0

I have a codebase that has been working fine with arm-none-eabi-gcc. I wanted to keep most of my source files in C while adding C++. I had some issues compiling this but finally seemed to successfully compile for my device (Atmel ATSAMG55).

However, when I go to flash the device in Atmel studio, I get an error

The Intel Hex file does not start with ':'

Note, I'm just programming it through an Atmel ICE programmer/debugger and Atmel studio. I'm compiling through arm-none-eabi-gcc and arm-none-eabi-g++ and a custom make file.

I opened up a hex viewer of my .hex output to find mostly 0x00000000 but a bit of "real" data at the beginning and end. Images below.

Top of Hex File

Bottom of Hex File

Clearly, if the compile process occurred properly, it wouldn't be mostly 0x00000000. However, without any compiler errors I'm a bit stuck on where to start. Below is an excerpt of the "core" of my make file. 

all: $(TARGET)


# Create binary from object files and external libraries
$(TARGET): $(OBJECTS_C) $(OBJECTS_CXX) $(S_SRCS)
    @mkdir -p $(dir $@)
    $(CXX) $(CXXFLAGS) $(C_INC) -T$(LDFILE) $(LFLAGS) -o $@
    $(TOOLCHAIN)-objcopy -O binary $@ $(basename $@).bin


out/$(PLATFORM_MCU)/obj/%.o: %.cpp
    @mkdir -p $(dir $@)
    $(CXX) $(CXXFLAGS) $(C_INC) -o $@ -c $<

-include $(DEP_CXX)

out/$(PLATFORM_MCU)/obj/%.o: %.c
    @mkdir -p $(dir $@)
    $(CC) $(CFLAGS) $(C_INC) -o $@ -c $<

-include $(DEP_C)

.PRECIOUS: $(PRECIOUS)


.PHONY: all clean


clean:
    rm -rf $(CLEAN)

Most of what is above that is variable definition and setting flags. I'm relatively confident in that as this was working fine with pure C. It was only when I added the second set of object/source dependencies that I started having issues.

Has anyone seen a compile issue like this and have any input on where to start debugging? Thank you!

House Targaryen
  • 69
  • 7

2 Answers2

0
  • From the error message you are getting, your programming tool is expecting a file in Intel Hex format.
  • The file you are providing a hexadecimal dump of cannot be a file in Intel Hex format, since this format uses the ASCII encoding.

  • The screen shots you provided are those of a file in ELF format: the first bytes are:

    00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|

  • Your make file seems to be producing a binary file, while you need a file in Intel Hex format:

$(TOOLCHAIN)-objcopy -O binary $@ $(basename $@).bin

You therefore probably need to add the following line right after the one above:

$(TOOLCHAIN)-objcopy -O ihex $@ $(basename $@).ihex

The resulting file (.ihex) should be the one to be used with your programming tool.

Frant
  • 5,382
  • 1
  • 16
  • 22
  • Hi @Frant, thanks so much for the response. You make a great point. The mention of "binary" is from legacy code, I'm really not sure the signifigance. However, I tried your change but it did not work. Note, my $(TARGET) is something like /mcu/obj/firmware.elf. Historically with gcc, this has worked as is and I have been ending up with both .bin and .elf files. Because it has worked with pure gcc, I'm really concerned that I'm doing something incorrect in the two sections defining %.o: %.c and %.o: %.cpp. – House Targaryen Jun 13 '18 at 20:09
  • How did it not work exactly ?did you get a .ihex file ? Did you get a different error message from your programming software ? Was the content of the flash different from expected ? any other hints ? – Frant Jun 13 '18 at 20:22
  • It did in fact generate a .ihex file, as well as the target .elf file. When attempting to flash the iHex file through atmel studio and the Atmel ICE programmer/debugger, the error was "file contents does not map to any valid device memory for programming the flash". I know it said it needed an iHex, but in the past I have successfully flashed .elf, .bin, and .bin using just c or just c++. This feels like an issue with linking files because the data in the output is so sparse. Do you think it has something to do with trying to use gcc and g++ in one makefile? – House Targaryen Jun 13 '18 at 20:59
  • Oh, I forgot add, yes the content of the iHex file was different. It was all of 10 bytes this time, really not sure what that means. – House Targaryen Jun 13 '18 at 21:00
0

It looks like the issue stemmed from incorrect flags. I know earlier I mentioned that it may be fair to assume the flags were correct. I no longer think that was true. After changing the flags (and updating some hardware specific files to recognize hard float abi's) it seems to be working. Thank you to everyone who helped me out.

House Targaryen
  • 69
  • 7