Compiler Error (FC V3)

[sptcarl]

Can anyone suggest where I need to be looking to rectify the error message?..

Serious Warning: Possible sw stack corruption, function '__rem_8_8' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

I have ignored it in the past and all seemed to work ok.
I have now noticed though that an interrupt that only gets enabled and disabled at one stage of the main program, is enabled constantly, even before the enable command is run.
I assume that this is what is causing this?

Thanks for any advice,
Carl

[DavidA]

Hey there,

This is caused when you call a function from an interupt that you are also using in your main program, it warns you that the interupt function may be called at the same time you call the function in main.

If code size isnt an issue quickest way to solve is to create a copy of the function and have the interupt call the copy rather than the original.

You can ignore it as it may never happen (you can design your code so it doesnt), but if you can its good to ensure it doesnt.

Unless im misundersanding the problem

Also moving this to the FC2/3 forum for topic relevance

[sptcarl]

Hi David,
Thanks for your reply.

I may be being a bit thick here, I assume you mean something like the same calculation being performed in main as in the interrupt?

Trouble is, there is nothing like that in my program!

I still cant see this being what is causing the B0 interrupt to be active continually and not enabled and disabled when called for.

thanks,
Carl.

[DavidA]

Hi Carl,

If you dont mind posting your program, that might make it a bit easier to diagnose the problem then

If its commercially sensitive you can PM me with it.

[sptcarl]

David,
I finally found it!
Right at the beginning of the program where the variables get initialised, there was the MOD function (I'm not even sure why it was there! It was acting on a value read from the EEPROM)
As you suggested, a couple of MOD functions also appear in a timer overflow interrupt later on.

Removing the function from MAIN and simply making sure that the value was in range BEFORE it was written to the EEPROM, has removed the error AND cured the enable/disable problems I was encountering with the B0 interupt.

So, something definitely worth noting for future... DON'T ignore warnings for "possible sw stack corruption" errors!

Thanks again for your help,
Carl.

[sptcarl]

I spoke too soon,
B0 Interrupt still doesn't disable!

[Benj]

Hello,

What if you place a disable icon for that interrupt at the start of your program?

Is there a bootloader or something similar loaded on the device that could be enabling this interrupt and never disabling it again?

[sptcarl]

Hi Ben,

I already tried a disable icon at the beginning, it didn't make any difference.

I shall show up even more of my ignorance now, and say that I'm not even sure what a bootloader is. Im assuming its something to do with programing the chip? I use the pic development board to program the PICs then they get transferred to a dedicated PCB made up of simple in and outputs.

I have PMd my program to DavidA...

Cheers,
Carl.

[Benj]

Hi Carl,

A bootloader is a section of code on the device that is responsible for re-programming the device. If you are using the multiprogrammer then there is no bootloader to worry about.

One thing you could do is use C code to look at the interrupt enable registers and see what is going on.

Create a Flowcode byte variable named test.

Then in your program add the following code into a C code icon.

FCV_TEST = intcon;

After this use an output icon to output the byte to a port to show on LEDs or alternatively you can print the byte to the LCD using the print number function.

[medelec35]

One thing you could do is use C code to look at the interrupt enable registers and see what is going on.

Create a Flowcode byte variable named test.

Then in your program add the following code into a C code icon.

FCV_TEST = intcon;

After this use an output icon to output the byte to a port to show on LEDs or alternatively you can print the byte to the LCD using the print number function.

I totally agree with Ben, This is what I do in practice.
The only difference is I use RS232 to send data to HyperTerminal, since you can display quite a few different variables simultaneously on your PC or notebook screen.
Here is a screenshot of one of my typical Flowcharts showing arrangement.
Note: It's important to finish with two Send RS232 Char components. 1st containing 13 and last containing 10.
Also the

Code: Select all

update = 1

every second, than after the last RS232 component, you want

Code: Select all

update = 0

RS232_Data1.jpg

(187.47 KiB) Downloaded 2653 times

[sptcarl]

Hi Ben,
What sort of values should I be looking for here?

I've had a play about, and tried writing the value to LEDs (only the first 7 bits though, cant access the 8th easilly on the circuit board)

I seem to be getting values as follows..
0 at the start of the program
4 after variables have been initialised
20 after the interrupt is enabled
4 after interrupt is disabled...

[Benj]

Hello,

If you look in the device datasheet at the intcon register then this details which bits are set or clear in the register and therefore if the interrupt is enabled or not.

The RB0 interrupt is bit 4 for some 16F devices but I cannot say more without knowing your exact device.

For a 16F877A here is what your intcon settings are doing.

0 at the start of the program - All interrupts disabled
4 after variables have been initialised - tmr0 flag set
20 after the interrupt is enabled - RB0 Int enabled and tmr0 flag set
4 after interrupt is disabled... - tmr0 flag set

You could try manually switching off the tmr0 flag by using the following line of C code however I'm not sure if this will help and I'm surprised the GIE global interrupt enable bit is not being set. This is probably because as you say you cannot see the highest bit of the register.

cr_bit(intcon, 2);

[sptcarl]

Hey Medelec, sorry, I must have missed your post while I was writing mine. It looks a good method, but just someething I haven't got time to try at the moment!

Ben,
The device is a 16f886, (Ill check the data sheet later)

I'm now getting very confused and there are a couple of things I cant get my head round...
Why does initialising variables set the tmr0 flag? Surely that should only be set when I enable the tmr0 interrupt in another part of the program?
It looks like the RB0 interrupt IS being enabled and disabled, so why when I go to the part of the program with the tmr0 interrupt, is RB0 still enabled?

When I get chance, I'll have to try and tap into Bit8 and see what that has to tell me, also I'll try the C code for switching off the tmr0.

*A bit of background on what I'm doing here*
Its a program I'm working on at work, amongst all the other jobs I have to do, so I just tinker with it when I have a spare second. This is a special version of a standard program that is present all around the world In a type of amusement game that we manufacture. Like I said in an earlier post, the problem I'm having isn't a critical one, it works, it's just nice to get it perfect!

Thanks,
Carl