cancel
Showing results for 
Search instead for 
Did you mean: 

Assembly code to launch an application

HABIJ.1
Associate III

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

2 REPLIES 2

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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