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

[Håkon Alseth]

Hi Gabriel,

 

These should be pull down:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0/boards/shields/nrf7002ek/nrf7002ek.overlay#L41-L42

 

Not pull-up.

By setting them to pull-up, they will always have the idle level of "active".

 

By setting a defined level here, you ensure that the pin is inactive when the nRF7002 is inactive, and vice-versa when nRF7002 is active.

 

Kind regards,

Håkon

[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?