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
STM32F767 nDBOOT MSP Topic is solved
Moderators: RoccoMarco, barthess
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32F767 nDBOOT MSP Topic is solved
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Who is online
Users browsing this forum: No registered users and 27 guests