Bug report for multiple (all?) KSDKs, not setting VTOR in CMSIS SystemInit()

[andrewparlane]

Looking at KSDKS for:

MK10 - v2.2.0,

MK12 - v2.3.1

MK66 - v2.7.0

In startup_X.c[pp] ResetISR() we have:

...
#if defined (__USE_CMSIS)
// If __USE_CMSIS defined, then call CMSIS SystemInit code
SystemInit();
#else
...
#endif // (__USE_CMSIS)

...

#if !defined (__USE_CMSIS)
// Assume that if __USE_CMSIS defined, then CMSIS SystemInit code
// will setup the VTOR register

// Check to see if we are running the code from a non-zero
// address (eg RAM, external flash), in which case we need
// to modify the VTOR register to tell the CPU that the
// vector table is located at a non-0x0 address.
unsigned int * pSCB_VTOR = (unsigned int *) 0xE000ED08;
if ((unsigned int *)g_pfnVectors!=(unsigned int *) 0x00000000) {
*pSCB_VTOR = (unsigned int)g_pfnVectors;
}
#endif // (__USE_CMSIS)

...

Specifically note the: "Assume that if __USE_CMSIS defined, then CMSIS SystemInit code will setup the VTOR register".

In system_X.c SystemInit() There is no code to setup VTOR.

This isn't an issue for a normal application but it is an issue if you use a bootloader (or potentially if you run from RAM).

In an older version of the K66 KSDK (not sure which version it is off hand) the Reset_Handler is in assembly in startup_MK66F18.S and contains the code:

cpsid i /* Mask interrupts */
.equ VTOR, 0xE000ED08
ldr r0, =VTOR
ldr r1, =__isr_vector
str r1, [r0]
ldr r2, [r1]
msr msp, r2

Which sets up VTOR immediately.

Interestingly it also sets up the stack pointer, which is something else that the latest KSDKs don't do.

Looking at the objdump for my application there's nothing in there that sets the stack pointer. We could argue that this is something that the bootloader should do before jumping to the application. I guess on that same front we could argue that the bootloader should setup the VTOR register too. However in that case the comment: "Assume that if __USE_CMSIS defined, then CMSIS SystemInit code will setup the VTOR register" is still wrong.

Please can someone file an official bug report for these.

Thanks,

Andrew

[danielchen]

Hi @andrewparlane :

Thanks for your feedback.  We have a MCU-BOOT middleware, VTOR is configured there.

SDK_2.9.0_FRDM-K66F\middleware\mcu-boot\src\bootloader\src\bl_main.c

Regards

Daniel

[andrewparlane]

That doesn't help if the application is run out of RAM, and in a couple of other possible albeit weird setups

This is either a bug or the comment needs to be re-written to state that setting the VTOR and stack pointer for applications that don't have their vector table at 0x00000000 is the job of the bootloader / JTAG programmer.

I'd suggest setting the VTOR register in the CMSIS SystemInit() function as the comment suggests, since it's an easy fix, and has no downsides. The stack pointer is more complicated because we'll have already used the stack by the time we get to that point, since the entry point is a C function. This means if you execute from RAM and the flash is erased (or at least at the first word is 0xFFFFFFFF) then the application will immediately crash, since the first assembly instruction is to write data to the stack with will be an invalid address.

[danielchen · Accepted solution]

Thanks for your good suggestions.  I will forward it to software team.

Regards

Daniel