Skip to main content
Graduate II
March 18, 2024
Question

Assembly code to launch an application

  • March 18, 2024
  • 1 reply
  • 2310 views

I got this assembly code (see below) in an ST example code on secure boot and  and I don't understand some lines :

  • why do we have to push R1 five times in a row?
  • why is LR set to 0xFFFFFFF9? That is causing a hard fault at run

Does anyone have better understanding?

 

 

 

1   .global launch_application
2    aunch_application:

3    /******************************************************
4    * return from exception to application launch function
5    * R0: application vector address
6    * R1: exit function address
7    * push interrupt context R0 R1 R2 R3 R12 LR PC xPSR
8    *******************************************************/
9    MOV R2, #0x01000000 /* xPSR activate Thumb bit */
10  PUSH {R2}
11  MOV R2, #1
12  BIC R1, R1, R2 /* clear least significant bit of exit function */
13  PUSH {R1} /* return address = application entry point */
14  MOV R1, #0 /* clear other context registers */
15  PUSH {R1}
16  PUSH {R1}
17  PUSH {R1}
18  PUSH {R1}
19  PUSH {R1}
20  PUSH {R0} /* R0 = application entry point */
21  MOV LR, #0xFFFFFFF9 /* set LR to return to thread mode with main stack */
22  BX LR /* return from interrupt */
23  .end

    This topic has been closed for replies.

    1 reply

    Graduate II
    March 18, 2024

    It is what I'd characterize as a "call gate" it determines how the MCU unstacks the processor context.

    Depending on the patterns, it picks one stack or the other, and unwinds the NVIC depth.

    Perhaps look a one of Joseph Yiu's Essential Cortex-M books, or ST's Programming Manuals, or the ARM TRM

    HABIJ.1Author
    Graduate II
    March 26, 2024

    Thanks for the tip, I read Joseph Yiu's book and understood better the call gate mechanism.

    I still have a problem with the line 21 :

    MOV LR, #0xFFFFFFF9 /* set LR to return to thread mode with main stack */

     For a reason that I don't understand , #0xFFFFFFF9 is being considered as an address and branching to it is causing  the hard fault. See capture attached.

    Does any one have a clue why #0xFFFFFFF9 is being considered wrongly as an address?

    Regards