S32K3 Vector Table Entry Bit[0]

[Psabouri]

Hi,

I have the following two questions:

1. As per ARM Cortex-M7 processor TRM, The entries on vector table should have bit[0] set to designate thumb instruction state upon exception entry. In S32k3 RTD, the vector table entries are set in "Vector_Tables.s" file. For reset entry one is added to the "Reset_Handler" symbol to set bit[0], while for the rest of the entries nothing is added and it is still working. For example, the address of the "NMI_Handler" symbol in the map file has bit[0] cleared (0x00400a68), but when I look at the vector table in the memory the value at NMI entry has bit[0] set (0x00400a69). How is this achieved without explicitly adding one? Why there is a difference between Reset_Handler and NMI_Handler that one need explicit addition of 1 and the other one doesn't.

2. As per ARMv7-M Archtecture RM, " On exception entry, if bit[0] of the associated vector table entry is set to 0, execution of the first instruction causes an INVSTATE UsageFault. If this happens on a reset, this escalates to a HardFault, because UsageFault is disabled on reset". I am removing the addition of one to the "Reset_Handler" symbol in reset entry of vector table. This will cause the reset entry in the vector table to have bit[0] cleared. As per the above quote from ARMv7-M Arch RM, I was expecting the program to go to the HardFault_handler at reset, but to my supprise the exception did not raised and the program continue executing as normal. Why the program did not raised the exception?

Thanks,

Pouya

[lukaszadrapa]

Hi Pouya,

1. It took me a while to figure this out but it's really simple. We can find in startup_cm7.s:

.thumb
.thumb_func
.globl Reset_Handler
.globl _start
_start:
Reset_Handler:
/*****************************************************/
/* Skip normal entry point as nothing is initialized */
/*****************************************************/
cpsid i
mov r0, #0
mov r1, #0

...

At first sight, it seems to be ok, nothing to be afraid of. But there are two labels at one place:

_start:
Reset_Handler:

And the issue is that .thumb_func affects only one following symbol, not symbols. So, .thumb_func only says here that _start will be thumb function, not the Reset_Handler. We would need to use:

.thumb
.thumb_func
.globl Reset_Handler
.globl _start
_start:

.thumb_func
Reset_Handler:

Then the "+1" would not be needed in the vector table. Someone just obviously used that as workaround. But I can see no problem here, this will also work as expected.

2. I did quick test and I can reach the hard fault. How did you tested it? Notice that when you load new project to MCU by debugger, the debugger will sets program counter manually at this moment at entry point / reset_handler of application. You need to reset the device to see the effect.

Regards,

Lukas

[Psabouri]

Hi Lukas,

Thank you for your explanation. I have totally overlooked _start symbol in startup_cm7.S file. 

As for my second question, this is how I performed my test.

1. Removed the "+1" from "Reset_Handler" in Vector Table

2. Loaded the target

3. Expecting The HardFault Exception at powerup since the Reset Handler entry has address with Bit[0] cleared and at powerup is loaded into PC. 

Thanks,

Pouya 

[lukaszadrapa]

I used Lauterbach debugger for my test. First, I just used system.up command to reset the device and to enter debug mode and this is the result right after using this command:

I also tried to do power off / power on sequence and then I used system.attach command to connect to a running target. When I stop the code, it's hanging in the same loop in HardFault handler.

So, everything works as expected from my point of view.

Regards

Lukas

[lukaszadrapa]

And I will add that other vectors in the vector table points to C functions in exceptions.c file, so those are recognized automatically as thumb functions.