Forum : ST7/STM8
Original Post
| Post Information | Post |
|---|---|
|
April 23, 2010 - 4:22pm
|
I'm using Ride7 7.26.09.0351 with STM8 Rkit 2.26.09.0317 for our project with STM8S207CT8 and experiencing "stack underflow" in Ride7 environment every time when i use breakpoints. |
Hi,
The "Stack underflow" message indicates that SP has a value which is too high.
This can be caused by a main() function that returns (it must not) or by SP being set to an improper value.
Can you check SP's value when the message occurs, and verify whether it matches the device stack (addresses 0x1400 to 0x1800)
Also a screenshot of the failure may be helpful.
Thanks, Bruno
Hi Bruno,
according to the map file the stack is defined as
i started programm and pressed pause. the SP show 0x7FF !? Why!?
I prepared the screenshot, but how i can transfer it to you?
Hi,
According to the ST docs, there is no "STM8S207CT8".
Is it "STM8S207C8T6"?
Is it "STM8S207C6T8"?
Something else?
In fact we will need more information than this. Please tell us everything that is written on the STM8 chip, or send us a picture of it. (support@raisonance.com)
Please also tell us what CPU you selected in the software.
Best Regards,
Vincent
Hi VincentC,
sorry it it was typo the chip is name as "STM8S207C8T6" and in Ride7 was choosen"STM8S207C8".
(see )
Here is all information that i can read on the chip
STM8S207
C8T6
90059 VG
MYS 901
ST-Logo, e4 in the circle and X
I have encountered similar errors ("Stack underflow", "Out of code",...), but further investigation showed these to be because of bugs in my code. You might want to compile a very simple project (say, main loop that just increments a variable) and try setting breakpoints there. See if the problem still occurs. Sorry I can't remember exactly what mistakes I'd made in my case...I think one was due to improper handling of an interrupt...another was related to optimization...
Hi,
As JQ says these messages usually result from code errors.
However in your case I think it results from something else: Your device might have more RAM than the doc and markings say. 6K instead of 4K. I have a STM8S208RB here and when I select the STM8S208R8 or the STM8S207C8 in the software, I observe the same behavior that you describe .
Now that I have the complete device reference I can ask my contact at ST to check that, but it could take a few days. In the meantime please try to select the "STM8S207CB" (that has 6K RAM) in the software and tell us how it goes like this.
What happens is that SP is initialized by hardware at 0x17FF, and then the debugger sees this it sends a warning message saying "stack underflow", which means that SP is out of the RAM (which is supposed to end at 0x0FFF), and masks SP so that it goes back inside the RAM. (0x17FF & 0x0FFF = 0x07FF)
Note that the next version of the software, which has been validated and will be released very soon, will handle this situation better, with clearer messages and no hidden masking of SP. In the meantime you should be able to go on with your work by selecting the "STM8S207CB" in the software. Just be careful not to use the higher 64K of flash that your device doesn't have. The linker will not warn you if you do.
Best Regards,
Vincent
Thanks, VincentC.
with STM8S207CB type the underflow message is disappeared.
I hope that you will release the new version as soon as possible.
With Regards