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

        0x12000064:    f000f84c    ..L.    BL       __scatterload ; 0x12000100

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:

        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