Possible Stack Overflow ???

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 8.

Moderator: Benj

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Possible Stack Overflow ???

Post by iain wilkie »

I have been having a nightmare getting a program in V4 to run in V8. Programs simulate ok but when transferred to chip I have the problem

After an update on the ATTiny13 from MM that was causing an interrupt problem, I have finally tracked down the source of another problem which seems to me to be some kind of stack overflow !!

The program involves a Timer0 overflow interrupt which works fine, and the program consists of the MAIN, which in it has a call to MACRO1 which in turn within it has a call to MACRO2 which within it has a call to a component macro that reads the ADC channels.

Now running in V4 everything is fine and program works when loaded to the chip. However running in V8 the program never appears to return from MACRO1 when loaded to the chip and hence does not run.

However if I remove MACRO1 by putting its contents in as in-line code in MAIN then everything runs ok at chip level.
So the only difference is essentially one call less as I see it.

So does this indicate a stack problem ? .... there are no error messages or warnings.

Iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Hi Iain,

Can you post some code that demonstrates this?
Stack problems can occur if you have variable access overwriting a return address on the stack, possibly due to overwriting the end of an array or string - particularly of parameters or macro local variables which are stored on the stack, and probably the most common cause?
Other no nos are using components in the interrupt handler, for example writing to a display when the main code also use them (keep that handler as short as possible is the golden rule.) And can lead to some insidious bugs :o
Alternatively if memory is very tight, (for example using two displays with 1k buffers on an Arduino with 2k ram was mentioned in the forum recently) memory problems will also cause grief.

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Hi Martin,

Thanks for taking an interest in this. I have attached the offending program.
You will see that in the MAIN section there is a group of icons that are "disabled" and just at the very start of that group is a macro called RAMPUP.

That group of disabled icons are the exact program that is contained in the macro called RAMPUP. If I run the program as it is at the moment it will simulate ok but when I run it in the chip it never exits the RAMPUP macro (it should when PRESSURE_IN > SETPOINT_IN). Please note that if I run this in V4 it works fine !!

Now if I disable the RAMPUP macro icon and re-enable the group of icons below ... effectively removing the RAMPUP macro call and putting the contents of RAMPUP in-line within MAIN, the program still simulates correctly but more to the point if I load it to the chip it runs no problem now !!!

Please note you need an updated ATTIny13.fcdx (also attached) from MM for this to work at all (there was a problem with the Timer0 overflow interrupt which MM fixed).... my feeling is there is a bug in Flowcode 8 or the .fcdx file.

Regards

Iain
Attachments
ATTINY13.fcdx
(6.31 KiB) Downloaded 200 times
Inflation REV4A_v7.fcfx
(29.66 KiB) Downloaded 217 times

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 Stack Overflow ???

Post by Benj »

Hello,

Stack corruption on an AVR is generally only an issue if you are running low on RAM resources and your stack runs into your variable space. I've seen this happening with a very large complicated programs but your program seems pretty simple.

In v6 or v7 we added this to the AVR compiler call to optimise out any unused variables and functions, before this they were being left in the compiled code. So the fact v4 works but v8 does not is strange as I would have expected the opposite if ROM/RAM size was an issue.
-ffunction-sections -fdata-sections -funsigned-char -o %2 %3 -lm -Wl,-gc-sections
Let me investigate for you and see if I can find out what's causing the problem.


Edit, I see in the routine you are doing ADC samples, maybe check the properties of the ADC components are ok vs your v4 program. e.g. conversion speed and acq cycles. Also your interrupt timings look maybe slightly off. e.g. the comments at the top of Interrupt macro don't seem right. This could of course be purely cosmetic.

Can you post the v4 program so we can compare how the settings are when it's all working.

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Hi Benj,

Thanks for replying.

Yes I did check the ADC values and they do appear to be exactly the same in V8 as in V4.
Also I can confirm that the interrupt time is as per the comments ..... this has been checked using a scope on the target hardware.

As requested I have attached the V4 edition of this program that runs absolutely fine when loaded to the chip.

Here's hoping you can resolve this one !

Cheers

Iain
Attachments
Inflation REV4A.fcf_avr
(19.23 KiB) Downloaded 207 times

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Hi Iain,

A couple of thoughts&ideas..

You never seem to set Divider - it 'may' always be initialised to 0 at the start of the program, though you shouldn't rely on this - needs to be rest after a count up as well..
It would probably simplify things to use a 16 bit counter, rather than two nested loops, for example in wait 1s, modify tick to be a 16 bit variable.

You use 'while x<>0' a few times as a busy wait - I would change to 'while x>0' where X is a signed 16 bit variable, which shouldn't make a difference, but is more robust for detecting the end of the loop.
Also in these busy waits, I would add some code, ideally sleep the MCU to wake on interrupt but even a few nops.. Again this shouldn't affect things..

Personally I would replace the gotos and labels with loops - is a matter of style (and v4 was more limited here) - and maybe I just had it drummed into me at an early age that gotos are bad!

FC reports that clock speed is too slow for accurate delays, and delay may not work with the PWM?, But if delay worked, would this be a suitable alternative to the interrupt code?

I don't have a ATTiny13 to test things on, nearest I have is an 85..

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Hi Martin,

I will have a look at your suggestions to see if any help, however please note that these would not explain why removing a call and placing its code in-line would suddenly make things work.

Also note everything else is fine .... PWM/Interrupt/delays all work perfectly, its just if I put the RAMPUP into a call that makes it crash !

Cheers

iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Reasons for the suggestions:

Trying to save a few bytes- the attiny13 only has 64 bytes ram, if one extra macro call is putting the program over the edge then things are close to the limit... Note that the stack frame for the macro call and the interrupt call will take up some of this. Since the only difference is this one extra macro call then this is surely the most likely explanation, otherwise any macro call would fail?

Empty loops, I just hope that the compiler would optimise them out.. the compiler might, or it might not. Depends how much optimisation it does? Sleeping the MCU would save some power and might be beneficial if battery powered

Single loops instead of nested loops are easier for my brain to cope with :roll: and as the program logic seems correct makes pinpointing the problem easier, another approach is to remove and then replace code and find at what point things break.

I ordered a couple of attinies for a play, as I have a board that should accommodate them, probably be on a slow boat however.

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Hi Martin,

I understand about the small ram area ... however its the same chip we are using when trying this with V4 and remember it works fine.

Anyway I think I have made a bit of progress ...... if I change the Divisor from an INT to a BYTE although this screws a time setting, the program
now works as expected. Indeed if I remove the Divisor section completely everything is good.
At the moment I am putting this down to the fact I think the interrupt routine is overrunning itself and causing the problem, removing or reducing the cycles in the routine stop this happening. What it doesn't explain is if this is the case it should be happening throughout the whole program and not just in one particular macro.
I have looked at the listings generated in V4 and V8 for the interrupt handling and they are substantially different ..... strangely the V4 implementation seems to get all this done within the vector call with 92 lines of code .... there is a FCM_Interrupt section of code but its never called !!! ... in V8 the vector call pushes and pops all the registers and calls the FCM_Interrupt section thus using about a total of 134 lines of code.
So although we could put this down to the interrupt routine overrunning due to more code, it still doesn't quite answer why its only happening in one routine and indeed why the interrupt handling is much more convoluted in V8 ?

Iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

It is a different compiler toolchain - with different code generation.

The interrupts 'should' be disabled (automatically) when in the ISR - but the ISR should be kept as short as possible - so it shouldn't be possible for it to overrun? (I'd suggested changing the ticks<>0 to avoid the possibility of 'overrunning' too - but the interrupts occur relatively slowly so this shouldn't occur)

The code length - shouldn't be a problem (as long as you're within your 1k program space limit)
The size of data in the RAM seems to be the problem (especially if a 1 byte change is affecting this?) This is probably only affecting RampUp at present - because you have the macro call stack frame on the stack when the interrupt occurs (saving everything to the stack - how many registers are getting saved to the stack here (if it's all 32 - then problems, that's 32 bytes of the 64 gone + return address) - you would hope that the compiler would be smart enough to save ONLY those used in the interrupt routine?. Whereas in main - if an interrupt occurs there is one less stack frame in use (rcall pushes at least a return address) This maybe a FC or a toolchain problem - as I understand it - FC just generates C code which is then compiled by the relevant toolchain compiler (which may be better at optimising things - depending on the level of licence you have paid for - not sure if this applies to the AVR toolchain?)

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Martin,

I totally agree with you. Looking at the .lst outputs from V4 and V8 it is clear the V8 output used much more stack than the V4.

A stack problem would definitely explain every scenario experienced.

I have ordered up a ATTiny25 which is basically exactly the same as the 13 but has twice as much ram. So what I am hoping is if I run the problematic program in this chip, if it works then that really proves it’s a stack problem.

If so I would be asking the question why FC doesn’t report an error or at least a warning.

I will let you know the outcome.

Iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

- one of the advantages of using these - just drop in a chip with more memory when the need arises.

It all just works (beautifully/hopefully)

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Ok ... all confirmed, using an ATTiny25 solves the problem. So stack overflow was the reason and the fact that ATTINY13 is ok in V4 and not in V8 is because V4 uses much less stack especially when calling an interrupt.

Which raises the question ..... Should we not be receiving an error and warning message when compiling ???? This would have been a pretty basic requirement I would have thought ?

Iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

& a question for Ben:

How easy would it be to alter the masm source generated by the C compiler (manually - rather than modifying the code generated by the compiler) - it's fairly easy in this case to just alter the interrupt vector code to only save the registers used in the interrupt routine. Then 'plug' the modified assembly language back into the toochain - for assembly and linking?

As an aside - if I compile this for the ATTiny13 using FC7 (for which I have a licence for the AVR chips) - the interrupt code doesn't seem to be generated at all - searching for Interrupt doesn't give a result in the masm listing.. The Interrupt vector table only contains __ctors_end and __bad_interrupt.. Or am I missing something here?

Compiling the code for the 328p chip using FC8.1 - generates suitable code for the interrupt macro - a vector for the ISR (which saves to the stack a lot of 'unnecessary' registers - visual inspection reveals that only a couple of these are used in the Interrupt macro)

This would allow an 'easy' fix - in this case - if the MCU was not so easily replaced?
FC7.txt
(12.1 KiB) Downloaded 133 times
Asm listing for ATTiny13 prog compiled using FC7
FC8.txt
(15.39 KiB) Downloaded 121 times
Asm listing for prog compiled for AT328p using FC8
Note that these are the 'lst' files generated - I have altered the filename extension to allow upload here.

Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Martin,

Part of the answer is here ...
viewtopic.php?f=76&t=20611

This wan the initial problem I had with no interrupt vector generated for the ATTiny13 .... so this part has been updated.
However I am now having the same problem with the ATTIny26 !!

You are seeing exactly what I came across .... where a large number of un-necessary registers are pushed to the stack during the interrupt routine.

Iain

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Thanks Iain,

I'll try the updated definition file after work today... Looks like at update is needed for the 26 and possibly others in the attiny family?

Martin

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Possible Stack Overflow ???

Post by medelec35 »

Hi Ian,
Do you want to try the attached file and see if it resolves your issue or not?
Attachments
ATTINY26.fcdx
(14.93 KiB) Downloaded 105 times
Martin

iain wilkie
Posts: 97
Joined: Tue Jul 14, 2009 4:37 pm
Has thanked: 13 times
Been thanked: 9 times
Contact:

Re: Possible Stack Overflow ???

Post by iain wilkie »

Hi Medelec,

Thanks but unfortunately I still get the same result. I think we need to wait for an update from MM

Cheers

Iain

User avatar
LeighM
Matrix Staff
Posts: 2178
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 481 times
Been thanked: 699 times
Contact:

Re: Possible Stack Overflow ???

Post by LeighM »

if I compile this for the ATTiny13 using FC7 (for which I have a licence for the AVR chips) - the interrupt code doesn't seem to be generated at all
Hi Martin,
For V7 you need the attached updated FCD
Attachments
ATTINY13.fcdx
(5.58 KiB) Downloaded 103 times

User avatar
LeighM
Matrix Staff
Posts: 2178
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 481 times
Been thanked: 699 times
Contact:

Re: Possible Stack Overflow ???

Post by LeighM »

However I am now having the same problem with the ATTIny26 !!
Looks like ATTINY26 FCD needs some work :(

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

And a new definition file for the 32u4 (ie Arduino micro) as well please....

Error given:
C:\Users\Martin\DOWNLO~1\Bluetooth micro .c:1341: warning: 'USART0_RX_vect' appears to be a misspelled signal handler
Martin

User avatar
LeighM
Matrix Staff
Posts: 2178
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 481 times
Been thanked: 699 times
Contact:

Re: Possible Stack Overflow ???

Post by LeighM »

Thanks Martin,
Updated V7 FCD attached (V8 version will go out with next update)
Leigh
Attachments
Arduino Micro.fcdx
(15.01 KiB) Downloaded 94 times

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Thanks Leigh,

The v8 (update) download generates the correct interrupt code. In v7 compilation now completes - but the interrupt vector and code are still not generated :cry: (- file copied to the Flowcode 7/FCD/AVR directory)

Martin

User avatar
LeighM
Matrix Staff
Posts: 2178
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 481 times
Been thanked: 699 times
Contact:

Re: Possible Stack Overflow ???

Post by LeighM »

Hi Martin,
Has FC 7 disabled your interrupt icon?
The timer name has changed from 0 to 1.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Possible Stack Overflow ???

Post by mnf »

Yes & no...

I'd re-enabled it. Changing the name to of the interrupt to the correct UART1RX instead of 0 fixed the problem. Oddly - in v8 the name is UART0RX.

Still didn't get the bluetooth working in v7. Now to test in v8 - works well in v8 using UART0RX interrupt :D - should there be two interrupts? I'm using d2 and d3 (standard hardware mode) at present.

Many thanks..

Martin

Post Reply