Can nRF54H20 work with nRF7002?

[lammobile]

Dear Nordic team,

I am currently working with the nRF54H20 and have been researching the nRF7002 (using the nRF7002-DK). I would like to ask if the nRF54H20 is compatible with the nRF7002 chip. I might need to manually connect the nRF54H20 to the nRF7002 chip on the nRF7002-DK.


** As far as I know, the nRF7002 is designed for the nRF52, nRF53, and nRF91. Is there any updated information or plans to support the nRF54H20?

www.nordicsemi.com/.../nRF7002

Thanks.

[Hung Bui]

Hi Lam, 
We do have experimental support for nRF7002 and nRF54H in SDK v2.7.0 
You can take a look here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/software_maturity.html#protocol_support

I haven't tried myself to run the nRF7002 from the nRF54H but let us know if you face any problem. 

[lammobile]

Hi Hung Bui ,

Context:

• WiFi board: nRF7002-EK
• Host boards: nRF52840, nRF5340, and nRF54H20

I've successfully built and flashed the Wi-Fi: Shell example for nRF52-DK and nRF53-DK, which works well with nRF7002-EK.

uart:~$ 

[00:00:00.259,460] <inf> wifi_nrf_bus: SPIM spi@4002f000: freq = 8 MHz
[00:00:00.259,490] <inf> wifi_nrf_bus: SPIM spi@4002f000: latency = 0
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting nrf52840dk with CPU frequency: 64 MHz
[00:00:00.515,899] <inf> wpa_supp: Successfully initialized wpa_supplicant
uart:~$ wifi 
  version             ap                  connect
  disconnect          ps                  ps_mode
  scan                statistics          status
  twt                 reg_domain          mode
  packet_filter       channel             ps_timeout
  ps_listen_interval  ps_wakeup_mode      rts_threshold

I can build and flash Wi-Fi: Shell for nRF54H20 (nrf54h20dk/nrf54h20/cpuapp) and nRF7002-EK (nrf700x_nrf54h20dk), but I'm encountering an error as shown in the log below:

uart:~$ 

[00:00:00.200,002] <inf> wifi_nrf_bus: SPIM spi@9a5000: freq = 8 MHz
[00:00:00.200,023] <inf> wifi_nrf_bus: SPIM spi@9a5000: latency = 0
[00:00:00.206,997] <err> wifi_nrf: hal_rpu_reg_read: Error !! Value read at addr_offset = 400 is = FFFFFFFF
[00:00:00.207,019] <err> wifi_nrf: hal_rpu_irq_enable: Reading from Root interrupt register failed
[00:00:00.207,034] <err> wifi_nrf: nrf_wifi_hal_dev_add: hal_rpu_irq_enable failed
[00:00:00.207,093] <err> wifi_nrf: nrf_wifi_fmac_dev_add: nrf_wifi_hal_dev_add failed
[00:00:00.207,102] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed
[00:00:00.207,109] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed
[00:00:00.208,131] <inf> fs_nvs: 6 Sectors of 4096 bytes
[00:00:00.208,135] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.208,144] <inf> fs_nvs: data wra: 0, 0
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting nrf54h20dk with CPU frequency: 320 MHz
[00:00:00.209,089] <inf> wpa_supp: Successfully initialized wpa_supplicant

Here's my hardware connection between nRF7002-EK and nRF54H20:

Func	nRF7002-EK	nRF5340-DK	nRF54H20
iovdd-ctrl-gpios	IOVDD_EN	P1.00	P1.00 [P1.03]
bucken-gpios	BUCK_EN	P1.01	P1.00
host-irq-gpios	HOST_IRQ	P1.09	P1.02
cs	SS	P1.12	P1.04
MOSI	MOSI	P1.13	P1.05
MISO	MISO	P1.14	P1.06
SCK	CLK	P1.15	P1.01

//nrf700x_nrf54h20dk.overlay

&pinctrl {
	spi130_default: spi130_default {
		group1 {
			/* SCK has to be 0..3 and other signals can't use these pins */
			psels = <NRF_PSEL(SPIM_SCK, 1, 1)>,
				<NRF_PSEL(SPIM_MISO, 1, 6)>,
				<NRF_PSEL(SPIM_MOSI, 1, 5)>;
		};
	};

	spi130_sleep: spi130_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 1, 1)>,
				<NRF_PSEL(SPIM_MISO, 1, 6)>,
				<NRF_PSEL(SPIM_MOSI, 1, 5)>;
			low-power-enable;
		};
	};
};

&spi130 {
	status = "okay";
	cs-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;

	pinctrl-0 = <&spi130_default>;
	pinctrl-1 = <&spi130_sleep>;
	pinctrl-names = "default", "sleep";
	memory-regions = <&cpuapp_dma_region>;
	nrf700x: nrf7002@0 {
		compatible = "nordic,nrf700x-spi";
		status = "okay";
		reg = <0>;
		spi-max-frequency = <DT_FREQ_M(8)>;
		bucken-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
		iovdd-ctrl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
		host-irq-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
	};
};

&gpio1 {
	status = "okay";
};

Questions:

1. Why are both bucken-gpios and iovdd-ctrl-gpios set to P1.00 for nrf700x_nrf54h20dk? I've tried changing iovdd-ctrl-gpios from P1.00 to P1.03, but the result remains the same.
2. Is my connection between nRF7002-EK and nRF54H20 correct? Are there any missing pins?
3. If the hardware connection is correct, what error am I facing? Is there a way to identify the root cause?

Thank you in advance for any help or insights you can provide. I appreciate your time and expertise.

[Elfving]

Hello Lam,

I'm surprised that this doesn't work by default. Have you modified anything in the sample or SDK?

Could you try changing the USB cable/port, just to make sure that you are not running into the same issue as this guy?

Regards,

Elfving

[lammobile]

Hi Elfving ,

For the example nrf/samples/wifi/shell when I build and flash in default mode (without modifications in NCS 2.7.0), below are the results, I cannot use the wifi scan cmd.

uart:~$ 

[00:00:00.200,002] <inf> wifi_nrf_bus: SPIM spi@9a5000: freq = 8 MHz
[00:00:00.200,023] <inf> wifi_nrf_bus: SPIM spi@9a5000: latency = 0
[00:00:00.211,151] <err> wifi_nrf_bus: RPU wakeup write ACK failed even after 10ms
[00:00:00.211,154] <err> wifi_nrf_bus: Error: RDSR2 failed
[00:00:00.211,200] <err> wifi_nrf: zep_shim_bus_qspi_dev_add: RPU enable failed with error -1
[00:00:00.211,225] <err> wifi_nrf: nrf_wifi_bus_qspi_dev_add: nrf_wifi_osal_bus_qspi_dev_add failed
[00:00:00.211,247] <err> wifi_nrf: nrf_wifi_bal_dev_add: Bus dev_add failed
[00:00:00.211,266] <err> wifi_nrf: nrf_wifi_hal_dev_add: nrf_wifi_bal_dev_add failed
[00:00:00.211,298] <err> wifi_nrf: nrf_wifi_fmac_dev_add: nrf_wifi_hal_dev_add failed
[00:00:00.211,307] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed
[00:00:00.211,318] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed
[00:00:00.212,337] <inf> fs_nvs: 6 Sectors of 4096 bytes
[00:00:00.212,341] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.212,344] <inf> fs_nvs: data wra: 0, 0
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting nrf54h20dk with CPU frequency: 320 MHz
[00:00:00.213,292] <inf> wpa_supp: Successfully initialized wpa_supplicant
uart:~$ wifi scan
Scan request failed
[00:00:05.554,349] <err> wifi_nrf: nrf_wifi_disp_scan_zep: Interface not UP

However, when I change iovdd-ctrl-gpios from P1.0 to P1.3, it works well, and below are the results:

uart:~$ 

[00:00:00.200,102] <inf> wifi_nrf_bus: SPIM spi@9a5000: freq = 8 MHz
[00:00:00.200,122] <inf> wifi_nrf_bus: SPIM spi@9a5000: latency = 0
[00:00:00.572,411] <inf> fs_nvs: 6 Sectors of 4096 bytes
[00:00:00.572,416] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.572,419] <inf> fs_nvs: data wra: 0, 0
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting nrf54h20dk with CPU frequency: 320 MHz
[00:00:00.573,397] <inf> wpa_supp: Successfully initialized wpa_supplicant
uart:~$ wifi scan
Scan requested

Num  | SSID                             (len) | Chan (Band)   | RSSI | Security        | BSSID             | MFP   

Question:

Is it expected or an accident that both iovdd-ctrl-gpios and bucken-gpios are set to P1.0? When I change the source code and it works, could this be the cause of the issue?

[Elfving]

Hi,

I see now what might have lead to these pin conflicts, that shield is not refering to EVK but the EB. The nRF54 being in the name had me confused.

I assume what you are using is the EK and not the EB?

Regards,

Elfving

[lammobile]

Yes, I am using the nRF54H20-DK connected to the nRF7002-EK.
When building the Wi-Fi: Shell, I use the Board target: nrf54h20dk/nrf54h20/cpuapp and Shields: nrf700x_nrf54h20dk as specified in the README Requirements. What confuses me is that Pin1.00 is configured for both iovdd-ctrl-gpios and bucken-gpios.

&spi130 {
	status = "okay";
	cs-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;

	pinctrl-0 = <&spi130_default>;
	pinctrl-1 = <&spi130_sleep>;
	pinctrl-names = "default", "sleep";
	memory-regions = <&cpuapp_dma_region>;
	nrf700x: nrf7002@0 {
		compatible = "nordic,nrf700x-spi";
		status = "okay";
		reg = <0>;
		spi-max-frequency = <DT_FREQ_M(8)>;
		bucken-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
		iovdd-ctrl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
		host-irq-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
	};
};

[Elfving]

I see. I guess this can explain the pin issues. The EB is what we recommend for the 54 series. The EK is only compatible with the 52/53/91 series DKs. Do you have an EB? Your RSM is hopefully able to provide one to you.

The EB do not have separate iovdd-ctrl pin as EK. There is a small circuit which uses bucken itself as iovdd-ctrl due to lack of pins. So in the code same P1.00 pin is used for both iovdd-ctrl and bucken. Our “shield” based support for the 54H is the EB mounted on a custom interposer. 

Another thing I should mention is that if you are planning on designing your own PCB, then don't use this shared BUCKEN and IOVDD_EN approach (as used on the EB) as it does not satisfy the documented power up/powerdown requirements as detailed in the PS. We just decided on doing it this way as there were not enough IOs on the EB to support independent controls.

Regards,

Elfving

[lammobile]

Hi Elfving 
I get it now. Adding eb to the overlay file name (e.g: nrf700eb_nrf54h20dk.overlay) makes more sense. I have both nRF7002EK and EB, so I'll try with the EB.
Thanks for your help.

[Elfving]

No problem at all, and sorry about the slow response from me here.

So it seems that the current version of the DK doesn't support the EB without the custom interposer. I am looking into getting the schematics for that for you. 

Though the EK can work with the wiring strategy you tried there as well (our Wi-Fi R&D team just tested it). Just note that power sequence is violated with both bucken and iovdden connected to same pin and we do not want that situation in a real product.

Regards,

Elfving

[lammobile]

Thanks Elfving for your update . 

Have a good weekendd.