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.
Best Answer
No, it's the other way round. When you compile a project in Eclipse,
.o
object files.elf
fileobjcopy
generates a.hex
file from.elf
size
, but this last step is purely informational.The debugger however works with the
.elf
from step 2, because it has symbols and other debugging aids in it, which are lost when converting to.hex
. Therefore, I'd take a very close look at step 3, and perhaps at the.elf
file too.This is how step 3 should look like in the eclipse build console window
First, check if there are any warnings or other suspicious signs. Is it regenerated when you remove it, and build the project? And when you remove the
.elf
? Are the file timestamps correct? Try to repeat it from the command line. For that to work, you'll have to specify the full path toarm-none-eabi-objcopy
in your toolchain, or include it in yourPATH
. Make sure that the toolchain path is properly set in eclipse, and there are no other versions ofobjcopy
lying around, especially in yourPATH
.You can examine the
.elf
witharm-none-eabi-objdump
. List the "directory" with-h
, it looks like thisCheck the
LMA
andSize
fields for each section. Is there an overlap? Dump the contents with-s
and examine it around the problem address.