I have a design using an STM32F105. My application written in C; using Eclipse and gcc. I have been using Eclipse (with OpenOCD and an ST-LINK/V2 programmer) to write the firmware to the devices. Now I need to program many devices and am looking for a faster method.
The ST-LINK Utility software seems to be a fine choice. You can point it to a .hex file and set it into "automatic mode". It then detects when a device is connected to the programmer and writes to it. Then you connect another device which will get automatically written. Very smooth.
So here's the problem: It appears that the firmware written to the device by Eclipse is actually different than the Eclipse-generated hex file.
This is what I'm seeing:
- I program Device#1 via Eclipse. I remove the programmer, reset the device, and it works fine.
- I find the Eclipse-generated .hex file (.../Debug/application.hex).
- I program Device#2 using the ST_LINK Utility and this file. I remove the programmer. The code doesn't run, even after a device reset.
- I use the ST-LINK Utility to read the (working) code directly from Device#1.
- I use the ST-LINK Utility to program this code onto Device#2. Now, Device#2 works correctly.
OK, so the generated .hex file must be wrong. I can use the ST-LINK utility to compare the two hex files (from steps 2 and 4). It shows that the files are identical until the end:
(click to zoom if you need to)
Finally, my questions:
Why is the generated .hex file incorrect? Perhaps Eclipse uses gcc to create the hex, and then modifies it en route to the device? How can I make Eclipse output a hex file that matches the code that it programs to an actual device?
Note that I am building the "Debug" configuration. When Eclipse connects to the target device it programs the code and allows me to debug. If I remove the debugger hardware, the device still functions. That is, the code works fine without the debugger attached.