0

I am cross-compiling for an ARM Cortex-M using CMake for the configuration of the project.

I've been so far successful in setting up the project and the executable is being generated. However, to flash the board I need an ".hex". file.

I've followed the Nordic nRF5SDK examples for gcc to get some clues about the compiling and linking stages and pass them to the CMake routines.

However, I cannot generate any ".out" file to proper extract the ".hex" file. I've played with the compiling flags and linker flags but without success.

I've setted up the init flags in the toolchain file as well as the compilers, the hex is being generated with a custom command:

(...)
add_executable(main main.c)
target_link_libraries(main sdk_lib)

add_custom_command(
        TARGET
            main
        POST_BUILD
        COMMAND
            ${ARM_OBJCOPY} -O ihex ${CMAKE_CURRENT_BINARY_DIR}/main${CMAKE_EXECUTABLE_SUFFIX} ${CMAKE_SOURCE_DIR}/main.hex
)
(...)

The issue is that I am using the binary file for extracting the hex, instead of a proper ".out" file.

How can I generate it without using another custom command parallel to the main build?

P.S.: Here is the current state of the project https://github.com/NunoRVicente/cmake-arm-toolchain

R. Vicente
  • 11
  • 1
  • You can't. You have to invoke objcopy. Which is not that bad, once you start debugging, you are going to need elf files anyway. Make from it a [custom target](https://gitlab.com/Kamcuk/kamillibc/blob/master/cmake/cross-compiling-utils.cmake#L12) tho. `to flash the board I need an ".hex". file` - That's strange. Openocd and gdb can flash elf files. – KamilCuk Sep 13 '19 at 08:52
  • `You can't. You have to invoke objcopy.` That's what I am doing now. But objcopy works with object files, and that's what I am having troubles with. Well, you're right. When i say I need an ".hex" I am actually using nRF Command Line Tools, and nrfjprog only uses ".hex". I am going to explore a bit more OpenOCD as I am working with CLion and it might be a better option. – R. Vicente Sep 13 '19 at 10:03
  • Well, I have `st-flash` that is best with only hex, I just wrap it for simplicity with [such script](https://gitlab.com/Kamcuk/kamilscripts/blob/master/bin/st-flash-auto.sh#L3). `objcopy works with object files, and that's what I am having troubles with` - why is it a trouble? You will always get an elf file from compilation. Then you only `objcopy` it. – KamilCuk Sep 13 '19 at 10:18

1 Answers1

0

why is it a trouble? So I figured out where the problem starts. Basically the elf file is not being well generated, so naturally the .hex has problems as well.

The issue here now is to understand why the elf is broken, and it is overtaking my knowledge. I've building the sdk_lib as STATIC with the SDK code and included the directories where the header files are. I've added the executable and linked the main with sdk_lib.

When I analyse the compilation process, the OBJ files are all being generated and at the end thinks are linked. But there is something odd that I can't understand.

[95%] Building C object CMakeFiles/main.dir/main.c.obj
/opt/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc -DBOARD_PCA10040 -DBSP_DEFINES_ONLY -DCONFIG_GPIO_AS_PINRESET -DFLOAT_ABI_HARD -DNRF52 -DNRF52832_XXAA -DNRF52_PAN_74 -D__HEAP_SIZE=8192 -D__STACK_SIZE=8192 -I/opt/nRF5_SDK_15.3.0_59ac345/components -I/opt/nRF5_SDK_15.3.0_59ac345/modules/nrfx/mdk -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/strerror -I/opt/nRF5_SDK_15.3.0_59ac345/components/toolchain/cmsis/include -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/util -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/balloc -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/ringbuf -I/opt/nRF5_SDK_15.3.0_59ac345/modules/nrfx/hal -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/bsp -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/log -I/opt/nRF5_SDK_15.3.0_59ac345/modules/nrfx -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/experimental_section_vars -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/delay -I/opt/nRF5_SDK_15.3.0_59ac345/integration/nrfx -I/opt/nRF5_SDK_15.3.0_59ac345/components/drivers_nrf/nrf_soc_nosd -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/atomic -I/opt/nRF5_SDK_15.3.0_59ac345/components/boards -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/memobj -I/opt/nRF5_SDK_15.3.0_59ac345/external/fprintf -I/opt/nRF5_SDK_15.3.0_59ac345/components/libraries/log/src -I/opt/nRF5_SDK_15.3.0_59ac345/examples/peripheral/blinky/pca10040/blank/config  -O0 -g0         -mcpu=cortex-m4         -mthumb         -mabi=aapcs         -Wall         -Wextra         -mfloat-abi=hard         -mfpu=fpv4-sp-d16         -ffunction-sections         -fdata-sections         -fno-strict-aliasing         -fno-builtin         -fshort-enums -g   -o CMakeFiles/main.dir/main.c.obj   -c /home/ricardo/Git/cmake-arm-toolchain/main.c
[100%] Linking C executable main
/home/ricardo/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/192.6603.37/bin/cmake/linux/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt --verbose=1
/opt/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc -O0 -g0         -mcpu=cortex-m4         -mthumb         -mabi=aapcs         -Wall         -Wextra         -mfloat-abi=hard         -mfpu=fpv4-sp-d16         -ffunction-sections         -fdata-sections         -fno-strict-aliasing         -fno-builtin         -fshort-enums -g  -O0         -g0         -mcpu=cortex-m4         -mthumb         -mabi=aapcs         -mfloat-abi=hard         -mfpu=fpv4-sp-d16         -Wl,--gc-sections         --specs=nano.specs         --specs=nosys.specs -L/opt/nRF5_SDK_15.3.0_59ac345/modules/nrfx/mdk -T/home/ricardo/Git/cmake-arm-toolchain/linker.ld -lc -lnosys -lm CMakeFiles/main.dir/main.c.obj  -o main libsdk_lib.a 
/opt/gcc-arm-none-eabi-8-2019-q3-update/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol Reset_Handler; defaulting to 0000000000000000
make[3]: Leaving directory '/home/ricardo/Git/cmake-arm-toolchain/cmake-build-debug'
[100%] Built target main

The linker that is being invoked is not the arm-none-eabi-ld but another one in the toolchain folder. So I am starting to think if the linking process is being performed correctly and all the object files are being build in one elf file. I am a bit lost in this process right now.

R. Vicente
  • 11
  • 1