MM8108 SPI on nRF54LM20B: bring-up works on some resets and fails on others

General
1

Setup

  • nRF54LM20 DK, NCS 3.4.0 / Zephyr 4.4. Custom MM8108 module (chip 0x809), BCF mf15457, morselib 2.10.4, FW 1.17.6.
  • Module has its own supply; ~10 cm jumper wires. SDIO_D2 tied to VDD.
  • SPI mode 0 at 8 MHz. GPIO CS held low per transaction. Per-byte transfers.
  • RESET_N low 5 ms, then 20 ms wait. 17×0xFF training with CS high, then CMD63/CMD0 ×3.

Problem
Same firmware, same hardware: each reset randomly ends in one of these.

  1. OK (after SDK retries):
CMD63 invalid ack=0x1f / CMD0 invalid ack=0x08 / CMD52 invalid ack=0xff
MM chip 0x809, firmware 1.17.6 -> connects, streams fine
  1. No response:
CMD63/CMD0 invalid ack=0xff data=0xff (x3) -> Transport init failed
  1. Chip ID read fails:
CMD52 invalid ack=0xff -> chip-ID failed chip=0x00000000
  1. Firmware download fails:
SPI write response 0xeb rc=-6 size=512 -> CMD53 invalid ack=0xe0 -> Firmware init failed
  1. Boot OK, TX fails later:
morse_yaps_tx: TX skb failed err -12 / Command 3e:1f2 timed out

Tried: SPI at 2/4/8/32 MHz, reset 5–100 ms, external-crystal wait on/off, WAKE high/low, MISO pull-up on/off, repeated hard resets. I also applied fixes suggested in other SPI threads on this forum, but the problem remains. Once stuck at 0xFF, further RESET_N pulses rarely recover it.

Questions

  1. Required RESET_N pulse, post-reset delay and power sequencing for SPI mode?
  2. Why does the chip stay at 0xFF or bit-shifted responses after RESET_N?
  3. Which SDIO pins need pull-ups in SPI mode?
  4. How to have a stable communication?
2

morselib 2.10.4, FW 1.17.6.

We’ve just released a 0.1.0 tag for mm-iot-zephyr which is using morselib 2.13 and FW 2.0

I had success bringing up an nfr54lm20a with Seeed’s xiao fgh100mhaamd shield. It did take overriding the default rx delay on the spi peripheral the mm6108 was on with by adding rx-delay = <0>; to its node on the device tree, which was causing similar bit shifting.

If you’re seeing bit shifting its very likely the sdio-spi handshake is failing so the mm8108 is not switching to spi mode. There’s a good appnote going over the sdio over spi startup for our chip, it’s targeted towards the mm6108 but it applies to the mm8108 as well.

2 Likes
3

Hi!

Could you kindly share the orginal file that can directly drive with the nfr54lm20a?

Thank you so much, that would save me a lot of time!

Sincerely,

Ziyao

4

From memory there was two relevant changes for the nrf54lm20a:

There’s the rx-delay device tree SPI property that I overrode as an overlay.

There was also switching the SDIO-SPI training sequence back to non const since it resulted in an 8 byte burst instead of a continuous 16 byte transfer because accessing it being placed in ROM required buffering for the DMA. That bit will only be relevant if you’re using your own implementation