2022-04-25 01:56 PM
Hello there ST Community,
I'm currently working in a way to update a device using a USB stick. Instead of implementing a normal bootloader, I decided to try a different approach: have the updater (and all its needed libraries) installed in a fixed region of the flash, while the rest of the program is installed in a modifiable part of the flash. During update, my updater erases the modifiable part of the flash, reads the USB stick and rewrite the flash with the new program.
This part is working well, and the program is perfectly capable of rewriting the flash. The problem arises after the MCU is reset. During the initialization it suddenly triggers a hard fault (more details below) - this is after some functions are completed.
The difference between the initial program and the new one is simply the addition of a couple of functions. When I use the same old program as the new one (which basically means reprogramming the flash) the process works fine and no hard fault is generated. The new program also works fine when tested separately.
In the hard fault my CSFR register has the bits BFARVALID and PRECISERR set. My BFAR register has a random number that does not fall under the valid address range. The problem is, when I investigate the instruction in the address pointed by the PC register (by debugging the new program separately), it is simply a branch instruction in a random function. Basically, debugging the hard fault didn't point me to the problem.
Also, I created a second new program with different functions added. This time, the instruction that causes the error is a Load Register Byte (which makes more sense but still doesn't help).
I'm wondering if the problem is my poor approach to the uploader problem. Is there a better solution? Does anybody have an idea about what might be causing these problems?
Thank you in advance.
2022-04-25 02:47 PM
Which STM32 are we talking about here?
Does basic checksumming/validation of the written data appear consistent with directly downloaded and functional code images?
2022-04-25 03:26 PM
STM32F407VG (STMF4-Discovery board) with limited RAM and FLASH (since end product will be running on a STM32F411RC).
About the checksum, that is a good question... Indeed both images (the updated and the standalone) should be equal, but I don't know how to verify the checksum after my update operation (can you do it using a debugger?).
To be honest I don't think data is corrupted; else using the updater with the original image would not work...
2022-04-25 03:46 PM
I replied in the wrong place... I'll copy here.
I'm using a STM32F407VG (STMF4-Discovery board) with limited RAM and FLASH (since end product will be running on a STM32F411RC).
I found out how to read the checksum using the ST programmer. And indeed, the checksum is different if I use my method compared to programming directly. I'm currently investigating this.
2022-04-25 04:06 PM
Just a quick update.
If I reprogram using the same image that is running, the checksum remains the same.
The difference is between my new program updated from the old program compared to the new program programmed directly.
2022-04-25 05:40 PM
> The difference is between my new program updated from the old program compared to the new program programmed directly.
Use STM32CubeProgrammer, download the flash in both instances and compare to determine where the differences are. Use that information to troubleshoot what is going wrong.
Be aware of the default behavior of only erasing the necessary pages, rather than the entire flash.