Author Topic: McuXpresso integration  (Read 328 times)

Offline Anton

  • Newbie
  • *
  • Posts: 12
    • View Profile
McuXpresso integration
« on: May 21, 2020, 09:44:14 PM »
Hi Mark,

I've been following your video here on importing and compiling uTasker in McuXpresso (11.1.1_3241).
However I ran into some issues during compilation process (FRDM-K22F):

1. Bunch of errors related to redefinition of arm_math related functions. I suppose the correct way of handling this is just to exclude CMSIS_DSP from build, right?

Code: [Select]
Description Resource Path Location Type
#error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)" core_cm0plus.h /uTaskerV1.4/Hardware/CMSIS_DSP line 88 C/C++ Problem
expected identifier or '(' before '{' token cmsis_gcc.h /uTaskerV1.4/Hardware/CMSIS_DSP line 1020 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_abs_f32.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_bitreversal.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_cfft_f32.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_cfft_q15.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_cfft_radix4_q15.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_cfft_radix8_f32.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_cmplx_mag_f32.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** [Hardware/CMSIS_DSP/subdir.mk:54: Hardware/CMSIS_DSP/arm_common_tables.o] Error 1 uTaskerV1.4 C/C++ Problem
make: *** Waiting for unfinished jobs.... uTaskerV1.4 C/C++ Problem
redefinition of '__QADD' arm_math.h /uTaskerV1.4/Hardware/CMSIS_DSP line 930 C/C++ Problem
redefinition of '__QADD16' arm_math.h /uTaskerV1.4/Hardware/CMSIS_DSP line 778 C/C++ Problem


2. QUEUE_HANDLE error in uCANopen. It is defined in types.h so I'm not sure why McuXpresso can't see it.

Code: [Select]
unknown type name 'QUEUE_HANDLE' CO_driver.h /uTaskerV1.4/uTasker/uCANopen line 382 C/C++ Problem

3. Project properties -> C/C++ Build -> MCU Settings show that target is Generic M4 with only RAM definition present. Is this correct?


Thanks,

Anton

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3062
    • View Profile
    • uTasker
Re: McuXpresso integration
« Reply #1 on: May 22, 2020, 01:36:56 AM »
Hi

1. There looks to be a mismatch between sme files compiled with FPU support and other without it.
Make sure that the MCU C Compiler architecture is set to M4 with FPU and also that the MCU Assember Architecture matches this. Command a clean and it may then be OK. You can also exclude any troublesome directories from the project/target build if you are not using their content.

2. I didn't have this problem when I just checked (although I did see an error like it when I had another sub-directory in the workspace with C files in it that i hadn't excluded from the build, and it went away when I excluded the (unwanted) sub-directory. Look to see which C file compile is actually failing - each CANopen C file using the header in question has #include "config.h" before the include of the header and via config.h it should find types.h and thus the missing define.
config.h is found by using the include path  "${ProjDirPath}/Applications/uTaskerV1.4" [in settings -> MCU C compiler -> includes] so also check that this path is correct for your target.

3. The setting that shows only RAM is not used and so doesn't matter if it doesn't actually match the device being used - the linker script file is defined in the MCU Linker -> Managed Linker Script setting (where managed linker script is not used).
I recommend installing the NXP SDK for the board/processor that you use because you can then select this as basis for the MCU setup and be sure that the debug target is also OK. Using generic M4 for building is fine but MCUXpresso (especially its debugger) seems to be somewhat inter-tied with some settings that the SDK delivers - even if not using SDK code haveing it installed in the workspace ensures that MCUXpresso and its debugger find scripts that they need to work without complications.

Regards

Mark


Offline Anton

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: McuXpresso integration
« Reply #2 on: May 23, 2020, 03:35:48 PM »
Mark,

I ended up excluding CMSIS_DSP. But the problem still persists with CO_driver.h not being able to see defines within types.h, include paths are there pointing to correct directory. Just to test I've cloned the repository https://github.com/uTasker/uTasker-Kinetis and it seems to compile without issues.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3062
    • View Profile
    • uTasker
Re: McuXpresso integration
« Reply #3 on: May 23, 2020, 08:30:04 PM »
Anton

The version on GITHUB doesn't have the CANopen in it so the troublesome file is not there.

If you don't need CANopen you could exclude its directory and files from the MCUXpresso project.

If you need CANopen an emergency solution would be to copy the define that is not being found to the start of CO_driver.h.

Regards

Mark


Offline Anton

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: McuXpresso integration
« Reply #4 on: May 23, 2020, 09:34:40 PM »
Mark,

Excluding CO_OD.* from build did the trick.

BR

Anton

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3062
    • View Profile
    • uTasker
Re: McuXpresso integration
« Reply #5 on: May 23, 2020, 11:44:08 PM »
Anton

CO_OD.c should be excluded since it is included from uCANopenApp.c: This file is the output of a CAN open object generation tool.
In Eclipse projects it should already be excluded in the uTasker1.4 project.
If you make a copy of the application directory to a new project it will need to be excluded again (because Eclipse includes all C files it finds by default).
Maybe the exclude attribute was lost somewhere if you are working with the original uTaskerV1.4 application (?)

Regards

Mark

Offline Anton

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: McuXpresso integration
« Reply #6 on: May 24, 2020, 09:22:01 AM »
Mark,

It could very well be that the files mentioned were excluded originally. I've previously managed to screw up the exclude list in multi-configuration projects in Mcuxpresso by having Dropbox application on and syncing files in background, while working in Mcuxpresso, maybe it is the case here is well.  I have to make habit of pausing Dropbox sync before starting McuX.

Thanks.

Anton