nRF7002 EB II: SPI Communication Fails with Custom Pin Mapping on nRF54LM20 (Works with Default Shield Mapping)

[Haresh05]

Environment:
* Host: nRF54LM20 DK
* Wi-Fi Companion: nRF7002 EB II
* SDK: nRF Connect SDK v3.3.0-rc2
* Wiring: Manual jumper wires

The Issue:
I am facing an SPI communication failure when using a custom pin mapping in my device tree overlay. Interestingly, the sample works
perfectly with manual wiring when I use the default shield configuration (-Dble_SHIELD="nrf7002eb2"). The failure only occurs when I switch
to the specific pins required for my project.

Error Log (Custom Mapping):

1 [00:00:00.021,277] <inf> wifi_nrf_bus: SPIM spi@4d000: latency = 0
2 [00:00:00.032,687] <err> wifi_nrf_bus: RPU wakeup write ACK failed even after 10ms
3 [00:00:00.032,692] <err> wifi_nrf_bus: Error: RDSR2 failed

Custom Wiring (Failing):
* SPI (spi00): SCK (P2.01), MOSI (P2.02), MISO (P2.04), CS (P2.05)
* Control: BUCKEN (P0.09), HOST-IRQ (P1.23)
* Coex: REQ (P1.19), GRNT (P1.18), STAT (P0.08)

Default Shield Wiring (Working):
* Note: When using the manual wiring with the standard shield mapping provided in the SDK, the system initializes and connects to Wi-Fi without issue.

Observations:
1. Voltages: I measured 3V on the BCKEN pin (P0.09) in the failing setup, so the GPIO is active.
2. Conflicts: I have disabled uart20 and redirected the console to uart30. I also modified the uart30 pinctrl to remove RTS/CTS
(P0.08/P0.09) to free them for the Wi-Fi signals.
3. Peripheral Initialization: When I try to lower the SPI frequency to 1MHz in the custom overlay, the nrfx_spim driver fails to initialize
with error -22 (EINVAL). At 8MHz it initializes but fails to receive the ACK from the RPU.

Questions:
1. Are there any restrictions on using P2.x pins (Global Domain) for high-speed SPI on the nRF54LM20?
2. Is there a hidden internal conflict when spi00 is mapped to the P2 port while other Wi-Fi control signals are on P0/P1?
3. Why does the driver return -22 (EINVAL) for a 1MHz frequency setting on this specific board/peripheral combination?

Regards,

Haresh

[Håkon Alseth]

Hi,

 

If you are using the nRF54LM20-PDK, you cannot re-use certain pins directly, like the UART interface, without disconnecting the connection on the DK itself.

P0.09 is connected to the CTS0 pin on the debugger IC, and the same applies to these pins:

Coex: REQ (P1.19), GRNT (P1.18), STAT (P0.08)

Which overlap with both the wired UART interfaces.

 I would recommend that you disable the uart interfaces in the board controller:

Click on both interfaces, so that they are inactive, and press "write config" afterwards.

 

Remember to re-enable the switches when you are done testing and need the uart interfaces.

3. Why does the driver return -22 (EINVAL) for a 1MHz frequency setting on this specific board/peripheral combination?

It is because the peripheral is clocked from the CPU clock (128 MHz), and the prescaler can only divide it down to just above 2 MHz.

 

Kind regards,

Håkon

[Haresh05]

Hi,

Thank you for the response!
Following your advice I disabled the UART interfaces in the board controller to ensure P0.09, P1.19, P1.18, and P0.08 are completely free from the debugger IC.

Unfortunately, even with the UARTs disabled in the board controller and using the dedicated SCK pin, Port 2 (spi00) still fails with the exact same error: RPU wakeup write ACK failed.

If I change the software to use spi22 and move my 4 SPI jumper wires over to Port 3 (the Arduino headers: P3.00, P3.01, P3.03, P3.02) while keeping the exact same Control and Coex pins on P0/P1... it works perfectly. The Wi-Fi chip boots, provisions, and connects without a single error.

My Questions:
1. Since the exact same manual wiring and control pin setup works flawlessly on Port 3 (spi22) at 8MHz, is it almost certain that the physical capacitance/presence of the onboard flash chip is causing the failure on Port 2, even if I drive the flash chip's CS pin high in software?
2. Or, is there something fundamentally different about the electrical characteristics of the P2 domain / SPIM00 that makes it highly sensitive to jumper wires, even at a lowered 8MHz frequency?

I want to be sure before I physically desolder the flash chip from the DK. Thanks again for your help!

Regards,

Haresh

[Håkon Alseth]

Hi,

 

Sorry, I forgot to mention that the mx25r64 flash IC is by-default switched in, so you will also need to disable the "external flash" in the previously mentioned board controller software.

https://docs.nordicsemi.com/bundle/ug_nrf54lm20_dk/page/UG/nRF54LM20_DK/hw_desription/external_memory.html

 

Kind regards,

Håkon

[Haresh05]

Hi,

I disabled the flash and now it is working as expected.

One final question:
In my current hardware revision, I am looking to save GPIOs. Is it acceptable to connect both BUCKEN and IOVDDEN of the nRF7002 to a single GPIO on the nRF54LM20?

Regards,

Haresh

[Håkon Alseth]

Hi Haresh,

 

Glad to hear it worked! 

Haresh05 said:

In my current hardware revision, I am looking to save GPIOs. Is it acceptable to connect both BUCKEN and IOVDDEN of the nRF7002 to a single GPIO on the nRF54LM20?

The nRF7002-EB (not nRF7002-EBii) does this, by adding a small time-delay to ensure that the BUCKEN goes high before the IOVDDEN signal

You can find the schematics here:

https://www.nordicsemi.com/Products/Development-hardware/nRF7002-Expansion-Board/Downloads?lang=en#infotabs

 

Kind regards,

Håkon