nrfxlib Wi-Fi driver documentation

[Saxman58]

We have firmware that works great on the nRF7002-DK board, but now that we have our own board with a Fanstel Wi-Fi module it appears that the Wi-Fi hardware is not responding.  Since the connections between the nRF5340 and nRF7002 are inside of the Fanstel module, there is no way to probe the signals to see if the chips are communicating, etc.

Can you point me towards any documentation on the Nordic Wi-Fi driver in nrfxlib/nrf_wifi?  My hope is that I can find some functions to tell me more about the status of the connection, whether the QSPI interface is working, if the nRF7002 is responding at all, etc.

I need to figure out if this is a hardware or firmware issue, and whether it is on our board or in the module.  One concern is if the split supply (1.8V for the MCU and nRF7002 I/O, but 3.3V to the Vbat pins of the nRF7002) was implemented the same in the Fanstel module as on the nRF7002-DK board.  So I want to see basic information from the driver about whether the RPU is enabled, if it is communicating on the QSPI bus, etc.

[Saxman58]

I found the CONFIG_WIFI_NRF700X_BUS_LOG_LEVEL_DBG and CONFIG_WIFI_NRF700X_LOG_LEVEL_DBG settings to turn on a ton of debug outputs, so now I can search for the WiFi driver code that produces the console outputs of interest to better understand where things are going wrong.

[Elfving]

Hi Glen,

Saxman58 said:

I found the CONFIG_WIFI_NRF700X_BUS_LOG_LEVEL_DBG and CONFIG_WIFI_NRF700X_LOG_LEVEL_DBG settings to turn on a ton of debug outputs, so now I can search for the WiFi driver code that produces the console outputs of interest to better understand where things are going wrong.

Sounds good.

Can you point me towards any documentation on the Nordic Wi-Fi driver in nrfxlib/nrf_wifi?

You can for instance see here.

Both the 54 and nRF7 is on the module? If so I guess a hardware wouldn't be necessary, and I assume the ordering on when what is powered on is also being followed. Have you written to the OTP of the board? Are you seeing it not responding even with a radio test sample? 

Regards,

Elfving

[Saxman58]

Hi Elfving,

Thank you for the link.  I do have more information now:

To take our firmware out of the equation, I am running the simpler example from your Wi-Fi course, lesson 2 exercise 1, with all the debug console outputs turned on.  I can see that the QSPI communications to the nRF7002 are working because the driver is installing the patches and check the RPU status.  And the radio is working because I am able to run a Wi-Fi scan and see all the available Wi-Fi networks in the area.

Everything seems fine until we try to connect to a Wi-Fi network with the console.  Then we get the same errors that we get from our application (which tries to auto-connect).  If the default low power option is set, then the errors look like there is a problem waking the RPU:

If CONFIG_NRF_WIFI_LOW_POWER=n is set, to keep the RPU from sleeping, then the errors look like this:

The invalid address matches what the stacks get filled with to see the high water marks (when CONFIG_INIT_STACKS=y).  That leads me to believe that the error might be an errant pointer that is pointing to a stack area or something like that.  And the wake errors might actually be false if the pointers in the driver are getting trashed.

But what is really strange is that the errors are the same for the Nordic Wi-Fi course example, and our much more complex code.  And both work fine on the nRF7002-DK board.

Fanstel put us in touch with the designer of their module, and he reviewed our schematic and verified that all of our connections to their module look correct.  They expose the internal connections between the nRF5340 and nRF7002 such as the QSPI bus and status and control lines, but we have no connection to those pins.

So it seems like the hardware is working correctly to be able to do a Wi-Fi scan, but then something goes wrong as soon as we try to connect.  And if it is an errant pointer, the fault may have occurred earlier but is only evident once that pointer is used.  Again, it is very hard to understand why the two boards would act different when we are only using the Wi-Fi interface and the console UART in this example code, assuming the Fanstel module really copies the nRF7002-DK circuits between the MCU and RPU.

[Saxman58]

I found the problem.  When trying to connect to the Wi-Fi network, a very short but high current draw spike from the nRF7002 was causing a brown out apparently.  Raising the current limit on our supply makes the problem go away.  It might be a good idea to add some more bypass caps to the Fanstel supply pins too.

I traced the Wi-Fi driver code down to the QSPI transfers and everything looked fine until the RPU would return a buffer address of 0xAAAAAAAA instead of the normal address ranges.  It may have be in the middle of resetting or something, and would never recover with rebooting the firmware (which then reinitializes the RPU).