MM8108 Integration with NXP i.MX8 (Cortex-M7) Host

We are currently evaluating the MM8108 platform for an embedded system with a Cortex-M7 host and would appreciate guidance from the community.

Our intended setup involves integrating the MM8108 with an NXP i.MX8 device, using the Cortex-M7 core as the host processor. We would like to better understand the level of support and the recommended integration approach for this architecture.

We would appreciate advice on the following:

1. Cortex-M7 Support

  • Are there existing builds or libraries that support Cortex-M7 hosts?

  • We observed that the SDK includes framework/morselib/lib/arm-cortex-m7f/. Is this build officially supported for MM8108 host integration, and is it expected to work with an NXP i.MX8 Cortex-M7 target?

  • If not fully supported, what is the recommended approach for porting from Cortex-M33 (e.g. EKH05) to Cortex-M7?

2. Reference Platform

  • Are there any evaluation kits or reference platforms demonstrating MM8108 working with a Cortex-M7 host processor?

  • If not, which existing evaluation platform would you recommend as the closest reference when integrating with an NXP i.MX8 system?

  • Are there any examples or guidance for adapting this setup to a custom host such as i.MX8 M7?

3. Porting Considerations

  • What are the key differences or challenges when moving from STM32U5 (Cortex-M33) to Cortex-M7?

  • Are there any limitations, configuration differences, or porting considerations when using a Cortex-M7 host instead?

4. MAC Timing / Deterministic Transmission

We are exploring slot-based transmission (TDMA-like behaviour) on top of MM8108.

  • Is transmit-at-time (TSF-based scheduling) supported?

  • Is it possible to control or bypass CSMA/CCA behaviour from the host?

  • Can the host access MAC timing (e.g. TSF or equivalent)?

Any guidance, references, or similar integration experiences would be greatly appreciated.

Thank you.

Hi @user44 ,

Generally speaking, the main differences between Cortex-M33 and Cortex-M7 is that they are compiled differently, and it should “just work”.

We have a pre-built libmorse library for the M7 here, and, if you’re feeling up to it, you are able to compile libmorse from source as of the latest release.

We also have examples which use the STM32 H753 platform which uses an M7 if you wanted to run the test applications.

I hope this helps!

Hi @cmistry

Thanks for the earlier clarification on Cortex-M7 support and the availability of an M7 libmorse build — that was very helpful! I just have a few follow-ups to better understand the reference setup.

Cortex-M7 support scope

  • Would you be able to advise whether the arm-cortex-m7f libmorse build is considered fully supported for MM8108 host integration, or more of a reference/best-effort build?

  • Also, has MM8108 been tried or validated on any NXP i.MX8 Cortex-M7 platform?

STM32H753 reference + EKH08
You mentioned examples using STM32H753 (Cortex-M7). Just wanted to check:

  • Does this setup correspond to the MM8108-EKH08 platform?

  • If so, is EKH08 currently available via sales/support, or still upcoming as indicated on the website?

  • And which STM32H753 board (e.g. Nucleo/EVAL part number) are the examples based on?

Additionally:

  • Are these examples already included in the SDK? If yes, which project/target name would be the best reference?

  • Do the examples use SPI, SDIO, or another host interface?

Porting (M33 to M7 / i.MX8)
When moving from STM32U5 (M33) to Cortex-M7, are there any practical considerations to take note of beyond compiler differences? For example:

  • cache coherency with DMA,

  • interrupt/timing behaviour affecting the WLAN transport,

  • expectations around SPI/SDIO usage (IRQ mode, DMA, etc.)

MAC timing / deterministic TX
We’re also exploring slot-based / TDMA-like behaviour on top of MM8108, and would appreciate any pointers:

  • Is TSF accessible from the host?

  • Is any form of transmit-at-time or scheduled TX supported?

  • Is there any way to influence or constrain CSMA/CCA behaviour from the host side?

  • Are there any examples or APIs related to timing-controlled access?

Appreciate any guidance you can share — especially around the H753/EKH08 setup, as that would help us plan our evaluation approach. Thanks again!

Hi @user44

Would you be able to advise whether the arm-cortex-m7f libmorse build is considered fully supported for MM8108 host integration, or more of a reference/best-effort build?

Yes, as of the 2.10.4 release we have full support the MM8108 platform. How and what host MCU that interacts with is up to the user. Again, using Cortex-M33 vs Cortex-M7 shouldn’t make a difference.

Also, has MM8108 been tried or validated on any NXP i.MX8 Cortex-M7 platform?

No, we have not tried or validated our MM-chips on any NXP platform.

Does this setup correspond to the MM8108-EKH08 platform?

This corresponds to an MM8108 SPI hat with a Nucleo WB55, and are still upcoming.
The Nucleo H753 references examples are for MM6108.

These examples are all included in the MM-IoT-SDK repository. sta_connect and scan would be good places to start.

When moving from STM32U5 (M33) to Cortex-M7, are there any practical considerations to take note of beyond compiler differences?

When porting between these 2, the main difference is that you will be going up in MCU performance. The main considerations will be needed for porting around the board specifically. For example the mmhal implementation.