Getting PC (R15) set to point to my code after placing it in RAM at the desired address with Keil, on an embedded ARM device

Question

Getting PC (R15) set to point to my code after placing it in RAM at the desired address with Keil, on an embedded ARM device

I need to place my program at the address in memory 0x20000000. In the project options in Keil I opened the tab "Target" and set the following settings (screenshot is here --> https://i.imgur.com/wL88jqR.png):

IROM1 start = 0x20000000
IROM1 size  = 0x400
IRAM1 start = 0x20001000
IRAM1 size  = 0x20000

This is my code, which I wish to place at the address I need:

STACK_TOP EQU 0x20000100
    AREA RESET, DATA, READONLY
    DCD STACK_TOP 
    DCD Start
    AREA PROGRAM, CODE, READONLY
    ENTRY
Start
    NOP
    NOP
    NOP
    b Start
END

After compilation I get 0 Errors and 0 Warnings:

*** Using Compiler 'V5.06 update 6 (build 750)', folder: 'C:\Program Files\Keil_v5\ARM\ARMCC\Bin'
Build target 'Target 1'
".\Objects\main.axf" - 0 Error(s), 0 Warning(s).
Build Time Elapsed:  00:00:00

Then in debug mode, I found my hex commands at the address I needed (screenshot is here -> https://i.imgur.com/aDohAV7.png):

     8:     NOP 
0x20000008 BF00      NOP      
     9:         NOP 
0x2000000A BF00      NOP      
    10:         NOP 
0x2000000C BF00      NOP      
    11:         b Start 
0x2000000E E7FB      B        0x20000008

But the problem is that I cannot execute it, since the program counter is always 0x00000000 and does not change in either the run mode or step-by-step mode. What have I done wrong?

assembly

arm

keil

cortex-m3

asked on Stack Overflow Mar 6, 2019 by

MadEvil • edited Jun 12, 2019 by

Peter Cordes

2 Answers

Presumably the abort handler points to address 0, and you end up in lockup state. You can't avoid using at least address 0x4 with Cortex-M. It is OK to have 0x2000001 at address 0x4. (if still rather incomplete).

A more complete implementation might be to write 0x20000101 to 0x4, and set VTOR to point to a vector table starting at 0x20000000 (which you will want to arrange to populate ASAP).

answered on Stack Overflow Mar 7, 2019 by

Sean Houlihane • edited Jun 12, 2019 by

Sean Houlihane

In debugging mode, you can see the binary loaded in RAM because Keil does that for you via the debugger, e.g. ULINK. However, this is only 1 time, the RAM content will be cleared in the next power cycle, and your binary will be lost the moment you reset the processor. The idea is that, you can place your program in RAM, but the binary has to be stored in the persistent/non-volatile memory (NVM).

The instructions to achieve what you need is provided in this article from Keil.

Note that you still need code in your NVM to bootstrap your application. It is impossible to run with an empty NVM with Cortex-M processors.

Your Program Counter is stuck at 0x00000000 because there is no vector table there to proceed. At startup, Cortex-M3 will look at the vector table (located at address 0x00000000 by default) and look for the starting address of Reset Handler (this address is stored at address 0x00000004). In the Reset Handler, you can copy your binary to RAM as shown in the article, then call the main program in RAM and run as normal.

answered on Stack Overflow Jun 12, 2019 by

DinhQC

User contributions licensed under CC BY-SA 3.0