2017-02-09 11:35 AM
Hi Everyone!
I am developing a firmware upgrade app for a custom board using an STM32F417.
The custom PCB does not have pin outs for Boot0 and Boot1 pins.
I have written a control app (console application) in C# and I can control the 417 through USART1.
I found the following code on an ST video, and I've added this function to the firmware code.
For testing, I hard-coded a call to this function. I've stepped through the code in the debugger and
it makes it to the while loop and should be ready to start running the bootloader.Here is the bootloader jump function:
I have tried to connect with the bootloader two different ways. First, I tried in C# code to send the byte the 417 is waiting for 0x7f. I verified on an oscilloscope that the byte is being received, but there is not response. Secondly, I tried to start the bootloader using the Flash Loader Demonstrator from ST. I configured it to connected on the correct Port Name, 115200, 8 data bits, even parity, and 1 stop bit as specified in the application note AN3155.
Application note AN2606 specifies the flash address of 0x1FFF0000. For the set-up of the jump, it specified jumping to that address plus 4, so 0x1FFF004. It also specified setting the Master Stack Pointer to the address located at the top of flash memory, which I found to be 0x801D0020.
What could be preventing the connection to the bootloader?
Thank you!
2017-02-09 02:14 PM
This type of question comes up weekly,
How can the STACK conceivably be in FLASH? That's going to fault. It is definitely not what the word at 0x1FFF0000 specifies.
The System Loader expects to be entered in near reset conditions, not will the PLL running, interrupts disabled, etc. You also want to map the ROM at zero to replace the BOOT0=1 configuration.
#it
2017-02-09 03:15 PM
Why are posts being moderated, FFS
https://community.st.com/0D50X00009XkgH0SAJ
2017-02-09 03:16 PM
How can the STACK conceivably be in FLASH? That's going to fault. It is definitely not what the word at 0x1FFF0000 specifies.
The System Loader expects to be entered in near reset conditions, not will the PLL running, interrupts disabled, etc. You also want to map the ROM at zero to replace the BOOT0=1 configuration.
2017-02-09 11:30 PM
Thanks for the response, Clive!
I am an engineering student (embedded systems) and this is the first time I am seeing a lot of this stuff. I have never worked with flash or bootloaders before.
The video I saw from ST said (and is confirmed in the application notes) that the function I posted sets up the conditions for the System Loader. Only the HSI clock is running (no PLL), the __set_PRIMASK disables interrupts, etc. I connected to the 417 using STLink Utility and found a different word stored at 0x1FFF0000 than I found in the memory map in Keil - 0x20001D80.That would be in SRAM, right? I tried to connect with that address and get a message that there is no response from the target.What does 'map the ROM at zero' mean?
I saw your post (from 2014) with assembly and the Reset Handler, but haven't seen anything like that in any of the ST documentation. Is there a source for learning how to use the assembly file to boot into the bootloader?
Any input is greatly appreciated!
2017-06-23 03:51 PM
I got this working some months ago, but was busy finishing up school.
The advice from CliveOne was correct, if a little opaque. Here is how I adapted his pseudo-code.
I wrote a function to save a 32-bit word to SRAM at an unused address. This function will be triggered by some event in your normally running code. The SystemReset() function appears below.
void SwitchToBootloader(void)
{
*((unsigned long *)0x2001FFF0) = 0xDEADBEEF;
SystemReset();
}
Below is assembly code from the startup_stm32f417xx.s file from my project. All the below code was found in the ST32 forum or somewhere on-line. Once you call SystemReset(), you will wind up in the Reset_Handler() function. If you have just called SwitchToBootloader(), the 0xDEADBEEF word will be in memory and the handler will branch to the Reboot_Loader(). The Reboot_Loader() will start running the built-in bootloader and once you are finished with your bootloader commands, there is a GO command that will allow you to jump to any address �? in my case I jumped back to the beginning of Flash to start executing the freshly updated firmware.
Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main
;...
LDR R0, =0x2001FFF0 ; Load address of WORD placed in SRAM from MAIN.C
LDR R1, =0xDEADBEEF ; Load same value stored above to a register
LDR R2, [R0, #0] ; Read the current value stored at 0x2001FFF0
STR R0, [R0, #0] ; Erase the value store in SRAM (next restart will be normal)
CMP R2, R1 ; If values match (DEADBEEF), jump to bootloader, otherwise continue startup
BEQ Reboot_Loader ; Jump to Reboot Loader below
; Normal startup path
LDR R0, =SystemInit
BLX R0
LDR R0, =__main
BX R0
ENDP
;...
; Vector into System Loader
; Sets up board for bootloader mode
Reboot_Loader PROC
EXPORT Reboot_Loader
LDR R0, =0x40023844 ; RCC_APB2ENR
LDR R1, =0x00004000 ; ENABLE SYSCFG CLOCK
STR R1, [R0, #0]
LDR R0, =0x40013800 ; SYSCFG_MEMRMP
LDR R1, =0x00000001 ; MAP ROM AT ZERO
STR R1, [R0, #0]
LDR R0, =0x1FFF0000 ; ROM BASE
LDR SP,[R0, #0] ; SP @ +0
LDR R0,[R0, #4] ; PC @ +4
BX R0
ENDP
SystemReset PROC
EXPORT SystemReset
ldr r1, =0xE000ED0C ; NVIC Application Interrupt and Controller
ldr r0, =0x05FA0004 ; Magic
str r0, [r1, #0] ; Reset
b .
ENDP
I hope this helps!