Hex file produced by STM32CubeMX Makefile does not work

[Manuel Forcen Munoz]

Posted on May 01, 2018 at 00:44

I'm trying to create a STM32CubeMX project using Makefiles. I implemented a simple Blink example which toggles PC13 pin of a stm32f103c8t6 MCU.

When I launch the 'make' command, several errors of 'multiple definitions' are shown, but they are easily fixable by removing duplicated source files in Makefile (it might be a bug).

After fixing this, the 'make' command generates an elf, a bin and an hex file. I tried to flash bin and hex files in different ways: using stm32flash through serial, using st-flasher through st-link and using openOCD, but nothing made the led blinks.

After that, I tried using SW4STM Eclipse-based IDE, using exactly the same program, but in this case, compilation is successful, flashing is successful, and then, the program works.

I'm trying to replicate the building and flashing proccess that Eclipse follows in order to replicate it in that Makefile.

Any ideas of what is wrong?

I'm using Ubuntu 18.04, with arm-gcc ubuntu repository version.

#hex #makefile #stm32 #compilation #flashing #bin #learning

[Tesla DeLorean]

Posted on May 01, 2018 at 01:00

Linker options or Linker Script?

Review the .MAP generated by the Linker, make sure the code and vectors are suitably situated in FLASH, and the variables, data and stack are within RAM and suitably aligned.

Use a debugger, understand what the code in the micro is doing. Can't drive a debugger, review the listing file statically.

Keil's debugger can work with code in ROM with no source code, I'd expect GDB could be used in the same way, and the ST-LINK Utilities as a simple debugger.

Make SW4STM download and debug your .ELF from the makefile.

[Manuel Forcen Munoz]

Posted on May 01, 2018 at 01:32

The linker file I use is the one that STM32CubeMX generates automatically, with no changes.

Are there a way to compare two elf files, two bin files or so?

[Tesla DeLorean]

Posted on May 01, 2018 at 04:23

If you have an ELF dumping tool you could a side-by-side of the output with a Merge tools, could do similar things with .MAP and .LST

Not really a practical way to do a binary compare in the way you want, even simple difference in code can precipitate large cascading differences at the binary level.

Static analysis of the non-functional image's listing file would likely be quite instructive.

[Manuel Forcen Munoz]

Posted on May 02, 2018 at 00:00

Apparently, linker was trying to link with arm version instead of thumb version.

In order to fix this, you have to specify the location of the newlib thumb version. In my case, I added to LDFLAGS variable the flag -L/usr/lib/arm-none-eabi/newlib/thumb

[Manuel Forcen Munoz]

Posted on May 01, 2018 at 22:57

After installing gdb (it was difficult for me, because of the lack of packages in Ubuntu), I have found out that the problem is in the function __libc_init_array. It raises a Hard Fault exception, so the MCU halts itself.

I have been looking for information on Google, it seems to be that the linker uses a version of libc compiled against ARM instead of Thumb code. Any ideas on how to change it?

Thanks in advance.

[Tesla DeLorean]

Posted on May 02, 2018 at 00:04

That makes sense, in the similar way to associate Include Paths