2014-05-01 04:26 PM
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_HandlerLDR 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?2015-10-13 10:15 AM
one small question looking at the code you posted. Why this:
LDR R0, =0x00000000 ; OR GENERICALLY MAPPED AT ZEROinstead of this (commented out):LDR R0, =0x1FFF0000 ; ROM BASEI was under the impression that for my MCU, the ST embedded bootloader was at 0x1FFF0000.Thanks!2015-10-13 11:14 AM
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.2015-10-14 07:21 AM
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?
2015-10-14 09:27 AM
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.2015-10-14 09:38 AM
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
2015-10-14 10:18 AM
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!2015-10-28 02:23 AM
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.54Jerry2015-10-28 04:35 AM
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¤tviews=575]This thread covers F0 parts2015-10-31 11:21 PM
Hi Clive,
Thanks a lot for your advice. it works!Thanks and best regards,Jerry2016-03-24 09:23 AM
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