STM32 flashing through boot loader fails (UART1)

1
votes

I have an STM32F103 that I'm re-flashing remotely using a different MCU through its UART port (using the boot loader). It works perfectly fine, I have multiple devices that have been successfully flashed with the right code. But occasionally there comes along a device that has stopped working because the STM32 code flashed is not the right one. The whole bin file is flashed using the other MCU, but the STM gets "bricked" (not exactly bricked, it's just has a wrong code). When I re-flash the device using my PC everything is working again. Why would the hex wrote into to the STM fail?

Brief:

*Using UART bootloader to flash STM32F103

*Occasionally this method fails, and so the STM stops working.

*Is there a method to check if the data written into the code space is valid?

*The STM is not bricked, it's just a wrong code inside the flash. When I read back the flash from the code space, this is smaller than the file that should have been flashed.

*I'm using the STM in system boot mode. [AN2606]

1
embeddedstm32bootloader
is this your bootloader or the built in one? how can you brick the built in one? This sounds like a software/tool question not an SO question. Did you write your own bootloader and/or tool to talk to the ST bootloader? Or are you simply using off the shelf tools? - old_timer
Hi old_timer, I'm using the STM in system boot mode, using the inbuilt bootloader. As mentioned in my edit above, I (just now) read back the flash and found that the STM flash code is a not the same size as the code (bin file) I have. It seems to be around 200(ish) bytes short. - clmno
where is the point where it breaks? is it at an obvious boundary? (flash block, one complete message/packet of data at the end didnt work, or one in the middle, etc?) - old_timer
smaller means you read 0xFFs where that code should be? - old_timer
There is no obvious point it breaks. My second MCU (NRF51822) reads the file to be flashed into the STM from an SD card and does the steps mentioned in AN2606. And we make sure the whole file is flashed (We write into the flash - sector by sector - in a for loop). Only after we are sure the whole file was sent through UART the NRF will get out of the flashing loop. Yes, smaller means the rest of the data are 0xFFs. We use STLink Utility to read the flash, which reads till 0xFF is seen in the flash memory. - clmno

1 Answers

0
votes

You can read the data written in STM32's flash using the boot-loader command just the way you write the data (bin file) to flash. This way, you can check if the data written (or new code) written into flash is same as the original binary file. Re-flashing is successful only if these two match, else you can re-attempt to flash the STM32.