We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
What is necessary to simulate or debug a STM32 program that is intended to run in RAM?
In µVision4 the program is located and loaded in RAM, but start debugging results in a jump to 0x00000000. Setting the SP and PC registers manually doesn't solve the problem. Is it necessary to define a minimal vector table that resides at 0x00000000 to make debugging possible?
Most ARM chips have a solution where the interrupt vector table can be remapped into the RAM region (or actually a part of the RAM region mapped to overlap the original interrupt vector table location).
I know that there is such a possibility using the VTO register. But the problem is startup of the debugging. The program has no chance to modify this register because just the first program step goes wrong. I've modified the scatter file to locate the vector table in FLASH starting at 0x08000000 and debugging seems to work fine. This workaround could help, but I thought there is a solution to debug or simulate code that completely will run in RAM without extensions that provide a special vector table in FLASH for startup.
Hi,
have a look into the example projects in the Keil\mcbstm32(x)\ folder.
I.e. the framebuffer (MCBSTM32E) uses RAM.
You must set the PC via PC = 0x..., or look how this is done in the .ini files (You'll find them in the project folders).
. BR, /th.
sorry, not the framebuffer, the ExtRam Example :-)
You load the program into RAM and set the PC - normally done by an init scipt. A number of Keil examples have RAM targets and a startup script for this.
When the program starts, no interrupts are enabled, so it doesn't matter if the interrupt vector table has been remapped or not. But your code (or the startup file) must perform the remapping of the interrupt vector table before any interrupt handler is configured.
Thanks, this was the important hint. Using the *.ini file it's possible to prepare the context before debugging.