K32 project fails to build

[davenadler]

I'm thinking about using a K32 for an upcoming project.
I created an MEX with the initial pin assignments and software component selection.
Planning to use FreeRTOS, FATfs via SPI, I2C peripherals, etc.
I added the required  #define FMSTR_TRANSPORT FMSTR_PDBDM  to  freemaster_cfg.h
It fails to build with the errors below.
What's going on (why does a very basic generated basic project have a duplicate definition and a missing function)?
MEX, project files and freemaster_cfg.h in attached ZIP.
Thanks!

c:/nxp/mcuxpressoide_11.3.0_5222/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.3.0.202008311133/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: ./component/crc/software_crc_adapter.o: in function `HAL_CrcCompute':
C:\tmp_K32_workspace\K32L2A41xxxxA_Project\Debug/../component/crc/software_crc_adapter.c:16: multiple definition of `HAL_CrcCompute'; ./component/crc/crc_adapter.o:C:\tmp_K32_workspace\K32L2A41xxxxA_Project\Debug/../component/crc/crc_adapter.c:17: first defined here
c:/nxp/mcuxpressoide_11.3.0_5222/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.3.0.202008311133/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: ./board/peripherals.o: in function `FATFS_init':
C:\tmp_K32_workspace\K32L2A41xxxxA_Project\Debug/../board/peripherals.c:133: undefined reference to `FATFS_DiskInit'

[davenadler]

@Alexis_A- That is really unbelievable. There are literally tens of thousands of applications that use uSD cards over SPI, and of course some of NXP's products also have a nice parallel uSD interface peripheral. How is it possible NXP's 'wizards' do not automatically generate code for these common options (connecting FAT to peripheral)? Is NXP trying to force customers to consider other vendors? Yikes!

PS: For example, here's a customer struggling to get this to work, when it should be out-of-the-box:
https://community.nxp.com/t5/K32-L-Series-Microcontrollers/K32l2B3-SPI-DMA-Problem/m-p/1221128#M30 

[Alexis_A]

Hello @davenadler,

Unfortunately, until now, this feature hasn't been add to the SDK, sorry for the inconveniences this may cause you.

I will let know the apps team about this room for improvement. Thanks a lot for your comments.

Best Regards,

Alexis Andalon

[davenadler]

@Alexis_A- NXP failure to provide base software for common FAT is not just an "Inconvenience".
As you can see from example customer I linked, it costs real time and money for each customer
to re-implement what should be in NXP base offering. It also makes customers go elsewhere,
for example appropriate FAT support is included in base software provided for ESP32 alternative
someone suggested here.

Please confirm this is clearly understood and forwarded to developers,
Thanks,
Best Regards, Dave

[mjbcswitzerland]

Hi

Note that the uTasker project includes Freemaster, FreeRTOS (as well as uTasker OS), FAT to SD cards over any SPI, and master/slave I2C for the K32L2A4.

https://www.utasker.com/kinetis/FRDM-K32L2A4S.html

Unlike the NXP solution it works without needing to be ported between parts so a project developed on the K32L2A4S will run on any other Kinetis part (with the required peripherals) or i.MX RT parts.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key

[davenadler]

@mjbcswitzerlandThanks Mark, but I'm a bit confused. I had a look at your web site, where the uTasker documentation I found has not been updated in 11-13 years, and I found no mention of FreeRTOS. We normally use FreeRTOS as it provides very complete OS facilities, it is well-documented, and its what we are familiar with. Can you clarify?
Thanks!

[mjbcswitzerland]

Dave

Since the uTasker OS has been stable for about 11 years there has been no need to update its document.

Documentation updates are made on a regular basis for new features and parts support.

FreeRTOS is included in the package (that is it is set up to immediately run on [all supported] HW platforms) and allows the uTasker OS and its tasks to run in a FreeRTOS task so that existing (FreeRTOS based) projects can be used with the uTasker framework which delivers advanced drivers and protocols and such. This is mentioned on the start side in the feature list: https://www.utasker.com/index.html but otherwise is not used that often since users tend to switch to the uTasker OS because it reduces RAM usage and tends to be faster in operation for most general purpose embedded projects.

Since, when RUN_IN_FREE_RTOS is enabled, the framework gives an operational FreeRTOS project  (whereby HW and startup is managed by uTasker) FreeRTOS users can work in their normal way and just need to decide which drivers and stacks etc. they actually want to use from the uTasker part (running as a low priority FreeRTOS task).

uTasker focuses on HW support, drivers and protocol stacks and not on the OS.

Regards

Mark

[Alexis_A]

Hello @davenadler,

The FATFS driver in the SDK only supports USB and RAM disks, in case you want to use the SPI you could base this in the SDK drivers but the HAL will need to be changed to support the SPI interface. Also, if if you enable the physical layer options this enables only the API to initialize the respective device. 

Best Regards,

Alexis Andalon