Dual Bank Boot not working

[stst9180]

Posted on November 01, 2016 at 15:17

Dear Folks,

I have a STM32F429 running with nuttx os. As I understood when programming the BFB2 bit to 1 the system should go to system-boot-mode and then look for a valid ram adress at 0x0810000 and after that at 0x08000000. Unfortunately this isn't working for me: I programmed the Firmware Image at both locations with a ''top-of-stack'' of 0x200175d8 at the beginning of the firmware image. (Verified that with debugger). When programming the BFB2 bit to 1 the device jumps to the system boot mode ( PC @ 0x1FFF5162 ) but does not continue to the firmware image when stepping through.. It ends in a loop between ( 0x1FFF24ae and 0x1FFF24b6 ). The only Uart i have access to within this device is on PC10/PC11, but there is no output even when sending 0x7F's... Does someone have an Idea how to debug this issue further? Regards Pascal Speck

[Tesla DeLorean]

Posted on November 01, 2016 at 15:45

Does someone have an Idea how to debug this issue further?

I'd review what the code in the ROM is doing, and why it's not transferring control to the application.

[stst9180]

Posted on November 02, 2016 at 06:56

I'd most likely do that, but therefore I would need the original bootloader code and binary to get the debugger running.

Can I get that from ST? Or is there an other way to see what is happening?

[ST Renegade]

Posted on November 02, 2016 at 09:18

Hello Pascal,

in such cases I'm trying to simplify the project as much as possible to make one feature running. In my opinion you don't need to use the nuttx os to try this out. I would try to create a very simple project of flashing LED (or you can measure an output pin with a scope), set the dual boot bank bit using ST-Link utility and load the firmware at 0x0810 0000. Make sure the BOOT0 pin is set to 0 (grounded).According to the bootloader application note if you are in dual boot mode, and the BOOT0 pin is 0, it checks a valid stack pointer address. Try to see, what is the 0x0810000 value. Is it really a valid stack pointer address?It's also strange you are not able to connect to the bootloader via usart! As this is the last step of the bootloader process. However I think everything is ok, because you described you end up in a loop somewhere in the bootloader. In my opinion this is the point where the bootloader waits for a sync over UART, SPI or so...Have a nice day,Vojtech

[stst9180]

Posted on November 02, 2016 at 12:06

Now I found out where the Problem was:

I compiled my firmware to reside at addres 0x0 and thought that system bootloader will alias flash here.. Unfortunately systemloader still aliases its base (0x1fff0000) to 0x0. So when compiling the software to run at 0x08000000 everything works because system-bootloader will alias the currently running flash-bank to 0x08000000 and the inactive one to 0x81000000. Regards Pascal

[Tesla DeLorean]

Posted on November 02, 2016 at 16:28

I'd most likely do that, but therefore I would need the original bootloader code and binary..

No you'd just need a half decent disassembly of the code in the supplied ROM. Not sure ST offers loader source to anyone.As noted the ROM is mapped while running, your should always build the code for the native address it should run at, otherwise it just complicates how you can map things later. For example booting back into the loader.