2018-05-15 10:01 AM
I have a firmware updater for stm32f417, written in C#, that does a software jump to the bootloader and uses the USART protocol (AN3155) to erase and install the firmware to flash.
The newest version of our board has a jumper for configuring the boot pins. Normally, boot0 and boot1 are held low (flash startup), removing the jumper sets boot0 high, which configures a bootloader, or System Memory, startup.
Running the updater during normal operation of the board configures the system and jumps to the bootloader, and completes an upgrade of the firmware.
Removing the jumper and starting the board in the bootloader causes the updater to fail (System.TimeoutException). The update is normal until it reaches sending the Extended Erase Memory command; sending the command gets a ACK (0x79) back from the board, but I receive a timeout exception before the erase is completed.
Since the update occurs while the bootloader is running, the only difference seems to be HOW the system arrives in the bootloader. Here is my code that sets up the system before entering the bootloader:
Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main
;...
; UPGRADE STARTUP path
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) [stores address as value for R0]
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
When using the boot pins, the start of the update is normal, the serial port is opened and I receive an ACK from the connection to the USART.
Here is readout from the Output window during the upgrade:
Serial Port is OpenComm byte = 0
Comm byte = 0
Comm byte = 0
Comm byte = 0
Comm byte = 121
Erasing flash memory...
Erase byte = 31
Erase byte = 31
Erase byte = 121
Exception thrown: 'System.TimeoutException' in System.dll
The thread 0x3070 has exited with code 0 (0x0).
The thread 0xfdc has exited with code 0 (0x0).
The thread 0x2074 has exited with code 0 (0x0).
The thread 0x1934 has exited with code 0 (0x0).
Exception thrown: 'System.TimeoutException' in System.dll
121 (0x79) is ACK for commands sent to the board. So, the erase procedure starts, but fails with a System.TimeoutException before the erase is complete.
Running a test on the software jump to bootloader shows that a single page erase can be completed and continue on to write:
Erasing flash memory...
Erase byte - page 2 = 121
Erase Complete byte - page 2 = 121
Write byte = 121
Does anyone have experience with performing an upgrade by configuring the boot pins. Since my software jump version works, I thought the boot pin version would also work. Do you need to do anything other than configure the pins and apply power to the board?
Thank you!
#uart-bootloader #stm32f417 #c#-programming #update-firmware #boot-pins2018-05-15 10:07 AM
>>
Does anyone have experience with performing an upgrade by configuring the boot pins.
Yes, and not had a problem.
Would perhaps examine rise time in supplies, look at NRST (ability to drive low with button, or external POR), and signal transitions on interfaces being monitored, 1.5K pull up on PA12?
2018-05-15 11:00 AM
NRST does not have an external pull-up, but we can add one easily.
2018-05-15 12:44 PM
Checking on rise times, power comes from DC-DC converter with caps, shouldn't be too fast or too slow
Checking on NRST, I believe there is an external pull-up added
How do signal transitions impact the bootloader?
PA12 is not connected on our board.
What exactly am I looking for in this scenario, where the bootloader is running (connects, and processes commands sent), but failing on tasks that it can accomplish when I do the software jump to bootloader?
As far as I know, the bootloader is a black box. Is there any way to see why it might fail on an erase command?
2018-05-15 04:53 PM
The more common problem is when people let BOOT0 float then end up in the ROM and not the FLASH, as BOOT0 is sufficiently high as the supply ramps, reset releases and the processor becomes sentient.
>>How do signal transitions impact the bootloader?
It is looking for 4 or 5 different modes of connectivity, and picks ONE. If that's the wrong interface, or the wrong baud rate, you need to reset and start over.
Erasing/Writing are supply dependent. Might check VCAP caps/voltage. Does reading out the whole memory before erasing change behaviour? Is the Erase timeout sufficient?
Why is it sending NACK? Are you sure it is actually erasing here