Forum : ST7/STM8
| Post Information | Post |
|---|---|
|
March 9, 2010 - 10:02pm
|
Hi, During the development of my application, I have encountered a problem during initialization. When I try to pause execution I see messages in the Debug Log like "Stack underflow" or "Out of Code" and it is no longer possible to use the "Show execution point" feature of Ride to find the source line where the program is executing. When I use the "Goto PC" feature in the disassembly it appears to be attempting to execute out of a data region (Mnemonic listing shows "db xxxh"). The illegal opcode detection flag was set (RST->SR ILLOPF bit was set, the rest of them were 0) During another test I found that the program was "stuck" at 0x8000 (user boot code section?) even though this section of code is quite simple/linear, plusinterrupts were disabled. What tools does Ride include that could help me troubleshoot this better? |
OK, I am finding that immediately when the program runs this bit is set, and also that if I clear it using the SWIM/debug interface in Ride, it gets set again after stepping to the next line. Why is this?
Hi again Jacob,
It looks like yuo are debugging a chip with a wrong device ID. Can you check that you selected the right device in your processor options?
If you still have problems, can you send us a photo of your device or the exact information which is printed on it, so that we can try to reproduce the problem in our labs?
Thanks,
Bruno
Bruno,
OK, I have checked that already, but am looking at it again. I don't see any problem, but perhaps I am missing something. Here is am image of the device marking (my apologies for the ugly PCB -- this prototype board has been hacked through a few hardware revisions)
Here is a screen capture from Project Properties in Ride.
Here is a screen capture from using the RLink to read the die ID in Ride.
I'm not sure if this is helpful information, but today I commented out a small section of code (just clears about 10 variables to zero during initialization) and found that I can debug my application when this part is taken out (it seems to work OK). In fact, if I put that code back in and instead comment out a nearby section of code that initializes some different variables, the behavior is the same. So I do not think that the problem is directly related to the section that I've commented out. It is as if a pending interrupt is causing some problem (even though interrupt handling is disabled until the end of this init() routine) or a watchdog timer is enabled (but I checked the option bytes and the flags in the RST->SR -- both IWDG and WWDG are disabled and the watchdog reset flags are clear).
Update: it seems part of my problem is happening because the the compiler/linker is not generating some function calls correctly. I have started a new thread for this but would still like to know what is going on with the illegal opcode bit.
Hi,
This looks like a stack overflow, underflow or corruption.
It could be caused by the linker problem that you reported, or simply by a "real" stack overflow (meaning your application just uses too much stack ;) ) or stack corruption. (meaning your application breaks its own stack when attempting to write data with a wrong or corrupted pointer, which is hinted by the fact that removing init code made the problem disappear)
And these problems usually result in PC being corrupted, which in turn will result in illegal opcodes being executed, resets being triggered, etc. as you observe.
I think we should first completely understand the stack/call issue (and fix it if it is a compiler or linker bug), and then we will be able to check if there is also a debugger issue.
Can you send us a project or two that show the two problems?
Please send them at 'support@raisonance.com'.
We will need complete projects, including sources, include files, compiled files, listings, etc.
Best Regards,
Vincent
Hi Jacob,
I replied to you *other* thread by email: As the code generates a "CALL 10h" instruction, it will start executing trash, and this is why you have this illegal opcode problem.
Regards,
Bruno
Yes, but the odd part to me was that it appeared to generate that illegal opcode reset flag before executing the bad call (e.g. when starting the debugger and just running to main()) and jumping into the data area. Once I understand what's causing the other problem I'll see if this still occurs. I think it is just a fluke; perhaps the RST->SR bits just don't like to be cleared over SWIM and need to be done via code. Thanks again for your assistance!
OK, this is good. I loaded the update you sent, and that resolved the problem with the compiler/linker incorrectly generating the code.
Regarding my confusion with the RST bits that I was seeing in Ride, I misunderstood this interface. The STM8S requires software to write a 1 to any of these bits in order to reset it, but using the debug explorer in Ride one has to make a change to a bit in order to write it. I was trying to change ILLOPF to a 0, but what I needed to do was change another bit to a 1 so that the ILLOPF 1 would get written and cause hardware to clear that bit. I tested this by triggering software resets using the WWDG. Now that I think I understand what is actually happening here it all seems to work right.
Thanks for your help.