MSPM0G3507: What space is actually stack using

There is no built-in stack monitoring, so you will not get an explicit notice of stack overflow.

You may want to check your Debug/<project>.map file to see if there are any variables allocated near the bottom of the stack.

That said, I see some things here that make me suspicious of a stack overflow:

1) a number of address words, pointing upwards in the region (saved SP -> stack backchain?). Some of them (e.g. 0x20207C50->0x20207E8C) point up into the stack proper, across the boundary as it were.

2) a 220-byte string (does "27134" look familiar?), which is half your stack size by itself. Does your code put any strings on the stack? printf() in this library uses quite a bit of stack (>256 bytes as I recall -- I couldn't use it on a C1-series device). 

3) I vaguely recall that some system (IAR? FreeRTOS?) uses 0x55 as a sentinel in its stack monitor

This could be an illusion of course, but it may be worth a quick audit and/or step-through. 

Hi Bruce,

Thank you for your reply.

I didn't see anything in .map file that are near the bottom of the stack.

1). I understand. Where are the code to save SPs from? Are they saved through my code? I didn't intentionally do that in my code.

2). Where did you see "27134"? 

      I did use many printf(). After they are removed, the stack use is much smaller like this:

But still overflows. And what are "0x20202020"?

3.) 0x55 are what I wrote to these addresses intentional to check stack overflow. 

In addition, I didn't find where the stack start address (0x20207E00) in .map file defined. Is it possible to change it? I didn't find where it is set in either compiler options or linker options.

Thanks!

Crane

If you were the one who put the 0x55-s there, you're already way ahead of me. Unless you're running short of RAM, maybe the answer is to just subtract the end of the 0x55-s (0x20207C00) from the top of stack (0x20208000) and conclude that 0x400 is what you need for stack. (You might want to add a few more bytes just in case.)

If you're not using sysconfig, you can set the stack size at "Build Settings->Build->Linker->Basic->Set System Stack Size". This causes "--stack_size=<number>" to be provided to the linker.

If you are using sysconfig, I haven't figured out how to set it. The generated linker .cmd file contains "--stack_size=<number>" (so the command-line option is ignored) but I don't see where that comes from in the .syscfg file nor in the sysconfig app. [Maybe someone else knows?]

[Edit: Apparently you can't. Summarizing this result: you turn off linker-file-generation in sysconfig, then change --stack_size yourself.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1375255/mspm0g3507-how-to-change-stack-size-with-sysconfig

[Edit: Sorry, I missed your other question. I got "27134" from that 220-byte string. 0x20202020 is just four blanks ("    "). It would appear that printf, for whatever reason, pre-pads its buffer with blanks. (I didn't know that.)]

I followed the instructions in the link, but the stack size is still not changed. I asked a related question:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1391111/mspm0g3507-how-to-change-the-stack-size-when-using-syscfg

In regard to "27134", you mean you see it from 0x20202020? But there are still many of these after I completely removed printf(), although the stack use is much smaller.

Thanks!

Crane