• State Not Answered
  • Replies 11 replies
  • Subscribers 69 subscribers
  • Views 304 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 335607
Options

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
Parents
  • 0

    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

  • 0 in reply to Håkon Alseth

    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
  • 0 in reply to GabrielDS

    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

  • 0 in reply to Håkon Alseth

    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
  • 0 in reply to GabrielDS

    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

  • 0 in reply to Håkon Alseth

    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.

  • 0 in reply to GabrielDS

    Hi,

     

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

    Do you see this issue if you use for instance the wifi/scan or wifi/sta sample?

    Does the issue only occur on custom hardware, or with the nRF7002dk as well?

     

    GabrielDS said:

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

    Understand that you do not want to upgrade your SDK, but it would be good to get a generic overview of if this is a generic problem seen only on v2.6.x or if it also occurs on newer versions?

     

    I would recommend that you atleast keep your sources up-to-date with the latest minor release, which is v2.6.2.

     

    GabrielDS said:

    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.

    Do you use a switch or similar to enable the main VDD_WIFI to the nRF7002? If yes, when is this done during initialization (SYS_INIT -> pre-kernel? What prio?) in your end? Do you have a delay afterwards to ensure that the nRF7002 is booted up?

     

    Kind regards,

    Håkon

Reply
  • 0 in reply to GabrielDS

    Hi,

     

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

    Do you see this issue if you use for instance the wifi/scan or wifi/sta sample?

    Does the issue only occur on custom hardware, or with the nRF7002dk as well?

     

    GabrielDS said:

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

    Understand that you do not want to upgrade your SDK, but it would be good to get a generic overview of if this is a generic problem seen only on v2.6.x or if it also occurs on newer versions?

     

    I would recommend that you atleast keep your sources up-to-date with the latest minor release, which is v2.6.2.

     

    GabrielDS said:

    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.

    Do you use a switch or similar to enable the main VDD_WIFI to the nRF7002? If yes, when is this done during initialization (SYS_INIT -> pre-kernel? What prio?) in your end? Do you have a delay afterwards to ensure that the nRF7002 is booted up?

     

    Kind regards,

    Håkon

Children
No Data
Related