MM6108-EKH05: scan example suddenly failing at mmwlan_boot (Transport init failed) after working previously

General
1

Hi everyone,

I’m facing an issue with the MM6108-EKH05 evaluation kit connected to an STM32U5 host, using the unmodified MM-IoT-CMSIS v1.8.4.

Important context: I had successfully run all the SDK examples (including scan) perfectly fine on this exact setup. However, it suddenly started failing with the errors below, without any changes to the hardware or software configuration.

Interestingly, the porting_assistant.c still passes all tests completely. It successfully reads the chip ID (0x0306), does bulk read/write, and validates the BCF and FW.

However, when I flash and run the scan.c example now, it falls into a failure loop:

Plaintext

Morse Scan Demo (Built Apr 24 2026 14:42:41)

E       29 Morse Chip Reset Unsuccessful
E       29 Transport init failed
Using 4.3V BCF
Failure 0 logged at pc 0x08009a9a, lr 0x0800bb07, line 155 in 00000000
... [Repeats] ...

Morse Scan Demo (Built Apr 24 2026 14:42:41)

E     1679 FW manifest pointer not set
E     1680 Failed
E     1680 Failed
E     1680 Firmware init failed
Using 4.3V BCF
Failure 3 logged at pc 0x08009a9a, lr 0x0800bb07, line 155 in 00000000

I mapped the program counter (pc 0x08009a9a) from the crash log, and it points precisely to line 155, which is the mmwlan_boot() function inside app_init.

Questions:

  1. Since the basic SPI/SDIO transport tests in porting_assistant still pass, but mmwlan_boot fails transport/firmware init, could the MM6108 be stuck in a bad state that a normal software reset isn’t clearing?

  2. Is it possible that the BCF or FW image stored in the host MCU’s flash got corrupted, causing the FW manifest pointer not set error when mmwlan_boot tries to load it?

  3. Could this be a symptom of a power supply issue (brownout) occurring exactly at the moment mmwlan_boot tries to turn on the radio PHY, which doesn’t happen during the lighter porting_assistant tests?

Are there any recommended steps to do a deep factory reset of the module’s state or further debug the mmwlan_boot execution?

2

Hi @marcusanderson

I think this is unlikely. Before doing anything the hardware reset line will be asserted to reset the chip. My gut here is telling me that there is a power issue. A logic analyser capture might help.

You can rule this out by rebuilding the application and reflashing the host MCU. I think this is also unlikely.

This sounds like a possibility. Has your usb cable for power changed? The porting assistant doesn’t call mmwlan_boot, so there is a difference in the host MCU cpu/memory load which will have an increase in power consumption on the host side. Does changing the USB cable used help?

In terms of further debugging morselib, we have recently open sourced morselib with source available in the mm-iot-sdk and in mm-iot-zephyr. If you can reproduce the problem using images built from these ports then you will be able to step through mmwlan_boot. Unfortunately the cmsis pack does not compile morselib from source, opting to use the precompiled binaries instead.

3

Hi @ajudge,

Thanks for the quick response and the insights!

Regarding the power theory: I actually tested it with a direct USB-C connection as well, but the behavior remains the same. The strange part is that the setup was working perfectly before with this exact same cable and firmware. I’ll be hooking up a logic analyzer to capture the lines during that specific moment and debug it further.

In the meantime, I followed your advice and spun up the mm-iot-zephyr environment so I could compile morselib from source. Here are the full test logs for both applications:

1. Porting Assistant: Passes completely

Plaintext

Memory allocation                                            [ PASS ]
Memory reallocation                                          [ PASS ]
Passage of time                                              [ PASS ]
Task creation and preemption                                 [ PASS ]
WLAN HAL initialisation                                      
Hard reset device                                            
SDIO/SPI Startup                                             [ PASS ]
Read chip id from the MM chip                                [ PASS ]
Verify BUSY pin                                              [ PASS ]
Bulk write/read into the MM chip                             [ PASS ]
Raw throughput test                                          [ PASS ]

Note: This will not be the final WLAN TPUT. See test step for more info.
        Time spent (ms):   2501
        Transaction count: 1328
        Bytes xferred:     3973376
        Raw TPUT (kbit/s): 12709

Validate MM firmware                                         [ PASS ]
Validate BCF                                                 [ PASS ]

13 total test steps. 11 passed, 0 failed, 2 no result, 0 skipped

2. halow_client: Yields the exact same failure sequence as the CMSIS version:

Plaintext

uart:~$ E     1710 ev morse_firmware_get_host_table_ptr[174] FW manifest pointer not set
E     1718 ev mm610x_digital_reset[116] Failed
E     1722 ev mm610x_digital_reset[116] Failed
E     1726 ev mmdrv_init[255] Firmware init failed
*** Booting Zephyr OS build v3.7.1 ***
uart:~$

Are there any specific lines, SPI transactions, or power sequencing steps during this initialization phase you recommend I focus on with the debugger/logic analyzer?

4

The consistent failure in Zephyr is surprising.

FW manifest pointer not set is a bit of a cryptic error. It would normally point to a mismatch with the firmware/bcf version, or possibly the BCF format. However, given this is an ekh05, and I’m sure you’re not changing those files, so I’m assuming it is not in fact a BCF issue.

The SPI data lines, RESET, Busy and Wake lines are most important. Use a logic analyzer with at least 100MHz sampling rate so Nyquist is satisfied, and capture normal operation from boot.