# MM8108 SPI on nRF54LM20B: bring-up works on some resets and fails on others **URL:** \ **Category:** General\ **Created:** [September 14, 2026, 1:14pm UTC](https://community.morsemicro.com/t/mm8108-spi-on-nrf54lm20b-bring-up-works-on-some-resets-and-fails-on-others/2021 "2026-09-14T13:14:04Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ziyao](https://avatars.discourse-cdn.com/v4/letter/z/7feea3/32.png) [@Ziyao](https://community.morsemicro.com/u/Ziyao)\ **Post date:** [September 14, 2026, 1:14pm UTC](https://community.morsemicro.com/t/mm8108-spi-on-nrf54lm20b-bring-up-works-on-some-resets-and-fails-on-others/2021/1 "2026-09-14T13:14:04Z")
**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): ```auto 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: ```auto CMD63/CMD0 invalid ack=0xff data=0xff (x3) -> Transport init failed ``` 1. Chip ID read fails: ```auto CMD52 invalid ack=0xff -> chip-ID failed chip=0x00000000 ``` 1. Firmware download fails: ```auto SPI write response 0xeb rc=-6 size=512 -> CMD53 invalid ack=0xe0 -> Firmware init failed ``` 1. Boot OK, TX fails later: ```auto 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? ---
**Author:** ![michael.mccandless](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@michael.mccandless](https://community.morsemicro.com/u/michael.mccandless)\ **Post date:** [September 15, 2026, 8:44am UTC](https://community.morsemicro.com/t/mm8108-spi-on-nrf54lm20b-bring-up-works-on-some-resets-and-fails-on-others/2021/2 "2026-09-15T08:44:59Z")
> morselib 2.10.4, FW 1.17.6. We’ve just released a [0.1.0 tag for mm-iot-zephyr](https://github.com/MorseMicro/mm-iot-zephyr/tree/0.1.0) 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](https://docs.morsemicro.com/application-notes/appnote-15-mm6108-sdio-spi-design-guide) going over the sdio over spi startup for our chip, it’s targeted towards the mm6108 but it applies to the mm8108 as well. ---
**Author:** ![Ziyao](https://avatars.discourse-cdn.com/v4/letter/z/7feea3/32.png) [@Ziyao](https://community.morsemicro.com/u/Ziyao)\ **Post date:** [September 17, 2026, 1:46pm UTC](https://community.morsemicro.com/t/mm8108-spi-on-nrf54lm20b-bring-up-works-on-some-resets-and-fails-on-others/2021/3 "2026-09-17T13:46:10Z")
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 ---
**Author:** ![michael.mccandless](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@michael.mccandless](https://community.morsemicro.com/u/michael.mccandless)\ **Post date:** [September 17, 2026, 11:08pm UTC](https://community.morsemicro.com/t/mm8108-spi-on-nrf54lm20b-bring-up-works-on-some-resets-and-fails-on-others/2021/4 "2026-09-17T23:08:51Z")
From memory there was two relevant changes for the nrf54lm20a: There’s the [rx-delay device tree SPI property](https://github.com/MorseMicro/mm-iot-zephyr/blob/main/boards/shields/xiao_fgh100mhaamd/boards/xiao_nrf54lm20a_nrf54lm20a_cpuapp.overlay) that I overrode as an overlay. There was also switching the [SDIO-SPI training sequence](https://github.com/MorseMicro/mm-iot-zephyr/blob/70007b9b9161c62c829d76baf3d022af6c8db2d2/drivers/wifi/morsemicro/morsemicro_spi.c#L25-L26) 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