Possible SW Stack Corruption

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

Post Reply
jethronull
Posts: 30
Joined: Tue Dec 04, 2012 4:03 am
Has thanked: 1 time
Contact:

Possible SW Stack Corruption

Post by jethronull »

I've had a few of these warnings rush past without me noticing them till recently. Specifically I am getting:
Serious Warning: Possible sw stack corruption, function 'FCI_GETLENGTH' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCI_MIDSTRING' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCI_NUMBER_TO_HEX' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCI_SHEAD' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCI_SCOPY' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'delay_us' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Now I thought I was being pretty careful not to put any macros in my interrupt routine but it is pretty hard to avoid using Flowcode's own macros. There is a genuine likelihood of one of these chaps colliding, though I am not sure whether it has happened or not (Ben, could this be the source of some of my RS232 and Flowkit weirdness?). This just seems odd to me though. Is the compiler worrying unnecessarily about built-in macros? If this is really a concern then the only solution I can think of is to go back to polling the RS232 instead of calling it by interrupt, which is of course, the preferred way to handle serial comms.
Attachments
Probe Test 1.fcf
(106.73 KiB) Downloaded 178 times
Jon/JethroNull

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

Re: Possible SW Stack Corruption

Post by Benj »

Hi Jon,

Yep that could be doing it. It looks like because your using the string manipulation functions in your interrupt routine and also inside your main loop then as you say there is the high likelihood of a clash. You can still receive characters using the RXINT but would it be possible to set a variable that then gets picked up in your main program loop to do the string processing etc on the received data.

jethronull
Posts: 30
Joined: Tue Dec 04, 2012 4:03 am
Has thanked: 1 time
Contact:

Re: Possible SW Stack Corruption

Post by jethronull »

Since using ReceiveRS232String only seems to work with ASCII data I can't use that (am I correct about that or am I missing something?). Could I cycle round ReceiveRS232Char feeding the incoming bytes into a int array? Then deal with the processing outside the interrupt. Or would I need to take one char at a time, exit the interrupt and concatenate outside? The latter would need nothing but a .Return in the interrupt, but the concatenation would probably get interrupted by the next RX byte.

BTW, did you know that the ReceiveRS232String definition in the help file actually calls it ReceiveRS232Char (little cut a paste error there).

Thanks.
Jon/JethroNull

Post Reply