Linking init_hardware function fail for MQX RTOS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Linking init_hardware function fail for MQX RTOS

Jump to solution
1,070 Views
lfschrickte
Contributor IV

Hi,

I'm trying to compile my own application using the combination CW 10.6 + MQX RTOS 4.1.0 for FRDM-K64F.

First, I tried to create a project by going to New > MQX 4.1 Project - however, after naming the project, no board appear in the board selection dialog. Is this a bug or am I doing anything wrong? I've tried already to reinstall the RTOS package after CW 10.6 installation.

2014-06-11 17_53_36-C_C   - psp_frdmk64f_PSP_Generic_fio_io_fp.c - CodeWarrior Development Studio.png

So I tried to do it by hand:

- imported bsp, psp, rtcs, mfs, shell, usb libraries using the .wsd RTOS file

- created a new bareboard project, with PE activated and ewl libs

- added the PE MQX RTOS component to the project

- added on the 'compiler include directories' table all bsp, psp, rtcs and other MQX RTOS directories (as in sample projects, same order)

- added bsp, psp, rtcs and shell libraries to the 'Other objects' table in the Linker settings, as in the sample projects

- didn't add any line of code to the application

When I compile, however, I got the following error:

Console

**** Build of configuration FLASH_debug for project httpsrv_mqx ****

"C:\\Freescale\\CW MCU v10.6\\gnu\\bin\\mingw32-make" -j8 all

'Building target: httpsrv_mqx.elf'

'Executing target #79 httpsrv_mqx.elf'

'Invoking: ARM Ltd Windows GCC C Linker'

"C:/Freescale/CW MCU v10.6/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc"    @"httpsrv_mqx.args" -o"httpsrv_mqx.elf"

C:/Freescale/Freescale_MQX_4_1_FRDMK64F/lib/frdmk64f.cw10gcc/debug/psp/psp.a(comp.o): In function `__init_hardware':

C:/Freescale/Freescale_MQX_4_1_FRDMK64F/mqx/source/psp/cortex_m/compiler/gcc_cw/comp.c:58: undefined reference to `init_hardware'

mingw32-make: *** [httpsrv_mqx.elf] Error 1

If I add an empty init_hardware function to my application I get the things compiled, so the only problem is resolving this reference!

The weird part is that I checked bsp.a lib and it contains a init_hardware() function available on init_hw.o. If this lib is being pointed as "Other Objects" section of the project linker settings, why can't the linker find the function? I'm sure init_hw.o is on bsp.a lib, which is being included. Below is the prints of my compiled includes and linked "other objects":

2014-06-11 18_03_44-Properties for httpsrv_mqx.png

2014-06-11 18_03_57-Properties for httpsrv_mqx.png

I've found more than one reference on how to create a MQX project on CodeWarrior, but neither works OK. So:

1. Am I doing things in the right way? Is there any simple guide on how to put a MQX project to work considering MQX 10.6 + PE? I can compile examples given in the MQX RTOS package, however I want to have the opportunity to start a new fresh project using MQX!

2. Does someone have any idea of the reason I can't get my project compiled, following steps above? (yes, I don't know if the compiled application I was mentioning will work in the hardware later :smileysad:).

3. Maybe the problem is that I'm using the MQX RTOS specific FRDM-K64F package, instead of the generic one?

Thank you very much!

Regards,

Luiz Fernando

0 Kudos
1 Solution
476 Views
lfschrickte
Contributor IV

OK, I just find out what the problem was with the init_hardware function: the linking order.

There are 2 ways I could get around it:

  • changing link order, putting all static libraries (*.a) in the top of the link order list
  • changing the linker line by putting -Xlinker --start-group ${INPUTS} -Xlinker --end-group, insted of just ${INPUTS} as the default link line. I found out that in the example projects this is already done. It means the linker should check all the objects/libs cyclically until it can get dependencies resolved.

In the second case, which results in worst compilation performance, but I consider more "elegant", I've found a couple bugs in the CodeWarrior suite. They are:

  1. if you keep the "Customize linker input order" checkbox marked, even if you don't change the default order, it can't resolve some environment variables used in the main project .args file. ${BSP}, ${PSP} and other variables aren't resolved, so the file has lines like this: "${BSP}/bsp.a". Obviously the linking process fails. I had to uncheck that box.
  2. if you don't have any library added, like m or rt, there is a variable, ${LIBS_QUOTED} which also get unresolved in the .args file. Putting a library to be linked together solves this.

Well, finally I could compile it, with one warning only:

c:/freescale/cw mcu v10.6/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: Warning: size of symbol `PE_CpuClockConfigurations' changed from 40 in ./Generated_Code/PE_LDD.o to 120 in C:/Freescale/Freescale_MQX_4_1_FRDMK64F/lib/frdmk64f.cw10gcc/debug/bsp/bsp.a(bsp_cm.o)

I'm not sure if this will bring me problems.. will check it later.

As I don't have my FRDM-K64F board yet I can't tell if all these changes I needed to compile an MQX RTOS app will result in a functional program, but let's hope I can get through this!

Thank you very much.

Luiz Fernando

View solution in original post

0 Kudos
3 Replies
477 Views
lfschrickte
Contributor IV

OK, I just find out what the problem was with the init_hardware function: the linking order.

There are 2 ways I could get around it:

  • changing link order, putting all static libraries (*.a) in the top of the link order list
  • changing the linker line by putting -Xlinker --start-group ${INPUTS} -Xlinker --end-group, insted of just ${INPUTS} as the default link line. I found out that in the example projects this is already done. It means the linker should check all the objects/libs cyclically until it can get dependencies resolved.

In the second case, which results in worst compilation performance, but I consider more "elegant", I've found a couple bugs in the CodeWarrior suite. They are:

  1. if you keep the "Customize linker input order" checkbox marked, even if you don't change the default order, it can't resolve some environment variables used in the main project .args file. ${BSP}, ${PSP} and other variables aren't resolved, so the file has lines like this: "${BSP}/bsp.a". Obviously the linking process fails. I had to uncheck that box.
  2. if you don't have any library added, like m or rt, there is a variable, ${LIBS_QUOTED} which also get unresolved in the .args file. Putting a library to be linked together solves this.

Well, finally I could compile it, with one warning only:

c:/freescale/cw mcu v10.6/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: Warning: size of symbol `PE_CpuClockConfigurations' changed from 40 in ./Generated_Code/PE_LDD.o to 120 in C:/Freescale/Freescale_MQX_4_1_FRDMK64F/lib/frdmk64f.cw10gcc/debug/bsp/bsp.a(bsp_cm.o)

I'm not sure if this will bring me problems.. will check it later.

As I don't have my FRDM-K64F board yet I can't tell if all these changes I needed to compile an MQX RTOS app will result in a functional program, but let's hope I can get through this!

Thank you very much.

Luiz Fernando

0 Kudos
476 Views
lfschrickte
Contributor IV

Just found out the reason for the warning mentioned above - I was creating the project with PE activate, which is wrong in MQX projects: it should only be configured in the bsp project. Thanks!

0 Kudos
476 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

hi Luiz,

Yes, the MQX 4.1 New Project Wizard does not contain the support for K64 boards (both FRDM and TWR) so far. We will assign engineer to work on it.

=====================================================

this answer is for you. if it helps, please click on "correct answer " button. thanks!

Best Regards,

Jennie