Recent Posts

Pages: 1 2 [3] 4 5 ... 10
utFAT / New SD cards stuck in CARD_BUSY_WAIT
« Last post by timadria on May 20, 2022, 09:59:37 AM »

WE received a new batch of SD cards (2 different brands) and they stay in a CARD_BUSY_WAIT loop forever. The older cards (same type, capacity, brand, ...) work perfectly.
I already updated our µtFAT library to the newest version.

I've added some logging:
 SD v2 or higher
 SD do new poll (Now we are in a SD_STATE_APP_CMD55_CMD41 - CARD_BUSY_WAIT loop

Is there any known issue/solution?
NXPTM M522XX, KINETIS and i.MX RT / Re: CANopen on i.MXRT?
« Last post by mark on May 17, 2022, 01:46:42 AM »

It is correct that the driver layer used as reference was from a Coldfire reference but I don't know whether it actually worked since there were some things that didn't match the Coldfire's CAN controller. CO_driver.c is therefore mostly not used since it is HW dependent in its original from and has been made HW independent (but original content retained - commented out - as reference).

Then the interface was reworked to use the uTasker CAN driver interface instead and used in a product (probably about 4 years ago now) on a K64 of K66 .
The Kinetis has FlexCAN (as the Coldfires do/did) and the i.MX RTs also have the same FlexCAN.

If I enable CAN_INTERFACE and
Code: [Select]
SUPPORT_CANopen the project builds for i.MX RTs (although I had to disable two lines in CANopen.c due to a typedef being provided twice):

//typedef unsigned short    MAX_MALLOC;                                    // up to 64k heap chunks
//extern void *uMalloc(MAX_MALLOC);

It may be that that was never needed or became redundant and is only evident when MAX_MALLOC is typedef'ed differently in the application's types.h. My bet is that this is the case and so I will disable these since I don't see that they are needed since there is an include of "config.h" there to access it.

Theoretically this will already run on the i.MX RT since the FlexCAN driver is the only thing that is HW dependent and, since this driver is shared between Kinetis and i.MX RT and assuming it runs on the i.MX RT (which I haven't verified myself just yet - eg. a clock source could be incorrect for speed calculation or there be a register incompatibility somewhere) it will run on any Kinetis, i.MX RT or Coldfire with FlexCAN (although Coldfire is legacy and no longer worked with).

One restriction of the CANopen stack is that it only supports a single instance and so different CANopen instances can't be run on multiple CAN buses..

uCANopenApp.c is used as application interface to the CANopen stack - interfacing with the CANopen.c interface.
If a newer version of CANopenNode is used I expect uCANopenApp.c to remain the same and also CANopen.c to remain the same unless there are changes to the stack's API.
The rest of the newer CANopenNode stack would replace the previous version.

In each of the CANopenNode files I have added:

#include "config.h"

#if defined CAN_INTERFACE && defined SUPPORT_CANopen

which allows them to get their configuration defines from the application configuration rather than needing a configuration header which is not so easily maintained for multiple application use.

Therefore I essentially expect that the 2015 version of CANopenNode should be operational (worst case with a driver / i.MX RT specific correction).
A newer version would need to be integrated but I don't expect any real complications as long as the interface files continue to do their job of keeping the CANopenNode code itself independent to the application's / HW interface.



P.S: There is a possibility that I will shortly be using CANopenNode in an i.MX RT based product development and then I would also need to decide whether an upgrade makes sense as part of this work.
NXPTM M522XX, KINETIS and i.MX RT / CANopen on i.MXRT?
« Last post by NedK on May 16, 2022, 07:34:00 PM »
I've been looking at the V2.0.0 µTasker code, and noticed that:

 (a) the version of the CANopenNode code is quite old (2015 vs. the CANopenNode 4.0 code that is the current branch)

 (b) the driver code appears to be taken from the MCF5282, but the guts of the actual driver code (in CO_driver.c) appears to be all or mostly disabled (CO_CANmodule_init, CO_CANsetConfigurationMode, CO_CANsetNormalMode, CO_CANverifyErrors, etc.).

The latest CANopenNode 4.0 branch cleans up the directory structure, and allows for using multiple object dictionaries if desired.
This can help sharing parts of the object dictionary between nodes that have to communicate but don't have identical object dictionaries.

I've been using the CANOpenEditor fork from, compiled in VS 2022 Community, and it's been quite stable.

My current project is actually using the CANopenNode object dictionary and editor, but not the whole CANopen stack (yet). However, it's likely that we will want to use the whole stack (and the CAN peripheral in the i.MXRT1020) within a year or so.

So I'd like to ask:

What is the current state of the CANopenNode code? Could it be updated to the 4.0 branch?

Is there likely to be a CAN driver for the i.MXRT family any time soon that would work with CANopenNode?


µTasker general / Re: Can't build simulator app
« Last post by NedK on May 04, 2022, 03:36:38 PM »
Thanks, adding several SDKs using the Visual Studio Installer made it compile correctly.
µTasker general / Re: Can't build simulator app
« Last post by mark on May 03, 2022, 08:50:43 PM »

Those two headers are supplied by the compiler library which is presumably either missing can't be found.
It may be something with VS 2022 (I am still using VS 2019) or it may be something missing during its installation - potentially you haven't installed an option that is required since, if i remember correctly, VS 2019 installs the IDE but not all of the language packages and it may be that you need to tell it that you need its C/C++ package which will then deliver the missing libraries.

As a reference I find these two missing files in the folder
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt

I believe VS 2022 is being used by some and I didn't hear of such issues and therefore I am tending to think that it will be an installation option problem - check out this Microsoft page and verify that the "Desktop development with C++" workload is included.

Good luck


µTasker general / Can't build simulator app
« Last post by NedK on May 03, 2022, 06:27:16 PM »
I'm trying to build the i.mxRT simulator application (in Windows 10 64-bit) under Microsoft Visual Studio Community 2022 (64-bit), Version 17.1.6.
I'm building from the V2.0.0 branch, based on commit e0e0bc9c7e3dc28d0f035bf7aacea3d2e3955ed2.
I've read the "getting started" PDF.
I can build the target application successfully using the make_uTaskerV1.4_GNU_iMX makefile.
However, when I go to build the Windows solution (using either the uTasker i.MX or uTasker i.MX plus GNU build targets), the compile fails upon trying to build FreeRTOS objects:

Build started...
1>------ Build started: Project: uTaskerProject, Configuration: uTasker i.MX Win32 ------
1>Z:\uTasker-GIT-Kinetis\FreeRTOS\Source\include\FreeRTOS.h(33,10): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory
1>Z:\uTasker-GIT-Kinetis\FreeRTOS\Source\stream_buffer.c(29,10): fatal error C1083: Cannot open include file: 'string.h': No such file or directory
1>Generating Code...
1>Done building project "uTaskerV1-4.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm not familiar with Visual Studio, so maybe it's something I'm doing wrong.
I've tried both the .sln and the .vcxprog solution/project files with the same result.
NXPTM M522XX, KINETIS and i.MX RT / Re: BOOT_MAIL_BOX location
« Last post by mark on March 22, 2022, 09:32:19 PM »
Hi Caleb

In fact the boot loader and application can have different memory bank layouts as long as the persistent memory (mail box) is always located at the top of the DTC or the FlexRAM layout is left unchanged.
For this to work (with reconfigured banks) the only requirement is the ordering of the banks - see section RAM and Cache in (although I think that the OCRAM addresses may be incorrect in the image since OCR in the 1062 starts at 0x20280000)

From the diagrams there it is seen that as long as the banks are used in the order IIIIDDD (however many banks are allocated to I) the persistent memory is located at the top of the last D bank.
The absolute address changes of course but the relative address (referenced to the top of D bank memory) remains the same.

fnGetPersistentMemory() returns the memory content relative to the top of memory (it simply assumes that the present stack is there, which would normally be the case).

The boot loader uses the chip's default memory layout and the application can also use it too, as long as its stack pointer is set to the same.

Beware that as banks are reconfigured their absolute addresses change, meaning that if a different strategy were used the absolute address of the boot loader's banks would move around as the application uses different layout and this is the reason for choosing this strategy so that it is (irrespective of how the application configures its bank usage - which can change as a project develops [but respecting the order the banks so that D is always the last]) in fact already solved.



« Last post by Caleb on March 22, 2022, 09:01:44 PM »
 Hi there,
   In the i.MX RT series, the BOOT_MAIL_BOX and other persistent memory locations are up at the top of memory, above the stack.  This poses a bit of a problem in that the bootloader and the applications need to have the same memory configuration.  For example, on the 1062, it's up at 0x20077ffe by default, which requires the DTC be set differently from the chip default.

Is there any reason I can't change the fnGetPersistentMemory fucntion to get it from one of the lowest areas in memory, that's not already taken?  This would mean it's independent of how DTC and ITC are configured?

USB / Re: USB when moving from MK66 to MK24
« Last post by tdrobnak on March 16, 2022, 11:09:18 PM »
Hi Alex,

I had a similar problem with the USB connectivity as you are experiencing in 2014.  On our design, it was found that we had undersized the capacitor for the VOUT33 pin for the MK22 processor we used in a project.  I see the capacitance is 100nF for your design.  This might be too low and cause noise issues on the USB's internal power supply that VOUT33 is designed to supply.  Our design uses a 2.2uF capacitor.  It is not well documented in the reference manual for the microcontroller, but I did find that Freescale's (now NXP) KwikStik-K40 Hardware Errata document on Errata ID KWIKSTIK_06 states "Undersized VOUT33 Capacitor" and the solution on page 10 of that document states: "The recommended value for the capacitor from VOUT33 to GND is from 1.76uF to 8.16uF with 2.2uF being the typical value. The capacitor (C34) connected to VOUT33 on the KwikStik is only 0.1uF. This can result in unstable or non-functioning USB operation.  Workaround: Replace C34 with a capacitor of value 1.76uF to 8.16uF".  The link to the document is:

There is also a NXP Community discussion on the USB internal regulator (VOUT33) with NXP TechSupport suggesting a 2.2uF capacitor.  The link for this conversation is:

Hope this helps,


NXPTM M522XX, KINETIS and i.MX RT / Re: UDP and TCP server
« Last post by mark on March 16, 2022, 05:50:46 PM »

For Telnet there is:
(although not a complete description)

For TCP there is:

(which also has examples from Telnet configuration and use)

UDP is so simple it is best to experiment with a simple listener.



Pages: 1 2 [3] 4 5 ... 10