Corrupted Fast Interrupt Shadow Registers

[George_B]

Hello,

I recently upgraded my FC6 to FC7 version

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.

[George_B]

[Benj]

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.

[George_B]

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 (141.84 KiB) Viewed 9813 times

[George_B]

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

[Benj]

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?

[George_B]

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

[Benj]

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]

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

[Benj]

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]

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.