Watch out for Stack Overflow in FlowCode

[mytekcontrols]

Stack Overflow, what is it? This is something that if you are programming directly in Assembler or "C" you learn about very quickly. It is a special area of memory in the PIC reserved for holding the return address when executing any kind of subroutine Call. This allows the PIC to know where to return to after the subroutine's code has been executed. If subroutine Calls are nested within other subroutines, additional return addresses will be stored on the Stack one after the other as each new subroutine is called. Then as each subroutine is completed, the return address of whoever called it is pulled from the Stack, allowing it to pick up where it left off.

This is a great system and works quite well assuming you stay within the limits of your Stack memory, which on some PIC chips can be as few as 4 levels. So if you have more than 4 nested subroutines when using one of these PIC's, your program will most certainly lose its way, causing the program to hang, or maybe go crazy and start executing the wrong part of your code.

When using FlowCode I just naturally assumed that handling the return address Stack was done automatically by the application, and that I did not need to be concerned about this. Well I was dead wrong. Macros are subroutines, and nesting too many of them can lead to problems.

I had been running a fairly complex FlowCode program (lots of nested macros) on a PIC16F877a, and occasionally I was seeing it lose its mind when running on the actual hardware. The problem seemed random in nature, and I could never pin it down to just one event. After a while I started thinking, could this be a Stack Overflow problem? It certainly seemed like it when I compared it to my Assembler days. But I just couldn't believe that FlowCode which was suppose to isolate the user from much of the inner workings of the PIC, would not have a way to deal with this, such as creating a larger Stack of its own utilizing standard ram memory, something that can be done in either Assembler or "C". Also because I never recalled seeing any warnings about this in the FlowCode Docs, I just assumed it wasn't a problem. Well it was.

I started snooping around and came across a FAQ article that exposed the Stack Overflow problem, which just like writing in Assembler or 'C', is something that the user of FlowCode has to be careful of as well. In my case I opted to change from the PIC16F877a to a PIC18F452 which has 4 times the Stack memory (32 levels).

Anyway this was a small disappointment, overall FlowCode is still quite superior to writing PIC programs over any of the alternatives. But it would be nice if the program could warn the user in some way when they have potentially nested too many macros for the targeted PIC chip.

[Benj]

Hello

Yes you are correct each flowcode macro is treated as a subroutine and therefore consumes a layer on the stack when it is being run. One way around the problem you mentioned is to turn on the BoostC software stack. This then allows you to run much more complex programs on the smaller devices.

See page 22 of the BoostC manual located inside the Flowcode V3/BoostC directory.

BoostC should flag a message if it thinks there is the possibility of stack corruption, check your compiler messages to make sure you are not getting a warning etc.

[mytekcontrols]

Hi Ben -- I'll have to check the compiler warnings as you suggested, although I don't recall seeing anything wrong.

Good idea on enabling the BoostC software stack, but for me it is simply easier to go with a better PIC chip, and thereby keep everything in it's default mode. I have really been trying to stay in FlowCode mode as much as possible, and avoiding the addition of any "C" Code Blocks. It's kinda the whole reason I chose to program with FlowCode in the first place, so as to not have to write any conventional lines of code. Thus far I have succeeded, and it does make it easier to troubleshoot.

Will there be built-in transparent support for the software stack in FlowCode 4?

[Steve]

We can't offer this kind of transparent support for the software stack because this is a feature of the underlying BoostC compiler, and Flowcode can theoretically operate with any C compiler underneath it.

But there is an easy way to turn this on without needing custom C code or anything. You just need to make a copy of an existing FCD file that includes the following lines in the "Device" section:

Code: Select all

ChipName=16F877A
ExtraLinkerParams=-swcs 6 2

Obviously, the exact chipname and software stack parameters specified will depend on your requirements.

[mytekcontrols]

Interesting, I'll give this a try.

Too bad there wasn't a device config aspect in FlowCode that would let you set this parameter by clicking a box. Then if FlowCode saw that this box was checked, it would know to either pull up an alternate FCD file for the particular target chip selected, or I don't know if this is possible, modify the existing FCD file on the fly. Seems like I recall seeing other suggested modifications of FCD files to suit particular needs, maybe these could also be accommodated within this device config system via other check boxes. Just a thought.

Hey on a completely separate subject; will FlowCode 4 have a better way to deal with unusual system clock speeds? This is something that becomes real important when trying to either optimize a baudrate across a large number of selections, or when directly creating a color video output.

[Steve]

unusual system clock speeds

Please explain more...

[mytekcontrols]

Unusual System Clock Speeds --- Using a crystal or oscillator input such as 14.318 Mhz which is 4 times the color burst frequency for NTSC video, or some other multiple at an even higher frequency, in order to directly produce color NTSC video output from a PIC (not something that could be done with FlowCode, but could be done indirectly within a C code box).
- OR -
Using a 16 Mhz crystal in order to produce a selection of RS232 Baudrates (1200, 2400, 9600, 19,2K) to a much higher degree of accuracy then that produced with a 20 Mhz clock.

These are just a few examples, of which there are infinite possibilities depending upon the specific application.

Unless I am mistaken, clock speeds are only available via a drop-down selection box, and the selections are few. There is no way that I know of to enter a unique clock frequency. Not being able to enter the exact clock frequency affects the Delay instruction's accuracy.

[Benj]

Hello

As well as the drop down selection of clock speeds you should be able to directly type in any value you wish.

Eg 14318000 for your 14.318MHz clock.

[mytekcontrols]

I didn't realize you could do that

Thanks Ben and Steve for the quick and informative responses to my questions.

[mimiyum]

If we get a warning, should this mean we shouldn't risk running that program? Does is mean we must automatically re-program to eliminate call stack overflow?

[Benj]

Hello

Call stack overflow will not damage the device but your program may not run as expected. If you are getting the warning and your program runs fine then there is probably nothing to worry about. If you are designing your system to always be on and reliably running then you can either play around with the code until the warning goes away or you can start using the watchdog timer peripheral. This will work to reset your device if it becomes locked for any reason eg due to a sequence of events causing a call stack overflow. More help on using the watchdog can be found by searching the forums.

[mimiyum]

Thanks for the tip! Back to the drawing board!

[mytekcontrols]

If you are designing your system to always be on and reliably running then you can either play around with the code until the warning goes away or you can start using the watchdog timer peripheral.

Although I would agree with using the watchdog timer to catch run away events, and it is a good idea to have this always active in a finished production program, I don't think it should be relied on as a fix for stack overruns. If your stack is not of sufficient size, then it is much better to either implement the Boost C solution to extend the stack via software, or use a chip with more physical stack memory. Having your chip randomly reset is not a good thing, and could pose a serious safety issue in certain circumstances depending on the actual real life application.

[mimiyum]

Going back to the drawing board is good. I rewrote the program and found out that it could have been sooo simple! Definitely no more stack overflow warnings. I couldn't afford to turn on the watchdog timer coz I need it to be continuously on without interruption.

Thanks for the tips!

[jadiflow]

I have a similar problem on an 16f685:

"Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
main and Task(s): hw used:8, sw used:0
interrupt: hw used:2, sw used:0"

I tried to turn on the BoostC s/w stack by editing the 16F685.fcd to include under 'Device':

ChipName = 16F685
ExtraLinkerParams= -swcs

Unfortunately, still the same serious warning. I closed and reopened Flowcode to make surte the amended .fcd was read in, no difference.
Any ideas?

BTW Is there a way to review stack usage other than going through the source?

Thanks,
Jan Didden

[jadiflow]

OK, fixed it. Apparently when you use -swcs you MUST also specify s1 and s2 otherwise the sw stack is only used for RTOS calls....
I changed it to -swcs 6 2 , and the warnings are gone now.

Thanks,

Jan Didden

[Jan Lichtenbelt]

Hello

Can someone tell me were I have to put the software stack commands?
ChipName=16F88
ExtraLinkerParams=-swcs 6 2

In the meanwhile I found the file 16F88.fcd in the directory Program Files (x86)/Matrix Multimedia/Flowcode V4/FCD. To save the file took some trouble, but at last I managed!



Jan Lichtenbelt

[Maher]

Hello
I have the same trouble in 16F877A
Serious Warning: Call stack usage exceeds:8!
Where & How I should put
ChipName=16F877A
ExtraLinkerParams=-swcs 6 2 ??
I Couldn't Open 16f877A.fcd
Thanks

[medelec35]

Hi Maher,
Welcome to Matrix forums.

Where & How I should put
ChipName=16F877A
ExtraLinkerParams=-swcs 6 2 ??

That was only mentioned if you wish to set up a limited number of devices only with the additional software stack.
The easiest way (in flowcode V3 Im assuming) is to go into Chip menu. compiler options then:

Software Stack.png

(110.08 KiB) Downloaded 9952 times

With exceeding stack level, you may be best tying to reorganize your flowchart reduce the stack level if at all possible.
You need to remember that a single component can take up more than 1 stack then interrupts can add another stack then each macro call with increase a stack.

If you get stuck then posting your flowchart may help.

Martin

[Maher]

Thank you Martin
The code failure to compile after put software stack instruction
but i solved problem by modify the code to avoid stack overflow
the simulation for this code on flowcode fin but it doesn't work in proteus 8 and when implementation on hardware
the config word for PIC16f877A in my project is 0x3f72
when I load the hex file to topwin2005 programmer(topwin ver 2.33 driver) the config word d0bd {fosc0 0,fosc1 1,wdten 0 ,PWRTEN 0,BOREN 1,LVP 0,CPD 1, WRT0 1,WRT1 1,DEBW 1,CP 1} after lode code to micro the LCD display just light
show the photos with file Removed url as iLividSetup can lead to spam installed on PC - Martin
what you suggest to solve this problem
thanks

[medelec35]

If you can post your flowchart and hex file the then can take a look for you.
I don't use 4shared as I don't trust it.

Martin

[medelec35]

Hi Maher,
I have removed your link due to very bad reviews of 4shared wanting people to install iLividSetup.

After some research I found it is NOT a good idea. Please read

Pros

-You gain the ability to arbitrarily be transferred to a totally different website than you had tried to go to.
-You will constant pop-ups in the corner of your screens "recommending" other sites to visit.
-Oh and your computer's performance, when online, will be slowed dramatically.
Yea, these are the "pros"

Cons

Your online experience will be dramatically reduced. Even after removing the "tool bar", which ILivid is happy to tell you how to do, there are other programs worming their way through your system that you cannot identify. It is practically impossible to remove and I-Livid will give no support except for empty platitudes.

Not taking the chance sorry

Martin