7002 Initialization fails when using debugger

[GabrielDS]

I have an app where I'm using the AP and STA mode of the 7002.  I'm running on a nrf5340.  

*** Booting nRF Connect SDK v3.5.99-ncs1-1-1-g6dc48c918694 ***
[00:00:12.620,269] <inf> main: Starting nrf7002_nrf5340_custom_cpuapp with CPU frequency: 64 MHz

When using the debugger, these are the first two messages I receive:

[00:00:12.376,525] <err> wifi_nrf: nrf_wifi_fmac_chg_vif_state: RPU is unresponsive for 10 sec
[00:00:12.376,586] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_chg_vif_state failed

However, if when 

CONFIG_WIFI_NRF700X_LOG_LEVEL_DBG=y

is set, everything works well.

When set to 

CONFIG_WIFI_NRF700X_LOG_LEVEL_INF=y

it still fails.

It would appear the time it takes to print the log messages, it allows something else to work.

If I don't use the debugger at all, it boots and runs fine.

 

I've verified that none of my main line code is executed.

I have these network settings set:

config NGBD_PROVISIONING_SERVER

    bool "Select to enable the http/dhcp servers and AP mode"

    select NRF700X_AP_MODE

    select WPA_SUPP_AP

    select WPA_SUPP

    select HTTP_SERVER

    select HTTP_PARSER_URL

    select HTTP_PARSER

    select NET_CONNECTION_MANAGER

    select SOFTAP_NGBD_DHCPV4_SERVER

    select NET_L2_WIFI_MGMT

    select NET_L2_WIFI_MGMT_EXT

    select NET_IPV4

    select NET_TCP

    select NET_UDP

    select NET_DHCPV4

    select NET_CONNECTION_MANAGER    

Thanks,

Gabriel

[Håkon Alseth]

Hi,

 

When using the debugger, these are the first two messages I receive:

[00:00:12.376,525] <err> wifi_nrf: nrf_wifi_fmac_chg_vif_state: RPU is unresponsive for 10 sec
[00:00:12.376,586] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_chg_vif_state failed

However, if when 

CONFIG_WIFI_NRF700X_LOG_LEVEL_DBG=y

is set, everything works well.

When set to 

CONFIG_WIFI_NRF700X_LOG_LEVEL_INF=y

it still fails.

It would appear the time it takes to print the log messages, it allows something else to work.

If I don't use the debugger at all, it boots and runs fine.

Do you have pull resistors enabled on the  iovdd-ctrl-gpios and bucken-gpios in your device tree entry for nrf7002?

 

Can you share your compiled build/zephyr/zephyr.dts file?

 

Kind regards,

Håkon

[GabrielDS]

I expect you mean like this? 

        /* Wi-Fi Pins used */

        iovdd-ctrl-gpios = <&gpio0 15 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>;    // nRF7002_IOVDD_CTRL

        bucken-gpios = <&gpio1 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>;        // buck-en

        host-irq-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;      // HOST_IRQ

        supply-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;         // WiFiPWR_EN

The GPIO_PULL_UP was not there, I just added it.  Can you advise what difference that should make?

The problem went away.  I suspect it had to do with the way the debug button got 'binded' to a configuration that wasn't valid.  Attach to running target still doesn't work, but you can close this out for now.  If it pops back up, I'll send you the .dts.

Thanks,

Gabriel

[GabrielDS]

It did do it again. 

I suspect a startup timing issue based on startup speed that the debugger affects.  I suspect it has to do with how soon the debugger can stop execution.  I do find when I just keep the debugger connected during the flash and reload process, it helps.

Thanks,

Gabriel

[Håkon Alseth]

Hi,

 

Could this be due to the P1.05 being default owned by the network core?

Try adding this:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0/boards/shields/nrf7002ek/boards/nrf5340dk_nrf5340_cpuapp.overlay#L14-L16

And see if this improves the scenario.

 

Kind regards,

Håkon

[GabrielDS]

The problem has risen it's ugly head again.

I actually already had the

gpio_fwd: nrf-gpio-forwarder 

commented out/disabled in my custom board files.

It is blocking my ability to debug wifi.

If I hit reset on the board, the board comes up just fine.  If I attached the debugger (attach or launch), the board resets, and the wifi error above happens.  

I've tried various gbd resets to try to get attached without resetting the chip.

Is there a way to force the wifi chip to reset on power up?  I suspect that a push button reset clears everything out, while a debugger attach does not.

Is there a way to force a wifi chip reset on startup?

Can you advise how I might fix the attach mechanism so a reset doesn't occur to debug?

[Håkon Alseth]

Hi,

 

It does sound like there is a timing error occurring while you are debugging.

Are you using the wifi ready library?

If not, could you try to implement this fix to see if the issue still occurs?

https://github.com/nrfconnect/sdk-nrf/commit/c6cb467b1935b6774be73a9c307c5a217d823023

 

Kind regards,

Håkon

[GabrielDS]

These lines:

[00:00:12.376,525] <err> wifi_nrf: nrf_wifi_fmac_chg_vif_state: RPU is unresponsive for 10 sec
[00:00:12.376,586] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_chg_vif_state failed

Happens very early at startup.  Before main or anything else.

My work around has been to set 

CONFIG_NRF_WIFI_IF_AUTO_START=n

Then start it up before I need it, using the mechanism in the wifi shutdown example.

It's a decent enough solution, but I'm confident there is an issue in the library/driver.

Thanks,

Gabriel

[Håkon Alseth]

Hi,

 

I am glad to hear that you have a workaround, but the issue is still present and should be addressed.

Q1: Are you able to reproduce this with any other sample?

Q2: Which NCS version are you using, and have you tried this on newer versions?

Q3: If you are using v2.6.1 or older, could you ensure that there is a 1 second delay in your main before calling any wifi-related API? https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/samples/wifi/scan/src/main.c#L335

 

Kind regards,

Håkon

[GabrielDS]

Q1:  Yes, it happens on a range of boards.

Q2:  I've been on NCS 2.6.1.  I've not upgraded for a number of reasons.

Q3:  I don't think this is relevant as this hang-up occurs well before main.

The reason you see the message after the startup message is that it tries for 10 seconds to start the Wi-Fi chip.  So the expiration and message show up in the time main runs, but the hang-up is right at power up.  I've verified this in the debugger.