AVR Studio Stack Monitor

Last post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.]