NRF7002DK - NRF5340 SPI4M SPI_MISO tristate causing failure to boot (with spi_nor flash defined)

[DKC]

Hi,

We found a weird case that when we re-populate the definition of SPI-NOR flash

- From original pin (gpio0.8/9/10, U15 populated on NRF7002DK)

- To pins (gpio1.0/1/4, exposed to pin header P3)

, the board failed to boot by hanging over here:

*** Booting MCUboot v2.1.0-dev-9b4ae4cbc9e2 ***
*** Using nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
I: Starting bootloader
I: Bootloader chainload address offset: 0x14000
I: Image version: v1.0.0
▒: Jumping to the first image slot

At hanging state, when we connect the MISO which is gpio1.1 to GND, then it continue to boot as below:

*** Booting MCUboot v2.1.0-dev-9b4ae4cbc9e2 ***
*** Using nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
I: Starting bootloader
I: Bootloader chainload address offset: 0x14000
I: Image version: v1.0.0
▒[00:00:00.003,662] <wrn> spi_nor: Waiting until flash is ready
[00:04:55.588,317] <err> spi_nor: Device id 00 00 00 does not match config c2 20 16
[00:04:55.588,439] <err> spi_nor: Device id 00 00 00 does not match config c2 20 10
[00:04:55.589,721] <err> spi_nor: Device id 00 00 00 does not match config c2 28 17
*** Booting My Application v1.0.0-mfg.inno-4a483adff6c4 ***
*** Using nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
Set up button at gpio@842800 pin 8
Set up button at gpio@842800 pin 9
[00:04:55.803,344] <inf> wifi_supplicant: wpa_supplicant initialized
[00:04:55.829,803] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:04:55.829,803] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:04:55.829,833] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 252.16862 Build 1121034987
[00:04:55.833,984] <inf> bt_hci_core: HCI transport: IPC
[00:04:55.834,075] <inf> bt_hci_core: Identity: DD:DE:F9:AF:40:1B (random)
[00:04:55.834,106] <inf> bt_hci_core: HCI: version 6.1 (0x0f) revision 0x2069, manufacturer 0x0059
[00:04:55.834,136] <inf> bt_hci_core: LMP: version 6.1 (0x0f) subver 0x2069
Bluetooth initialized, use shell to control

This test is try to find whether a spi-nor flash should be presented for booting. But the test was showing that even the true flash device is not presented, the zephyr (with flash_shell enabled) application still can boot with proper error/warning message displayed like log below. But with tricky level change on MOSI signal.

--

<err> spi_nor: Device id 00 00 00 does not match config c2 20 16

--

I just wonder why the level of MOSI will impact the booting procedure. Is there any explanation for the finding?

[Simonr]

Hi

The pins you have rerouted the SPI to are used on the DK for the UART interface communicating with the interface MCU, which will cause conflicts when using the DK board file since these are now being used for more than one thing. Please see the nRF7002 DK user guide here for more information on which pins are already used for something else on the DK: https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/intro.html 

Best regards,

Simon

[DKC]

Thanks, Simon.

This issue seems not related to the confliction of multiple usage on the GPIO pins. I see the same issue when GPIO usage is just for SPIM only.

And I can simply resolve this issue by *internally pull-down* MISO pin by declaring it over .dts. See relevant discussion from  nRF5340 QSPI flash , see comment from roshangeoroy. 

I just wonder if this is the same root cause as discussed in the thread as I shared, and how do I apply necessary patches for the driver 'spi_nor.c', since I don't use QSPI for flash access, driver 'spi_nor.c' is the one I chose from zephyr instead of 'nrf_qspi_nor.c'. BTW, my current zephyr is from version 'ncs-v3.1.0' repo github.com/.../sdk-zephyr.

[Simonr]

Hi

Glad to hear you have found a resolution. Yes, this seems relevant, but please also be aware that the nRF7002 DK uses a lot of the GPIOs for other peripherals by default, so have that in mind while developing.

Best regards,

Simon