0
\$\begingroup\$

I am writing a python script similar to STM32Loader that can write a hex formatted program to the flash of an STM32F0.

I have managed to use the system boot-loader to write the hex file to the chip and verified it with STM32CubeProgrammer, but the chip won't boot. If I flash the same hex file with the STM32CubeProgrammer the chip boots fine.

The script flashes the hex file on to the chip by first erasing the flash, then reading the hex file and creating a memory map from it, and using that map to load the correct data into the flash of the chip.

I used this Wikipedia article to decode the hex file. The STM32F0 hex files generated by gcc only uses the data types for data, end of file, extended linear address and start linear address. I do not know what to do with the line for start linear address, but if I remove it from the hex file and flash it with the STM32CubeProgrammer the chip boot with no issue.

Is there something I'm missing?

\$\endgroup\$
  • 3
    \$\begingroup\$ Why not use one of the variety of existing software solutions for this? How do you think anyone else could know what is wrong with your code? Try reading the memory back out with SWD to a flat binary and comparing it to one made from the original elf. \$\endgroup\$ – Chris Stratton Jul 23 '19 at 17:23
  • \$\begingroup\$ I tried that, no differences I could find, so I tried writing the downloaded file to the flash instead. The chip still did not boot. I'm just looking for ideas of where the issue could be, I am not expecting anybody to debug my code. I think there is something I am missing while writing the hex file to the chip. \$\endgroup\$ – G. Meeser Jul 23 '19 at 18:04
  • 1
    \$\begingroup\$ Did you verify the differences with a diff tool? Write with working tool, read with working tool. Then write with your tool, read with working tool. Diff. Or just use binary file, they are simpler as hex files are rarely continuous unless converted from bin file. \$\endgroup\$ – Justme Jul 23 '19 at 18:16
  • \$\begingroup\$ If the chip doesn't "boot" then using SWD is the way to find out why. Run your non-functional code for a second, then pause execution and see what is executing...you are probably stuck in a fault handler or an unexpected infinite loop. \$\endgroup\$ – Elliot Alderson Jul 23 '19 at 18:18
  • \$\begingroup\$ @Justme, that was the process I used, STM32CubeProgrammer has a function where you can check the program in the flash of the chip against a hex file. However I discovered that that function doesn't check the whole file, only the part of the file currently in the view window. \$\endgroup\$ – G. Meeser Jul 24 '19 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.