Corrupted Fast Interrupt Shadow Registers

A forums to allow bugs and problems with Flowcode v7 to be reported and resolved.

Moderator: Benj

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Corrupted Fast Interrupt Shadow Registers

Postby George_B » Thu Apr 13, 2017 11:59 am

Hello,

I recently upgraded my FC6 to FC7 version :D

I opened an old program which i created using FC6

I tried to compile the program without making any modifications.

I got the following message during compilation..


Code: Select all

Target folder:
Title:         
Description:   
Device:        PIC.18F.18F4680
Generated by:  Flowcode v7.2.1.4
Date:          Thursday, April 13, 2017 13:50:39
Users:         1
Registered to:
Licence key:   
   NOT FOR COMMERCIAL USE
http://www.matrixtsl.com
Launching the compiler...
C:\Program Files (x86)\Flowcode 7\compilers\pic\bin\xc8.exe  --chip=18F4680 MSGDISABLE=359,1273,1388
Microchip MPLAB XC8 C Compiler (Free Mode) V1.41
Build date: Jan 24 2017
Part Support Version: 1.41
Copyright (C) 2017 Microchip Technology Inc.
License type: Node Configuration

Employing 18F4680 errata work-arounds:
 * Corrupted fast interrupt shadow registers

    38:   __config("__PROG_CONFIG", "pic18", 0x4, 0xBB);
                                               ^ (1386) unable to determine the semantics of the configuration setting "BBSIZ" for register "CONFIG4L" (warning)
. . . . .


Memory Summary:
    Program space        used  7740h ( 30528) of 10000h bytes   ( 46.6%)
    Data space           used   253h (   595) of   D00h bytes   ( 17.9%)
    Configuration bits   used     7h (     7) of     7h words   (100.0%)
    EEPROM space         used    18h (    24) of   400h bytes   (  2.3%)
    ID Location space    used     0h (     0) of     8h bytes   (  0.0%)
    Data stack space     used     0h (     0) of   A84h bytes   (  0.0%)


You have compiled in FREE mode.
Using Omniscient Code Generation that is available in PRO mode,
you could have produced up to 60% smaller and 400% faster code.
See http://www.microchip.com/MPLABXCcompilers for more information.


Launching the linker/assembler...
C:\Program Files (x86)\Flowcode 7\tools\DoNothing\DoNothing.exe 


FINISHED




What is the reason this is happening?

The same program compiled with FC6 gives no warning or errors during compilation.
Last edited by EtsDriver on Tue Apr 18, 2017 6:42 am, edited 1 time in total.
Reason: Changed log to [code] for better readability

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Mon Apr 17, 2017 9:06 pm

:roll:

User avatar
Benj
Matrix Staff
Posts: 14566
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4595 times
Been thanked: 4238 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby Benj » Tue Apr 18, 2017 10:58 am

Hi George,

What is the reason this is happening?

The same program compiled with FC6 gives no warning or errors during compilation.


The Flowcode v7 compiler is simply letting you know more about what it is doing. The new compiler is made by Microchip and so is more able to provide helpful and up to date information during compilation.

Employing 18F4680 errata work-arounds:
* Corrupted fast interrupt shadow registers


There is a known problem with the chip so the compiler is automatically working around the problem for you. BoostC may or may not have been performing these workarounds for you silently.

38: __config("__PROG_CONFIG", "pic18", 0x4, 0xBB);
^ (1386) unable to determine the semantics of the configuration setting "BBSIZ" for register "CONFIG4L" (warning)


One of the configuration bits doesn't make sense, check your configuration settings. Probably ok to ignore but occasionally this will help to identify a problem.
These users thanked the author Benj for the post:
George_B (Tue Apr 18, 2017 12:29 pm)
Rating: 5.26%
 

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Tue Apr 18, 2017 12:49 pm

Benj wrote:Hi George,

What is the reason this is happening?

The same program compiled with FC6 gives no warning or errors during compilation.


The Flowcode v7 compiler is simply letting you know more about what it is doing. The new compiler is made by Microchip and so is more able to provide helpful and up to date information during compilation.

Employing 18F4680 errata work-arounds:
* Corrupted fast interrupt shadow registers


There is a known problem with the chip so the compiler is automatically working around the problem for you. BoostC may or may not have been performing these workarounds for you silently.

38: __config("__PROG_CONFIG", "pic18", 0x4, 0xBB);
^ (1386) unable to determine the semantics of the configuration setting "BBSIZ" for register "CONFIG4L" (warning)


One of the configuration bits doesn't make sense, check your configuration settings. Probably ok to ignore but occasionally this will help to identify a problem.


Hi Benj, thanks very much for letting me know about it. I just learn how the new compiler and Version 7 works..

Regarding the configuration bits, i checked this issue and i found something. The warning came from the "Boot Block Size 0" fuse bit. For an unknown reason, this bit was setted to number 3 (as i show you in the attached picture). I solve the problem by selecting the "1K Words Boot Block" option.

Just note that the project was created with Flowcode 6 and opened with Flowcode 7 and i didn't touch the configuration bits in the meanwhile.


Thank you
George

Capture.JPG
Capture.JPG (141.84 KiB) Viewed 5447 times
These users thanked the author George_B for the post:
Benj (Tue Apr 18, 2017 3:00 pm)
Rating: 5.26%
 

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Sun Apr 23, 2017 7:42 pm

Hello,

i observed something strange on hardware during testing the same program from both FC6 and FC7 which are completely the same without any modifications at all.


I am using the INT0 which is receiving some ( low frequency < 5Hz) pulses from a proximity sensor.

In the interrupt macro i only have a calculation icon which is just changes one variable(byte) from 0 to 1 every time that the interrupt occurs.

Then, in the main menu i have a decision icon where i check if the variable is 0 or 1 . If variable is 1 then i increment another variable by 1 and display this value on a triple 7 segment display.

The program compiled with FC6 was running fine as expected. Tested several times and works fine. At 3Hz pulse rate on INT0, i could see the increments on the display correct.

The program compiled with FC7 was not working as expected on hardware. At 3Hz pulse rate on INT0, the variable on the display was NOT changing at all. Only when i alter the pulse frequency from 3Hz to 0.2Hz for example the variable increments by one.


I know that it is better to upload my program for further checking but i would prefer not to publish it here at this time. I could send it to the administrator if required.


Thanks in advance
George

User avatar
Benj
Matrix Staff
Posts: 14566
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4595 times
Been thanked: 4238 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby Benj » Mon Apr 24, 2017 10:27 am

Hi George,

Would you mind sending me a PM with the program so I can investigate for you. Sounds like something is maybe blocking the interrupt from firing correctly?
These users thanked the author Benj for the post:
George_B (Mon Apr 24, 2017 10:31 pm)
Rating: 5.26%
 

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Mon Apr 24, 2017 10:36 pm

Benj, if you don't mind.. you can comment my program issues in this topic so everyone can learn something..

Thanks in advance for your support

George
These users thanked the author George_B for the post:
jgu1 (Tue Apr 25, 2017 6:01 am)
Rating: 5.26%
 

User avatar
Benj
Matrix Staff
Posts: 14566
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4595 times
Been thanked: 4238 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby Benj » Tue Apr 25, 2017 2:40 pm

Hi George,

One minor difference I have spotted.

In v6 the INT0 enable icon properties sets the interrupt for the falling edge, in v7 this has changed to the rising edge.

Maybe this could be causing the problems you're seeing e.g. if the falling edge is a nice clean high speed edge but the rising edge is more capacitive then the interrupt may fail to fire reliably.

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Tue Apr 25, 2017 8:28 pm

Thanks for your time Benj,

I probably left this setting (rising edge on INT0) while trying different settings to figure out what might be the problem. My hardware is developed so as to use "falling edge" setting like my FC6 program. I changed this setting to falling edge(as it should be) in FC7 program but there is no difference at all.
The same problem as i described in my previous post is still there. :(

At this time there is nothing i can do to overcome this issue with the interrupt on INT0 unless you seggest something else?



EDIT:

In Interrupt macro, i placed a component so that every time the interrupt fires i will turn on a led to flash momentary. After this test i see that the led is flashing fine every time the INT0 pin goes low and responding fine as well when i am changing the pulse frequency. That means that the interrupt fires properly and this is not the case.


With the same technique as above, i found that there is a malfanction while calculating the time interval between two pulses on INT0.

For example if i wait 2 sec and then fire the INT0 again it will work fine.. :?


Is there any different approach in the compiller of FC6 and FC7 regarding the calculations with float numbers?


Thank You Very Much!
George

User avatar
Benj
Matrix Staff
Posts: 14566
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4595 times
Been thanked: 4238 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby Benj » Thu May 04, 2017 1:58 pm

Hi George,

v6 used the BoostC compiler which had a library for dealing with floats. They were kind of an after thought and it took a third party to write the float library to support floats at all.

v7 uses the XC8 compiler which supports floats natively and much more efficiently.

Are you performing the floating point calculation inside the interrupt macros or in your main program loop? Due to the size of the calculations it's better keeping the calc outside of the interrupt if possible. Also are you performing calculations both inside an interrupt and outside in the main loop? If so the calculations have a chance of colliding with each other. This would have been an issue with v6 but v7 I think should be ok with this?

George_B
Posts: 88
Joined: Wed Jul 04, 2012 11:21 pm
Has thanked: 37 times
Been thanked: 12 times
Contact:

Re: Corrupted Fast Interrupt Shadow Registers

Postby George_B » Thu May 04, 2017 7:10 pm

Benj wrote:Hi George,

v6 used the BoostC compiler which had a library for dealing with floats. They were kind of an after thought and it took a third party to write the float library to support floats at all.

v7 uses the XC8 compiler which supports floats natively and much more efficiently.

Are you performing the floating point calculation inside the interrupt macros or in your main program loop? Due to the size of the calculations it's better keeping the calc outside of the interrupt if possible. Also are you performing calculations both inside an interrupt and outside in the main loop? If so the calculations have a chance of colliding with each other. This would have been an issue with v6 but v7 I think should be ok with this?



Hello Benj,

I perform the floating point calculations inside the main loop and outside of the interrupt since i am aware of this "problem". In my interrupt macro i only set a variable equal to 1 everytime the INT0 falls to zeto. You can see that in the program that i have sent to you the floating point calculations are made outside the interrupt.

The problem is that instead of having problem with FC6 i am facing problem with FC7 compiled hex.

:?