STM32F767 nDBOOT MSP Topic is solved

[plamen]

Hello,
I'm using STM32F767I, ChibiOS 17.6.0, arm-none-eabi-gcc 7.1.0 compiler.

I'm trying to implement bootloader using nDBOOT and nDBANK option bits, but I'm having buffer overwrite problems. The problem appears to be that in USART interrupt handler the stack pointer of the IRQ handler points somewhere in RAM of my application. I reproduced the situation with STM32F767ZI-NUCLEO144 and the default ChibiOS demo for that board:

1) Enable nDBOOT and nDBANK option bits with ST-Link or with OpenOCD. BOOT0_ADDR and BOOT1_ADDR are 0x2000, which is boot from 0x0800 0000
2) Compile and run demos/STM32/RT-STM32F207ZG-NUCLEO144. The app works fine - LEDS blink, test report over serial line pass.
3) Set breakpoint on STM32_USART3_HANDLER
4) Send something on the serial line to trigger USART3 IRQ. Check the SP:
(gdb) info register sp
sp 0x20003420 0x20003420

The stack pointer is beyond the base of MSP, which is 0x20000400.

If I disable the nDBOOT option and restart the board, breakpoint on the IRQ shows:

(gdb) info register sp
sp 0x20000400 0x20000400

[Giovanni]

Hi,

After reset, Cortex-M initializes the main stack by reading the value from the second word in the vectors table, ChibiOS assumes that main stack is initialized that way.

Probably the bootloader initializes the stack in its own position and do not initializes the stack for the loaded application like reset does.

If this is confirmed then you need to change crt0.S to setup the main stack explicitly.

Not setting up things like reset does before passing control is the one sin most bootloaders do.

Giovanni

[plamen]

Thanks!
There is code in crt0_v7m.S that initializes MSP. I added in my Makefile
UADEFS = -DCRT0_FORCE_MSP_INIT=TRUE

and now all seems to be good.

[Giovanni]

I forgot that

Probably already faced the same problem.

Giovanni