Problems using nRF7002 with non-nRF MCU

[djgj]

Hello All,
I am trying nRF7002 shield on my non-nRF MCU and i am running the wifi sample app on zephyr (latest version as of today Aug 20)
I get this error most of the time when issuing "wifi" shell commands. however commands are successful 50% of the time.
Has anyone seen this before? should i enable or disable any kconfig for this?

Regards,

djgj

[runsiv]

Hi Djgj

Could you give a bit more information regarding your system? As we can't test for all devices, the test level will be lower on non Nordic hosts. Due to this, there might be compatibility issues with helper libraries, such as the download library.

Regards

Runar

[djgj]

Hi Runar,

We are using RT500 MCU (NXP) as our host MCU. I connected our host MCU with nRF7002 EK via SPI connection. 

I am running the basic WiFi shell application on zephyr:

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/net/wifi

All other configs are same as used with nRF5340 except the SPI interface part.

While debugging i also noticed this comment which can be related to my issue.
https://github.com/nrfconnect/sdk-nrfxlib/blame/main/nrf_wifi/hw_if/hal/src/hal_interrupt.c#L437

Do you know what this is about and how to mitigate this?

kindly let me know if you need more details.

Regards,

djgj

[djgj]

Hello,
      I didn't see this issue when i tried the same sample with nRF5340 DK and nRF7002 EK. 

do you know on what conditions this might be triggered? 
https://github.com/nrfconnect/sdk-nrfxlib/blame/main/nrf_wifi/hw_if/hal/src/hal_interrupt.c#L437

What connection should i ensure so that nRF7002 does not give wrong addresses?

Regards,
djgj

[Marte Myrvold]

Hi,

I have forwarded this issue internally and will get back to you early next week.

Best regards,
Marte

[Marte Myrvold]

Hi,

The Wi-Fi team does not believe the issue is relevant to https://github.com/nrfconnect/sdk-nrfxlib/blame/main/nrf_wifi/hw_if/hal/src/hal_interrupt.c#L437.

The Invalid memory addresses from the logs seem to be random addresses, which would suggest SPI read corruption. This could indicate SPI connection issues.

What SPI frequency are you using? Would it be possible to try with lower SPI frequencies, such as 2 MHz or even 1 MHz?

Please also specify what you mean by the commands failing 50% of the time. Do the commands both succeed and fail during a single boot or do they succeed during some boots and fail during other boots?

Please also provide logs during the boot, as well as .config and zephyr.dts from the build folder.

Best regards,
Marte

[djgj]

Hi Marte,

Thank you for the response.
I will try to debug from SPI transfer corruption aspect.
I currently running at 8 MHZ, however i tried at 1, 2 MHz too without much success.

I meant with 50% failing is during single boot itself. if i issue the `wifi scan` shell command, it passes around 50% time roughly. but i do keep seeing these invalid addresses always.

I have also attached the requested files.

1856.logs.zip

regards,

djgj

[Marte Myrvold]

Hi,

Thank you for clarifying and providing the files. I have forwarded it internally and will get back to you by the end of the week.

Best regards,
Marte

[djgj]

Thank you Marte, 

I also noticed that when i leave the setup for more than 5 minutes and try wifi scan command again. then nrf7002 kind of goes to off/low power mode and it does not wake up.

Is this also known issue? should i disable/enable something?

Regards,

djgj

[Marte Myrvold]

Hi,

Can you try disabling low power mode to debug the issue? You can do this by setting CONFIG_NRF_WIFI_LOW_POWER in prj.conf or adding it as a flag when building (-- -DCONFIG_NRF_WIFI_LOW_POWER=n).

Best regards,
Marte

[djgj]

Hi Marte, 

Issue about wake up is better when i disable CONFIG_NRF_WIFI_LOW_POWER. However i still see those invalid memory addresses most often along with other issues like timeouts. Overall the connection/interface is not stable enough to do any networking task. 

I tried to debug by connecting logic analyzer to SPI lines. However i do not know what each bytes represent to check anything meaningful.

Are these memory addresses transferred via SPI line to host? i could not see them in my logs?
Could you help me debug this issue and to what to look for in those analyzer logs?

How to prove it is an issue on either host MCU side or nRF7002? on the host side we have also verified that SPI lines are working and stable. Only in combination with nRF7002 we face this issue.

Regards,

djgj

[Marte Myrvold]

Hi,

I have forwarded this internally and will get back to you early next week.

Best regards,
Marte

[Marte Myrvold]

Hi,

The team has suggested some things you can do to debug the issue.

1. Measure the SPI clock while running the SPI at 2MHz or 1MHz to validate the frequency.
2. Measure the BUCKEN, IOVDD, and VBAT supplied to the nRF70.
3. Probe IOVDD and BUCKEN with an oscilloscope during boot to check the power sequencing.

The power-up sequencing requirements are as follows:

• Supply VBAT/BUCKVBAT/BUCKVBATS/AFEVBAT
• Wait ≥ 6 ms
• Assert BUCKEN
• Wait ≥ 1 ms
• Supply IOVDD

You can read more about this in supply sequencing requirements.

Please share the results of these tests.

It would also be helpful if you could share the hardware schematics of your host interface.

Best regards,
Marte