STM32F429 Discovery FW_Upgrade hex to bin

[johnbharrellsel]

Posted on April 25, 2014 at 02:40

I have the cool STM32F429 discovery board.

I am wanting to use the FW_Upgrade project as a test system for my own product release but I am having a problem getting started. The FW_upgrade project comes with the software download from ST for the STM32F429 discovery board.

I compile/link the MDK-ARM FW_Upgrade project and get a .hex output which I use to program the board. I then load on a USB key one of the two binaries (.bin) which come with the project in the binary folder, either SysTick or LTDC_ColorKeying, and rename to image.bin. And as documented, the image.bin gets downloaded from the USB key and runs.

Question 1: I have a lot of .hex programs that I would like to convert to a .bin and load as image.bin on a USB key to see if they run. I have used different hex2bin, and nothing seems to work.

So I tried this. Also on the software download from ST are a number of peripheral projects, one of which is SysTick. I go in there, compile/link this project with MDK-ARM and get a .hex output. For a test, I program the board with the .hex directly and it works. I then convert the .hex to .bin, rename it image.bin and put on USB key. After I program the board with the FW_Upgrade.hex, and insert the USB key, I get a green light, but then nothing. I am guessing that it gets downloaded, but then jumps to neverland, which makes me think that I am not converting the .hex to .bin correctly.

How did the .bin that are in the ST software download binary folder for the FW_Upgrade project got converted from a .hex. Question 2: How do I do that, in other words how do I convert any .hex to .bin so that I can put any image.bin on USB key and have the FW_Upgrade load it properly.

Thanks,

[Tesla DeLorean]

Posted on April 25, 2014 at 02:52

Are you sure the other files you have built are linked at the correct address?

[johnbharrellsel]

Posted on April 29, 2014 at 20:20

Thanks Clive, I performed quite a few tests and code debug.

I was hoping that I could use any .hex and just use a hex2bin converter with appropriate offset applied, but I don't think this method works. So as per documentation and your instruction, I changed the target application start to be 0x08020000. The .hex and resultant .bin does get build correctly. The FW_upgrade seems to download the .bin correctly, but it still doesn't execute properly. I don't see any documentation that says that any other ROM/RAM or ISRs need to change, but I suspect that the .data and stack may need to also need a change of address (and maybe ISRs?). I just want to build the SysTick and the LTDC_Colorkeying binary similar to what is in the FW_upgrade binary folder. I will then know that I can build the FW_upgrade and also binaries properly. Thanks,

[Tesla DeLorean]

Posted on April 29, 2014 at 22:11

I'm not using hex2bin, I have several other tools that do equivalent things, but you need to be sure the base address is correct in the .HEX as it is lost in the transition to the .BIN. Once you have the .BIN you should inspect that, and double check you see the vector table in the first bytes.

The other consideration is the base address programmed into the CPU for the vector table (SCB->VTOR), this typically gets programmed in SystemInit(), within system_stm32f4xx.c This has to reflect your new higher loading address. And finally you should be cautious about what SystemInit() does, most versions make assumptions about what clock sources are being used (nominally HSI from reset), and bringing up the PLL, this clearly isn't necessary if the part is already up and running from HSE/PLL. You might want to look at other IAP examples that ST has provided (USART, ETHERNET, etc) Debugging can be difficult, if you have a USART, GPIO or LEDs you can use those to output diagnostic or way-point indications so you can see if something started, and how far into the code it got. To be effective you have to start that early, in the ResetHandler. You can also add debug and diagnostic output to the firmware update boot loader to see where that is, and what it's doing, and perhaps add a Hard Fault handler to catch problems as your other code loads/starts.