Hello, I have Cortex-M3 and encountered problems when using scatter file: (I just want to keep space 4kb at the beginning of the code space)
LR_IROM1 0x08000000 0x01000{ ER_IROM1 0x08000000 ABSOLUTE EMPTY 0x1000 { ;0x1000 empty space } }
LR_IROM2 0x08001000 0x3F000{ ER_IROM2 0x08001000 ABSOLUTE 0x3F000{ STM32F10x.o(RESET, +First) ; vector table *.o(+RO) *(InRoot$$Sections) }
RW_IRAM2 0x20000000 0x0000C000 { ; RW data *.o(+RW +ZI) } }
After I compile the project and download the image into target, debugger puts its pointer at address 0x00000000 which is complete nonsence. Disassemly window looks like this:
***************************************************************************************** 151: 152: /* Get status to se if WIP (write in progress) clear */ 0x00000000 5700 LDRSB r0,[r0,r4] 153: sr = Fls_RDSR(); 0x00000002 2000 MOVS r0,#0x00 0x00000004 8799 STRH r1,[r3,#0x3C] 0x00000006 0800 LSRS r0,r0,#0 ****************************************************************************************** There should be main at address somewhere in 0x0800xxxx. The same happens when I don't use scatter file but set the R/O Base to 0x08001000 in the Linker Tab. If I put in the default value 0x08000000 everything works fine. I use ST-Link.
Does anybody have an idea what's wrong? How could I force the debugger to show propper entry point?
Thank you in advance for any hint.
"After I compile the project and download the image into target, debugger puts its pointer at address 0x00000000 which is complete nonsence."
Not nosence. The processor starts with the reset vector - the processor itself does not know where you decide to load your applications.
So the simulator would have to do the same thing.
Unless you have a boot loader that starts with the normal reset vector, your real target will not run your programs.
For debugging applications in RAM, you can use an ini file that sets the PC to the start address you want, but this is only suitable for debugging. For real programs you need to take care of the real reset address of the processor in your application or in a boot loader.
I just want to keep space 4kb at the beginning of the code space
Just a reminder: the Cortex-M3 CPU fetches the reset vector from the address 0x00000004.
Hello gents thank you both for the reply and the solution. I was quite confused. Now I put reset vector back in the first load region starting from 0x08000000 and it works fine. But as you said, I want to keep the space for the bootloader and want to debug without it. I vaguely remember that when I used IAR I put vector table to address different form 0x08000000 and it worked fine. Maybe section for vector table had a special name and IAR debugger initialized PC and VTOR.
I tried using ini file with $=__main but I suppose it's not sufficient because I also have to change VTOR. I could do some wrapper function around __main which would set VTOR and call __main and init file would look like this
$=wrapper_main
or is there a better way how to debug with different start address?
Thank you
A number of Keil sample projects shows how it is done. Some of the samples can be built in both a flash and a RAM configuration.
Most embedded ARM chips have some support for remapping the vector table to another address, and the startup code can be used to initialize this RAM region with the proper values.
The RAM configuration contains a setting to move the interrupt vector table into the start of RAM. And it contains an ini file that sets the PC to the proper value for your debugging.
Here is a simple uVision initialization file for code that is loaded to 0x40000:
FUNC void Setup (void) { SP = _RDWORD(0x00040000); // Setup Stack Pointer PC = _RDWORD(0x00040004); // Setup Program Counter _WDWORD(0xE000ED08, 0x00040000); // Setup Vector Table Offset Register } LOAD _OBJ\lpc1788_rtx_blinky.axf INCREMENTAL // Download Setup(); // Setup for Running
Note: put this in a XXX.ini text file and under "Target Option -> Debug" select this file as the initialization file.
Hello Marc
thank you very much for your code. It helped me much and works great.