NXP FRDM-iMX8MP and NPU

[MTeschke]

Hello,

We have been working on the FRDM-iMX8MP with Yocto for some time now, first with Scarthgap, which was unstable in some areas. We used the Matter variant once and once without Matter with the i612 chip.

We have now switched to Walnascar, which is not a problem. Although there have been some changes in the NXP layers, the board is (still) supported. However, we have noticed that Matter will no longer be supported for FRDM-iMX8MP as of q1_2025. This is extremely annoying, as we had relied on it for the OEM project and now have to do everything manually. Will support for the board be provided? I-MX9 is all well and good, but the iMX8 stuff must not be neglected in the long term.

We have also found that it is almost impossible to create a model with INT8 on the FRDM-iMX8MP. eIQ can no longer do it or crashes. And other models cannot be converted because frameworks have a bug and generate errors. Or the models are unusable.

Is there a solution to this?

We have been trying for weeks to get Detect, Multipose, and reID to work.

Detect is not really the problem, as there is TFLite from NXP that can be used. (But it is also not trainable, and eID only causes problems under Ubuntu 20.04.)

Pose is only available as a single pose, int8 -> float32.

And reID is not possible at all.

Will the possibilities change with the i-MX95? Even if it will take forever for the imX95 to hit the market and for an FRDM Dev from NXP to be available for purchase. Especially since eIQ is fully usable.

How do you do it?

[Bio_TICFSL]

Hello,

While Matter support is scheduled to end for FRDM-iMX8MP in Q1 2025, NXP continues to support the i.MX 8M Plus family through other software releases. The transition to Walnascar was a positive step, and this platform will continue to receive updates. The i.MX 8 family remains an important product line even as i.MX 9 series development progresses.

Regarding NPU model optimization challenges:
The difficulties you're experiencing with INT8 model conversion for the NPU are known issues. There are several approaches to resolve these:

1. For detection models:
- The TFLite models provided by NXP are indeed usable but have limitations for training.

2. For pose estimation:
- The single pose models with int8→float32 conversion are currently the best supported option.
- For the FRDM-iMX8MP, you can use the pre-built demo application with the command: `/usr/bin/gstnninferencedemo-posenet-camera /dev/video3`

3. For reID models:
- These are more challenging to implement on the current platform.

For better results with model conversion:
- Follow the proper workflow: .pb → .onnx (with PyTorch) → .tflite with eIQ (quantization) → optimized .tflite
- When using eIQ, ensure you have sufficient training data (300+ images) for proper quantization
- Consider using eIQ v1.12.1 instead of newer versions which may have conversion bugs

The i.MX 95 will offer improved NPU capabilities with better model support through the Neutron delegate. While the FRDM development board availability timeline is still pending, the enhanced NPU will support more complex models and operations.

Regards

[MTeschke]

Hello,

thank you for your detailed responses.

As a future partner, I assume that the i.MX8 family will continue to receive solid support with regard to frameworks, especially since it is listed in Active Longevity from 2034 to 2038. From a developer’s perspective, it is of course very frustrating when support for Matter and potentially other components is discontinued. This significantly slows down development, and especially with Yocto it is sometimes difficult to achieve meaningful results under such conditions.

Based on this, we can assume that the FRDM i.MX8MP will no longer receive Matter support, while only other boards of the i.MX8 family have received such support so far in the latest release.

For certain use cases without strict requirements, the provided prebuilt detection models can of course be used. However, it is very difficult to obtain reliable INT8 versions of these models without errors.

This issue is less related to the i.MX8 or i.MX9 themselves and more to framework-related problems, for which NXP—aside from eIQ—is not directly responsible. We are aware of this.

The single-pose models are usable, as we know, but we require multi-pose. While it is possible to force single-pose models into a multi-pose setup in combination with detection, this is not a clean or ideal solution.

Regarding the i.MX9: yes, the overall concept sounds very promising. However, even the best SoC with an NPU is of limited value if the frameworks are not capable of generating the required models. This is not necessarily an NXP issue, except in the context of eIQ. We hope that with the i.MX9, the tooling will become more modern and stable. It would also be highly desirable if NXP were able to integrate very strong YOLO models—such as the newer versions from v10 onward—into eIQ. These models are extremely accurate, even though we are aware of their internal complexity.

For now, we will pause our development until the launch of the i.MX9, as we specifically require the i.MX95.

Thank you for the information.