cancel
Showing results for 
Search instead for 
Did you mean: 

Calling stm32429I-Eval Bootloader

chuck2
Associate
Posted on May 02, 2014 at 01:26

Hello, we are wanting to call the built-in bootloader from our application without manipulating the BOOT0/BOOT1 pins. I am trying to use the EVAL board to validate our method. The Users Manual for the Eval board does state:  ''The RS-232 boot loader mechanism is not supported on the STM32429I-EVAL''. There is no explanation of this statement. However, if I move the Boot0 switch on the eval board to 1 and power cycle, I am able to at least connect to the bootloader over RS-232 using the ST demo flash loader program. If I can get that far by calling the bootloader on the Eval board with the BOOT pins both at 0, I will call it a success until our hardware is ready.

I have tried both calling the bootloader from C code, using the method posted on Youtube, and also calling it from my startup assemble code, using the method Clive has suggested in the forum, as follows (I am using IAR):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;

;; Default interrupt handlers.

;;

THUMB

PUBWEAK Reset_Handler

SECTION .text:CODE:REORDER:NOROOT(2)

Reset_Handler

LDR R0,=0x1FFF0000

LDR R1,[R0,#0]

MOV SP,R1

LDR R0,[R0,#4]

BX R0            ;debugger shows 0x1FFF4ABF in R0 at this point

Unfortunately, both methods display the same behavior - I cannot connect to the bootloader using the demo program. If I use the debugger, I can hit a breakpoint at the start of the bootloader (at 0x1FFF4ABE) , and can trace through it until I get bored, but as soon as I hit run, I hit a breakpoint back at the BX R0 line above, as if a reset is occurring, or the bootloader is jumping back to the start of the application. This made me suspect the dual boot mode of the 429, but I used ST-Link to verify the BFB2 bit in the options byte is cleared, so no dual boot should be taking place.

Any ideas?
32 REPLIES 32
dthiffeault9
Associate II
Posted on October 13, 2015 at 19:15

one small question looking at the code you posted. Why this:

LDR     R0, =0x00000000 ;  OR GENERICALLY MAPPED AT ZERO

instead of this (commented out):

LDR     R0, =0x1FFF0000 ; ROM BASE

I was under the impression that for my MCU, the ST embedded bootloader was at 0x1FFF0000.

Thanks!

Posted on October 13, 2015 at 20:14

Ok, as the comments explain, we are mapping/shadowing the ROM into the ZERO address space. ie it decodes at BOTH the 0x00000000 and 0x1FFF0000 basis, over whatever length it has. This is how the processor starts, it always starts with a Vector Table at zero, what's usually mapped there is defined by the BOOTx pins, which in the F4 case get latched into the aforementioned register. The PC loaded points into the 0x1FFFxxxx space, and off it goes at it's native address. Subsequently you can change SCB->VTOR to point the Vector Table at some other suitable address. At reset I think you'll find it's zero.

If the System Loader watchdogs it's going to reset the chip based on the actual settings of the BOOTx pins. If that's your user space flash code, then that's what will execute. I haven't spent a lot of time qualifying all the exit paths. I have used this methods on F205/F405 parts to reset into the System Loader's DFU mode, and successfully update firmware that way. You'll need to do your own validation work.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dthiffeault9
Associate II
Posted on October 14, 2015 at 16:21

Hi,

ok I see. 2 things I notice while testing. 1- breaking in the Reboot_Loader assembly function, I get this message: ''The stack pointer for stack 'CSTACK' (currently 0x20002D40) is outside the stack range (0x20003870 to 0x20007870)'' 2- Also, now I think I'm in the bootloader. When breaking the code, I always end up at addresses like 0x1FFF0xxx, which is good I think! Now, I can't connect via UART using the loader program. That UART is used normally by my application, but I'll need to validate. EDIT: had a little connection problem. Bootloading like a charm. I'm still interested in the CSTACK warning though. Does it matter?


dthiffeault9
Associate II
Posted on October 14, 2015 at 18:27

Ok, I did some experimentations. I bootload A1 and using the Command Line Flash Loader from ST, I can send my new firmware and it works.

Now, if I cut the power while loading the new firmware (in the erase phase or in the downloading phase), I brick my MCU. Since the hardware Boot Pins are not setup correctly, I don't go back into the ST Embedded Bootloader.

Is there a work-around? I've tested some ideas, like loading to Flash 2 before erasing and loading Flash 1, etc... but didn't work.

Posted on October 14, 2015 at 18:38

Which is why people don't tend to erase the entire part, and have a strategy that has a small loader, and recovery mechanism in the base of flash, which checks and qualifies an ''application'' image placed slightly higher in the flash. The app only gets called if it is valid/complete, and if not the loader falls back to a recovery method. There really shouldn't be a need to replace the loader in the life of the product if it is written with thought and rigour.

Looks at some of the IAP (In Application Programming) examples, or which there are many.

If these concepts are alien to you, might a suggest a book on the topic area?

http://shop.oreilly.com/product/0636920017776.do

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dthiffeault9
Associate II
Posted on October 14, 2015 at 19:18

alright thanks.

I'm used to write my own bootloaders actually. Using the ST one, I was checking if I could avoid that.

So yeah I'll need to do a small loader that will rest at sector 0 and will validate and if invalid, will jump right to the embedded bootloader. I prefer that to writing my own big bootloader.

Thanks!

jerry_my
Associate
Posted on October 28, 2015 at 10:23

Hi Clive,

I'm doing a project on bootloader. And I tried using your code but it just won't compile in Keil.

...

...

LDR     SP,[R0, #0]     ; SP @ +0 <- Error here, in THUMB, LDR only accepts R0 to R7. If I'm not mistaken, SP is R13??

...

any help will be greatly appreciated. Thanks in advance.

EDITED: I'm using STM32F030R8T6 and KEIL v4.54

Jerry

Posted on October 28, 2015 at 12:35

You are taking code from a thread about a different part. You'd have to load SP through another register, and the peripheral registers for mapping the memory are different anyway.

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Jump%20to%20USB%20DFU%20Bootloader%20in%20startup%20code%20on%20STM32F042&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=575]This thread covers F0 parts

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
jerry_my
Associate
Posted on November 01, 2015 at 07:21

Hi Clive,

Thanks a lot for your advice. it works!

Thanks and best regards,

Jerry
ambrose
Associate II
Posted on March 24, 2016 at 17:23

Hello Clive, I am sorry to put this in an old thread. But I am just trying to get my head around the bootloader/in application programming. I have looked through ST examples and have gone through several threads here (some you recommended), but I am still at sea about how to go about it.

The product(s) is(are) rack-system where we have a control board that interfaces with the board via I2C. I need to be able to update the firmware of 3 or more boards in one click of a button - meaning different I2C addresses. I am not really sure how to start with the bootloading. I have looked through the ST example. I am using STM32f334. T