Command line tools to build applications are great. But productivity goes up if I can use the standard Eclipse environment with GNU tools. This tutorial is about how to use standard and free GNU and Eclipse tools to build my FreeRTOS application for the ARM Cortex-M4 on i.MX7 π :
Outline
In my earlier article (see “Tutorial: Running FreeRTOS on NXP i.MX7Dual Cortex-M4F“) I used cmake, cygwin and the ARM Launchpad GNU toolchain to build a demo application. That’s fine, but to be really productive, an IDE like Eclipse is preferred. NXP and Toradex offer some examples for IAR Embedded Workbench and ARM DS-5. The IAR IDE and toolchain is proprietary (not Eclipse) and expensive (there is a free 32k Byte version). On the other side the ARM DS-5 is Eclipse based, but very expensive too. NXP offers the unlimited and free-of-charge Eclipse based Kinetis Design Studio (KDS), but for unknown reasons NXP does not provide any example projects with it for the i.MX parts :-(: so you either have to spend a lot of money or to use command line tools only. Time to change this π
I’m using in this tutorial KDS V3.2.0 which uses the GNU ARM Eclipse plugins and the GCC ARM Embedded (launchpad) tools. The cool thing is, because that KDS is using standard components, I can build such an IDE with the toolchain and plugins myself (see “Going to Mars: Building a DIY Eclipse IDE for ARM Embedded Microcontrollers“).
I’m showing the required project settings in the next steps for the ‘hello world’ project. This (and other) project can be found on my GitHub site: https://github.com/ErichStyger/freertos-toradex/tree/colibri-imx7-m4-freertos-v8/examples/imx7_colibri_m4/demo_apps/hello_world/kds
Prerequisites
- Eclipse based IDE (e.g. Kinetis Design Studio V3.2.0) for ARM Development
- GCC ARM Embedded Toolchain (launchpad) toolchain (included in KDS)
- GNU ARM Eclipse plugins (included in KDS)
- BSP with FreeRTOS for i.MX (e.g. from Toradex or from my GitHub)
Project Creation
Create a new C/C++ project with the wizard, with the standard settings:
Files
Add FreeRTOS and application files to the project. Below shows the files for the ‘hello world’ demo application where I’m using Eclipse Virtual Groups and linked files.
This method (using linked files) is recommended. Alternatively you can copy the files into the project instead but only copy the files and folders shown here and when setting your C compiler include paths, refer to the Git repository. Please pay careful attention to the exact file structure shown below as it is a bit different from the structure of the Git repository.
But of course you can copy the files too.
Anyone following the file linking strategy can easily switch between Git repositories with a few simple steps:
- edit the .cproject file for the new project:
- change the path of all LinkedResources to reflect the path of the new repo
- replace all instances of ‘imx7_colibri_m4’ with whatever the repository-/board-specific designation is e.g. ‘imx7d_nitrogen7_m4’
- edit the C compiler includes:
- change all instances of ‘imx7_colibri_m4’ to the repository-/board-specific designation e.g. ‘imx7d_nitrogen7_m4’
- change Settings->Build Artifact->Artifact name field as desired
Project Settings
In the project settings, configure the Target Processor as ARM Cortex-M4 with hardware floating point unit:
In the Optimization settings that the following are turned on:
- -ffunction-section
- -fdata-sections
- -ffreestanding
- -fno-builtin
Compiler
In the compiler preprocessor settings, have the two following defines added:
CPU_MCIMX7D_M4 __DEBUG
For a ‘release’ build you can use __NDEBUG instead of __DEBUG.
In order for the compiler to find the header files, specify all the paths needed. How they are specified depends on how your organize the source files. For the ‘hello world’ demo I’m using relative paths to the project directory ({$ProjDirPath}). You can copy and past the paths below:
${ProjDirPath}/../../../../../examples/imx7_colibri_m4/demo_apps/hello_world ${ProjDirPath}/../../../../../examples/imx7_colibri_m4 ${ProjDirPath}/../../../../../platform/CMSIS/Include ${ProjDirPath}/../../../../../platform/devices ${ProjDirPath}/../../../../../platform/devices/MCIMX7D/startup ${ProjDirPath}/../../../../../platform/devices/MCIMX7D/include ${ProjDirPath}/../../../../../platform/drivers/inc ${ProjDirPath}/../../../../../platform/utilities/inc ${ProjDirPath}/../../../../../rtos/FreeRTOS/Source/include ${ProjDirPath}/../../../../../rtos/FreeRTOS/Source/portable/GCC/ARM_CM4F
Linker
In the linker setting, specify the linker file to be used with the -T option (I’m using below the one using the tightly coupled memory (TCM)):
"MCIMX7D_M4_tcm.ld"
The path to linker file is specified with the -L option:
"${ProjDirPath}/../../../../../platform/devices/MCIMX7D/linker/gcc"
Use the newlib-nano library with the nosys option (–specs=nosys.specs):
Binary File
With u-boot we load a bin (binary) file. To create it, enable ‘Create Flash Image’ under the Toolchains tab. Press the ‘Apply’ button.
Back in the Tool Settings, specify to create a raw binary file:
Building
Build it, and you should get the binary file you can load with u-boot (see Tutorial: Running FreeRTOS on NXP i.MX7Dual Cortex-M4F).
Enjoy π
Summary
Instead spending lots of money with commercial IDE’s, it is possible to build FreeRTOS applications for the ARM Cortex-M4 on the NXP i.MX with free-of-charge open source tools. All what it requires is a basic project setup and is easily done with the GNU ARM Eclipse plugins used in this article.
You can find everything on the following GitHub repository: https://github.com/ErichStyger/freertos-toradex
Happy Eclipsing π
Links
- Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board
- Tutorial: Running FreeRTOS on NXP i.MX7Dual Cortex-M4F
- Tutorial: Updating Embedded Linux on Toradex i.MX7 Colibri Module using SD Card
- GitHub repository with all the files: https://github.com/ErichStyger/freertos-toradex
- Toradex NXP i.MX7D module: https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-imx7
- Going to Mars: Building a DIY Eclipse IDE for ARM Embedded Microcontrollers
- GNU ARM Eclipse Plugins: http://gnuarmeclipse.github.io
- GNU/GCC ARM Embedded: https://launchpad.net/gcc-arm-embedded
- Eclipse: http://www.eclipse.org/
IDE is a good step forward ! Nice work :). But what about debugging ? I heard that Keil DS-5 have this function but unfortunately not include into free community edition. Also Viola and Iris carries board do not embed JTAG or SWD connectors. Do you have trick in mind ?
LikeLike
Still working on debugging. I have a SABRE board which has the debug connector on it. I will need a full eval board from Toradex which has the debug connector on it too. A trick would be to make my own debug adapter on the bottom side of the module (I already found that spring connector to the pins on the backside of the Colibri module).
LikeLike
Interesting. Looking forward your next article :).
LikeLike
Theres a JTAG port on these modules but according to the datasheet its on PCB testpoints and connects using POGO pins on a carrier board. would be great if the jtag port would allow connection to the M4 as easy as it is to connect and to any Kinetis device. Is the M4 in the JTAG chain?
LikeLike
Yes, the M4 is accessible through JTAG and debug port.
LikeLike
Hey Erich,
Great article! have you made any progress with debugging the M4 using KDS?
LikeLike
Hi Evgeny,
no progress unfortunately so far. There is a thread on the Segger community on this as well: http://forum.segger.com/index.php?page=Thread&threadID=3493
LikeLike
Hi,
I followed all the steps above but I’m getting this linker error:
Building target: m4_on_imx.elf
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-builtin -g3 -T MCIMX7D_M4_tcm.ld -Xlinker –gc-sections -LC:\Users\gador\Documents\test\m4_on_imx\platform\devices\MCIMX7D\linker\gcc -Wl,-Map,”m4_on_imx.map” –specs=nano.specs –specs=nosys.specs -o “m4_on_imx.elf” ./rtos/FreeRTOS/Source/portable/MemMang/heap_1.o ./rtos/FreeRTOS/Source/portable/MemMang/heap_2.o ./rtos/FreeRTOS/Source/portable/MemMang/heap_3.o ./rtos/FreeRTOS/Source/portable/MemMang/heap_4.o ./rtos/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.o ./rtos/FreeRTOS/Source/croutine.o ./rtos/FreeRTOS/Source/event_groups.o ./rtos/FreeRTOS/Source/list.o ./rtos/FreeRTOS/Source/queue.o ./rtos/FreeRTOS/Source/tasks.o ./rtos/FreeRTOS/Source/timers.o ./platform/utilities/src/debug_console_imx.o ./platform/utilities/src/print_scan.o ./platform/drivers/src/adc_imx7d.o ./platform/drivers/src/ccm_analog_imx7d.o ./platform/drivers/src/ccm_imx7d.o ./platform/drivers/src/ecspi.o ./platform/drivers/src/flexcan.o ./platform/drivers/src/gpio_imx.o ./platform/drivers/src/gpt.o ./platform/drivers/src/i2c_imx.o ./platform/drivers/src/mu_imx.o ./platform/drivers/src/rdc.o ./platform/drivers/src/rdc_semaphore.o ./platform/drivers/src/sema4.o ./platform/drivers/src/uart_imx.o ./platform/drivers/src/wdog_imx.o ./platform/devices/MCIMX7D/startup/gcc/startup_MCIMX7D_M4.o ./platform/devices/MCIMX7D/startup/system_MCIMX7D_M4.o ./examples/imx7_colibri_m4/board.o ./examples/imx7_colibri_m4/clock_freq.o ./examples/imx7_colibri_m4/gpio_pins.o ./examples/imx7_colibri_m4/pin_mux.o ./hardware_init.o ./main.o
c:/freescale/kds_v3/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld.exe: cannot open linker script file MCIMX7D_M4_tcm.ld: No such file or directory
collect2.exe: error: ld returned 1 exit status
makefile:49: recipe for target ‘m4_on_imx.elf’ failed
make: *** [m4_on_imx.elf] Error 1
Could you help me out?
LikeLike
This means the linker cannot find the linker file (MCIMX7D_M4_tcm.ld). Check that this file exists in your project, and that the linker can find it.
LikeLike
can you show me the set up for the right toolchains from KDS itself when creating the project, because I get an error ” arm-none-eabi-gcc not found in PATH” using toolchains at /opt/Freescale/KDS_v3/toolchain/
LikeLike
No need to setup any tool chain, that toolchain is included in KDS already. Generate a project as shown in the article, and things are correctly setup. Your message indicates that you have not used the KDS project wizard to create the project?
LikeLike
So sorry for late reply, but I’ve figured it out. Thank for the help. But now I am facing a new problem. I try to use this tutorial for UDOO neo Full which uses imX6solox. So I use FREE RTOS for imx6x, but there is some error in port.c file. the error message show : ../source/rtos/FreeRTOS/Source/portable/RVDS/ARM_CM4F/port.c:263:7: error: expected ‘(‘ before ‘void’
__asm void vPortSVCHandler( void )
any idea why some of the assembly code isn’t successfully compiled?
LikeLike
You have to check your compiler C/C++ language settings. Not every compiler accepts the new __asm keyword.
LikeLike
I’m having the same problem. I can compile successfully at the command line using the example project’s armgcc/ scripts but when I follow your instructions to set up a project in KDS 3.2.0 using the same toolchain and try to build, it fails to process the __asm keyword. I’ve tried fiddling with the various compiler arguments to make the Eclipse compile commands look like the command line ones but no matter what I do I still have this issue.
I am running KDS in Windows 7 if that makes any difference. I tried installing KDS in an Ubuntu VM but that install fails. I can command-line compile cleanly both in Ubuntu and Windows using the same toolchain. The issue is clearly with KDS.
LikeLike
Are you using https://github.com/ErichStyger/freertos-toradex?
In the compiler settings you have to specify ‘GNU ISO C11 (-std=gnu11)’ as language standard, otherwise __asm is not recognized.
LikeLike
I have tried your personal repo – https://github.com/ErichStyger/freertos-toradex – the main Toradex repo – https://git.toradex.com/freertos-toradex.git – and the BoundaryDevices repo – https://github.com/boundarydevices/freertos-boundary.git – all have the same issue. (Not too surprising since they share a common origin but it was worth a try)
I have tried gnu11, gnu99, c11 and c99. The KDS builds fail each time. The command line by the way successfully compiles using gnu99 not gnu11.
I have tried updated my GNU ARM compiler toolchains to the latest – 7-2017q4 – and the command line builds continue to succeed in both Linux and Windows but the KDS builds continue to fail. (I literally have the command line build in each O/S using the same toolchain instance as the KDS there)
I got my Linux KDS install fixed and it has the same issue as Windows KDS when compiling the hello_world app.
The main differences I see here are the make binaries and the build configuration.
I compared the make binaries:
Windows KDS fails using GNU Make 4.1
Windows command line succeeds using CMake 3.10.2
Linux KDS fails using GNU Make 3.82
Linux command line succeeds using GNU Make 4.1
So that suggests the build configuration the issue but the fact that they are so different makes them a real pain to compare.
LikeLike
Compared your output with my own and made a couple of adjustments but still not working.
variances:
‘-j8’ argument on the make command – parallelizes the make; adding it shows that some other files compile cleanly but does not fix my problem with port.c
‘-std=c99’ argument on the C compile commands – I thought you said to use ‘gnu11’? Anyway, changing to c99 does not fix the problem
GCC toolchain – reverted back to the v4.8.4 toolchain which comes bundled with KDS 3.2.0 .. does not fix the problem
At this point I am unsure what to try next so I have emailed you an export of my HelloWorld project in the hope that you could spare a few minutes to import it and try to build in your KDS. (It’s self-contained, complete with source code)
LikeLike
It works for me both with gnu11 and c99 compiler settings. I’ll email you my project.
LikeLike
Update: resolved my issue with a little help from Erich.
For anyone else reading this:
1) I highly recommend following Erich’s approach of linking the source files into the project rather than copying the source in.
2) If you do choose to copy source, only copy the source files shown in his screenshots above and refer to the Git repo when defining your C compiler includes.
3) Either way, pay careful attention to the exact folder structure and file locations in Erich’s screenshots because it different than the Git repo in some places.
4) If you get this folder structure set up correctly you can substitute the BoundaryDevices FreeRTOS Git repo (and probably others derived from the NXP repo). It’s easiest if you follow Erich’s approach of linking rather than copying the source files:
* edit the .cproject file for the new project:
** change the path of all LinkedResources to reflect the path of the new repo
** replace all instances of ‘imx7_colibri_m4’ with whatever the repository-/board-specific designation is e.g. ‘imx7d_nitrogen7_m4’
* edit the C compiler includes:
** change all instances of ‘imx7_colibri_m4’ to the repository-/board-specific designation e.g. ‘imx7d_nitrogen7_m4’
** change Settings->Build Artifact->Artifact name field as desired
LikeLike
Hi Ian,
Thank you so much for your feedback. I have updated the article with that information, so hopefully it will be easier next time for everyone.
Thanks and best regards,
Erich
LikeLike
Hi Erich, i am looking at a i.MX7 Colibri and full evaluation board now, it has a 20 pin JTAG header and I have a Segger Jlink Pro so I am looking into how to debug and found this article on the Toradex site : http://developer.toradex.com/knowledge-base/using-arm-ds-5-ide-with-cortex-m4-of-a-colibri-imx7 my question is, can MCUXpresso be configured to debug the M4 or is DS5 the only option right now?
LikeLike
I *believe* it is supported by the latest MCUXpresso IDE 10.1.0 which just came out, but I have not tried that yet.
LikeLike
Hi, Erich.
I’m getting this error when linking:
09:58:06 **** Incremental Build of configuration Debug for project ADC_M4_V00_R00 ****
make all
Building target: ADC_M4_V00_R00.elf
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-common -ffreestanding -fno-builtin -g3 -T “MCIMX7D_M4_tcm.ld” -Xlinker –gc-sections -L”/home/favero/workspace.kds/freertos-colibri/platform/devices/MCIMX7D/linker/gcc” -Wl,-Map,”ADC_M4_V00_R00.map” –specs=nano.specs –specs=nosys.specs -o “ADC_M4_V00_R00.elf” ./sources/rtos/FreeRTOS/portable/GCC/ARM_CM4F/port.o ./sources/rtos/FreeRTOS/croutine.o ./sources/rtos/FreeRTOS/event_groups.o ./sources/rtos/FreeRTOS/list.o ./sources/rtos/FreeRTOS/queue.o ./sources/rtos/FreeRTOS/tasks.o ./sources/rtos/FreeRTOS/timers.o ./sources/platform/utilities/src/debug_console_imx.o ./sources/platform/utilities/src/print_scan.o ./sources/platform/drivers/src/adc_imx7d.o ./sources/platform/drivers/src/ccm_analog_imx7d.o ./sources/platform/drivers/src/ccm_imx7d.o ./sources/platform/drivers/src/ecspi.o ./sources/platform/drivers/src/flexcan.o ./sources/platform/drivers/src/gpio_imx.o ./sources/platform/drivers/src/gpt.o ./sources/platform/drivers/src/i2c_imx.o ./sources/platform/drivers/src/lmem.o ./sources/platform/drivers/src/mu_imx.o ./sources/platform/drivers/src/rdc.o ./sources/platform/drivers/src/rdc_semaphore.o ./sources/platform/drivers/src/sema4.o ./sources/platform/drivers/src/uart_imx.o ./sources/platform/drivers/src/wdog_imx.o ./sources/platform/devices/MCIMX7D/startup/gcc/startup_MCIMX7D_M4.o ./sources/platform/devices/MCIMX7D/startup/system_MCIMX7D_M4.o ./sources/examples/imx7_colibri_m4/board.o ./sources/examples/imx7_colibri_m4/clock_freq.o ./sources/examples/imx7_colibri_m4/gpio_pins.o ./sources/examples/imx7_colibri_m4/pin_mux.o ./hardware_init.o ./main.o
./sources/rtos/FreeRTOS/tasks.o: In function `prvAllocateTCBAndStack’:
/home/favero/workspace.kds/freertos-colibri/rtos/FreeRTOS/tasks.c:3134: undefined reference to `pvPortMalloc’
/home/favero/workspace.kds/freertos-colibri/rtos/FreeRTOS/tasks.c:3140: undefined reference to `pvPortMalloc’
/home/favero/workspace.kds/freertos-colibri/rtos/FreeRTOS/tasks.c:3151: undefined reference to `vPortFree’
collect2: error: ld returned 1 exit status
make: *** [ADC_M4_V00_R00.elf] Error 1
Strangely, its the only function linker cannot find… Could me help me with this issue?
Thanks!
LikeLike
So I figured out: It was the folder MemMang under /rtos/FreeRTOS/include/portable/GCC that I forgot to add. π
LikeLike
ah, that makes sense: without it, you will not be able to link FreeRTOS. Unless you are using 100% static memory allocation.
LikeLike
It looks like you missed to link/use any of the memory scheme files.
LikeLike
Hi Erich,
About the Macros “CPU_MCIMX7D_M4”, “_NDEBUG” and “_DEBUG”, the older version “device_imx.h” uses “CPU_IMX7D_M4” instead.
I cannot find in which file compiler check “_NDEBUG” and “_DEBUG”, are they some kind of switch for checking parameters and printing error message?
Thanks!
PingQi
LikeLike
I found “NDEBUG” defined by GCC (2017-q4-major) in assert.h
But yet I cannot find “_NDEBUG” and “_DEBUG”. GCC version difference?
LikeLike
This all depends on the libraries you are using. _NDEBUG and _DEBUG are usually defined with the compiler -D option.
LikeLike
these are defines you usually add with the -D compiler option.
LikeLike
I just want to make sure what’s the correct form in my current GCC, as I quoted code from “assert.h” above, the “NDEBUG” is the only option, there’re no “DEBUG”,”_NDEBUG”,”_DEBUG” as option, or I could missed something.
It seems to me the gcc makes assert checking by default until “NDEBUG” is defined in IDE/makefile.
The difference between this to what you described in the article is because of the different GCC version I’m using.
Am I right?
LikeLike
There always could be some differences between gcc (or library) version, but the usage of NDEBUG has been pretty standard over the years.
LikeLike
Hi, thanks for your very complete article. I’m using a SABRE board for i.MX7 Dual and I’m getting this error:
arm-none-eabi-g++: error: CreateProcess: No such file or directory
makefile:94: recipe for target ‘m4_on_imx.elf’ failed
make: *** [m4_on_imx.elf] Error 1
I cannot find a solution for this issue, I have also tried another version of the ARM toolchain but the result is the same.
Thank you in advance.
LikeLike
I suggest you check your path settings. It seems to me that it cannot find the g++ compiler/executable?
LikeLike
I tought about htat, but the path is fine. The problem was about the length of some name in folder structure, once I renamed some folder everything was fine. Thank you again.
LikeLike
oh, that’s a good one, I did not think about this. But I have seen that kind of thing in other places, e.g. https://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/
Thanks for sharing your solution!
LikeLike
Hi Erich,
1. Does NXP FreeRTOS BSP for i.MX 7 work as well (not much changes needed)?
2. Do you have any success on debugging with KDS (I did not see a past on that)?
Thanks
LikeLike
Hi Zhiqun,
1: I have not used that one yet
2: No, I was not able to get the Segger J-Link working with the board, unfortunately.
LikeLike
Hi! Very useful, I’m training with iMX7 too, but I followed your step and the next error appear.
#error This port can only be used when the project options are configured to enable hardware floating point support.
../sources/rtos/FreeRTOS/Source/portable/RVDS/ARM_CM4F/port.c:79:3: error: #error This port can only be used when the project options are configured to enable hardware floating point support.
#error This port can only be used when the project options are configured to enable hardware floating point support.
^
../sources/rtos/FreeRTOS/Source/portable/RVDS/ARM_CM4F/port.c:273:7: error: expected ‘(‘ before ‘void’
__asm void vPortSVCHandler( void )
I’m working with the next arm-gcc
gcc-arm-none-eabi-4_9-2015q3 gcc-arm
I really appreciated any advice or help. Many thanks and congrats for your vblogs.
LikeLike
In your project compiler settings, you have to turn on FPU (hard floating point support), then this error shall go away.
LikeLiked by 1 person
Hi I did not resolve my problem, I tried to add the following flags -mfloat-abi=hard -mfpu=fpv4-sp-d16 but I’m little lose, any advice? thank you.
LikeLike
Are you really using my example from GitHub (https://github.com/ErichStyger/freertos-toradex)? I tried it again today with KDS V3.2.0 and it works without issues for me.
LikeLiked by 1 person
Yes I’m using your projects, but I missing something.
Could you share me your makefile generated by eclipse? Many thanks for your support.
LikeLike
I have loaded a zip of the output make files:
https://github.com/ErichStyger/freertos-toradex/commit/8b373c98053c09b503c97fc79b892961c744247e
I hope this helps,
Erich
LikeLiked by 1 person
Hi! it is me again, thanks for you make file I really help me.
This is the link for toradex community, here I upload my fixed with photos and code, I do not know with manual configuration not working for me, but with make file all goes well. Thanks again fr your support.
https://www.toradex.com/community/questions/36131/build-fail-eclipse-freertos-imx7-cortex-m4.html
this was my compile output:
09:47:53 **** Build of configuration Default for project gpio_demo ****
make all
Building target: gpio_demo.elf
Invoking: GNU ARM Cross C Linker
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-builtin -Wall -g3 -T “MCIMX7D_M4_tcm.ld” -Xlinker –gc-sections -L”/home/gualberto/Documents/eclipse-work/eclipse-c-cpp/gpio_demo/sources/platform/devices/MCIMX7D/linker/gcc” -Wl,-Map,”gpio_demo.map” –specs=nano.specs –specs=nosys.specs -o “gpio_demo.elf”
/home/gualberto/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol Reset_Handler; defaulting to 000000001fff8000
Finished building target: gpio_demo.elf
Invoking: GNU ARM Cross Create Flash Image
arm-none-eabi-objcopy -O binary “gpio_demo.elf” “gpio_demo.bin”
Finished building: gpio_demo.bin
Invoking: GNU ARM Cross Print Size
arm-none-eabi-size –format=berkeley “gpio_demo.elf”
text data bss dec hex filename
88 8 2080 2176 880 gpio_demo.elf
Finished building: gpio_demo.siz
09:47:54 Build Finished (took 833ms)
Which advice do you suggest me about this warning? cannot find entry symbol Reset_Handler; defaulting to 000000001fff8000
Kind regards from Mexico!
LikeLike
The Reset_Handler is inside the startup code. From your command line output, it seems that you are not linking all the files needed, and I don’t see that you use the startup code?
LikeLike