Windows IoT Meets FreeRTOS: Real Time CAN Communication on the i.MX93
We would like to share a new CAN solution we developed for our i.MX93 based board running Windows IoT LTSC 11.
Background
The NXP BSP does provide a CAN driver, but under higher packet rates and general system load on the A55 cores we saw noticeable performance drops that did not meet our requirements. Since the Cortex M33 on the i.MX93 was not used for anything else in our design, we decided to move the whole CAN handling over there instead of trying to further tune the existing approach.
How it works
- A FreeRTOS application runs on the M33 and talks to the FlexCAN controller directly, with dedicated interrupt priority and no dependency on the Windows scheduler.
- Communication between the M33 and the Windows side goes through MU1 (Messaging Unit) for interrupt driven signaling and a shared memory region with two lock free ring buffers (one per direction) for the actual CAN frame data.
- On the Windows side, a new KMDF driver, canmu.sys (canmu.inf), maps the MU registers and the shared memory region and exposes a simple IOCTL interface for sending frames, receiving frames and querying status.
- We also built a small reference application, CanTestAPI, that talks to the driver through DeviceIoControl and can be used to send and receive frames for testing.
Why offload to the M33
Since the bus handling now runs independently of Windows and its scheduler, we get stable, deterministic behavior even when the A55 side is under heavy load, and we make use of a core that would otherwise sit idle under windows iot.
Summary
Overall this gives us a CAN interface that stays stable and predictable even under heavy system load, since the time critical part runs completely independent of Windows and its scheduler, and it puts the second core to good use instead of leaving it idle. Just as important for us, it shows that we have the in house know how to build this kind of solution ourselves, from the FreeRTOS firmware on the M33 all the way to the Windows kernel driver, whenever a standard driver does not fully cover what a project needs.
Happy to answer questions or share more details on the MU / shared memory protocol if there is interest.
