Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
cmhicks
PostPosted: Nov 23, 2008 - 05:31 PM
Hangaround


Joined: Nov 20, 2008
Posts: 333
Location: Cambridge, UK

Hi All,

There are a number of threads around in these forums saying that the Stack Monitor functionality has never been implemented fully and hence the menu entry in AVR Studio is grayed out. However, I am running code in the simulator (on a simulated Mega168) and I keep getting the error message "Excessive stack overflow. Simulation stopped." or words to that effect. It seems as though some kind of stack monitor is indeed running.

I don't believe my stack has overrun when I get this message, but my program does mess about with the stack pointer a lot because I am running an RTOS. I'm possibly doing this in a slightly different way to most RTOS systems, as mine is in C++ and a task object contains its own stack. Therefore the stacks are not all at the top of memory, but are dotted around memory wherever the corresponding task object has been allocated (in theory this could even be on the stack of another task!).

So to my questions - does anybody know:

Can I switch off this "Stack Overflow" error, or at least convert it to a warning that does not stop the simulator?

What gets monitored so as to trigger this message?

Many thanks,

Christopher Hicks
==
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Nov 23, 2008 - 06:01 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 69334
Location: (using avr-gcc in) Finchingfield, Essex, England

I'm just guessing but I'd guess the program prints that message when SP passes the RAMEND boundary (or maybe for each time it changes while beyond that limit). So what is the actual SP value when you see this and what's the RAMEND for the AVR model you are using?

Cliff

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
cmhicks
PostPosted: Nov 24, 2008 - 10:07 AM
Hangaround


Joined: Nov 20, 2008
Posts: 333
Location: Cambridge, UK

The exact message is:

AVR Simulator: Excessive stack overflow, stop sim

On the current build of my code, it stops on a PUSH R0 instruction with the SP=0x01F0. On a mega168 the RAM goes from 0x100 to 0x4ff inclusive, so the SP is definitely pointing at valid RAM, and looking at my structures in memory, 0x01F0 is a few bytes from the top of one of my task stacks.

I have looked hard and there is no evidence of corruption of any of my data structures, and I can resume the simulation and everything continues as it should. It really does seem that the simulator is trying to be a bit too helpful!

The PUSH R0 instruction it stops at is the first instruction of the RTOS context save. Bizarrely it does not stop there when it is saving a context whose SP=0x1A4.

Christopher
==
 
 View user's profile Send private message  
Reply with quote Back to top
rkruse
PostPosted: Nov 25, 2008 - 09:24 AM
Hangaround


Joined: Jan 19, 2005
Posts: 177
Location: Atmel Norway

cmhicks wrote:
The exact message is:

AVR Simulator: Excessive stack overflow, stop sim

Which AVR Studio version do you use?

The ATmega168 is supported by Simulator2 in the latest AVR Studio (4.15), there is no stack supervision there and we recommend using simulator2 when possible.

Regarding the bug you see:
The simulator tries to track the call stack in order to implement "Step Out" in a compiler-independent manner in the debugger.

The simulator's internal tracker stack tracks call/interrupt and return events (interrupts, rcall, call, (e)icall, ret, reti)

We have seen a problem with this before in a (possibly RTOS related) piece of code that pops the return address into ZH:ZL and then does an IJMP instruction in place of a 'ret'. This is missed by the simulator stack tracker and eventually can cause it to overflow. If you have something like this in your code, the error message you see is probably not related to the program location it is reported on.

If your AVR Studio is older than 4.13 updating it may help. And, as mentioned earlier, simulaotor2 does not have this issue.

- roland
 
 View user's profile Send private message  
Reply with quote Back to top
cmhicks
PostPosted: Nov 25, 2008 - 12:27 PM
Hangaround


Joined: Nov 20, 2008
Posts: 333
Location: Cambridge, UK

Thanks. I'm on AVR Studio 4.14 which I think only supports mega168P in Simulator2, not plain mega168 (not that there's a lot of difference, I imagine).

So, I will upgrade and report back.

Christopher
==

[EDIT: I upgraded and switched to using Simulator2. This does not seem to exhibit the same problem, as expected.]
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits