This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why branch to address with LSB=0 in non-secure state will trigger secure fault?

Hi all, 

I have some questions about branch instructions and TrustZone, not sure if here is the right place to post them.

I am using cortex M23, and I debug with Keil MDK.

I don't know if there is any limitation on branch instructions (B,BX, BL,BLX,BXNS,BLXNS). But here it says when processor is in non-secure state, the LSB of address shouldn't be 0, otherwise there will be hardfault. 

Does any one know why is it?

I am writing a non-secure software, so I did not enable the compiler TrustZone option (-mcmse) in this project. And I am using ARM compiler C library for startup and initialization.

In the assembly, there is one line

Fullscreen
1
2
_main_scatterload
0x12000064: f000f84c ..L. BL __scatterload ; 0x12000100
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

After this line the processor goes into secure handler state. So I guess BL & B have the same limitation like BLX & BX? It triggers a hardfault when the LSB of address is 0?

I don't think this is true. Because assembly is generated by compiler. If I cannot use 0x12000100 as destination, the compiler should know.

To provide more information, I put the assembly of __scatterload:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
__scatterload
__scatterload_rt2
0x12000100: 4c06 .L LDR r4,[pc,#24] ; [0x1200011c] = 0x12000140
0x12000102: 2501 .% MOVS r5,#1
0x12000104: 4e06 .N LDR r6,[pc,#24] ; [0x12000120] = 0x12000150
0x12000106: e005 .. B 0x12000114 ; __scatterload + 20
0x12000108: 68e3 .h LDR r3,[r4,#0xc]
0x1200010a: cc07 .. LDM r4!,{r0-r2}
0x1200010c: 432b +C ORRS r3,r3,r5
0x1200010e: 3c0c .< SUBS r4,r4,#0xc
0x12000110: 4798 .G BLX r3
0x12000112: 3410 .4 ADDS r4,r4,#0x10
0x12000114: 42b4 .B CMP r4,r6
0x12000116: d3f7 .. BCC 0x12000108 ; __scatterload + 8
0x12000118: f7ffffa6 .... BL __main_after_scatterload ; 0x12000068
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Thanks,

Hilda

0