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

nRF7002dk nrf5340 bus fault after shutting down interface

bcornell

Hello,

I am working on a low power sensor logging project using the nRF7002dk. So far, I have updated the main loop in the wifi/sta sample and in place of the:

k_sleep(K_FOREVER);

I have added:

status = net_mgmt(NET_REQUEST_WIFI_DISCONNECT, iface, NULL, 0);
status = net_if_down(iface); 
k_sleep(K_SECONDS(2)); // will be longer in production, shortened for testing
status = net_if_up(iface);
k_sleep(K_SECONDS(2)); // allow the interface time to come up

I also have code verifying the statuses are returned as 0, but haven't posted that here to simplify my post.

I find that after a few connections, there is a kernel panic when trying to bring the interface back up.

[00:04:56.560,913] <inf> sta: State: SCANNING
[00:04:56.861,053] <inf> sta: ==================
[00:04:56.861,083] <inf> sta: State: SCANNING
[00:04:57.150,177] <err> os: ***** BUS FAULT *****
[00:04:57.150,177] <err> os: Precise data bus error
[00:04:57.150,207] <err> os: BFAR Address: 0x40000b08
[00:04:57.150,207] <err> os: r0/a1: 0x20000200 r1/a2: 0x20000580 r2/a3: 0x20000289
[00:04:57.150,207] <err> os: r3/a4: 0x20000588 r12/ip: 0x2003cca0 r14/lr: 0x200006a8
[00:04:57.150,238] <err> os: xpsr: 0x01000000
[00:04:57.150,238] <err> os: Faulting instruction address (r15/pc): 0x0003e97a
[00:04:57.150,268] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:04:57.150,299] <err> os: Current thread: 0x20003470 (unknown)

The kernel panics stop if I add a 1 second delay between the net_mgmt and net_if_up calls. 

It appears that I can not shut down the interface immediately after disconnecting or something is not cleaned up that causes issues when bringing the interface back up. Obviously in production code, I would like to replace the delay with a check to ensure the disconnect has completed in case it takes longer than 1 second. How can I determine when it is safe to shut down the interface?

Parents
  • 0

    Hi,

    I have added your modifications to the wifi sta sample from NCS v2.4.2. I tested this modified sample on nrf7002-dk board, but I could not reproduce your issue. In my case, the sample behaved as expected.

    If you experience some congestion in your environment, you could try to increase the value of CONFIG_NET_MGMT_EVENT_QUEUE_TIMEOUT in the prj.conf file.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hello,

    Thank you for looking into this so quickly. I apologize, I forgot to mention that I am using the main branch. I have not tested this issue specifically in the NCS v2.4.2 release.

    Idle power consumption is extremely high in the NCS v2.4.2 release, so it is not suitable for our application.

  • 0 in reply to dejans

    Hello,

    Thank you for getting back to me.

    I have rebased using the latest development branch and the behavior has changed. After 15 minutes, on wifi 6, I get an endless stream of State:Scanning messages
    [2023-11-20 14:12:16] [02:34:24.108,917] <inf> sta: State: SCANNING
    [2023-11-20 14:12:16] [02:34:24.409,057] <inf> sta: ==================
    [2023-11-20 14:12:16] [02:34:24.409,088] <inf> sta: State: SCANNING
    [2023-11-20 14:12:16] [02:34:24.709,197] <inf> sta: ==================
    [2023-11-20 14:12:16] [02:34:24.709,228] <inf> sta: State: SCANNING
    [2023-11-20 14:12:16] [02:34:25.009,338] <inf> sta: ==================
    [2023-11-20 14:12:16] [02:34:25.009,368] <inf> sta: State: SCANNING
    [2023-11-20 14:12:17] [02:34:25.309,478] <inf> sta: ==================
    [2023-11-20 14:12:17] [02:34:25.309,509] <inf> sta: State: SCANNING
    [2023-11-20 14:12:17] [02:34:25.610,168] <inf> sta: ==================
    [2023-11-20 14:12:17] [02:34:25.610,198] <inf> sta: State: SCANNING
    [2023-11-20 14:12:17] [02:34:25.910,339] <inf> sta: ==================
    [2023-11-20 14:12:17] [02:34:25.910,369] <inf> sta: State: SCANNING
    [2023-11-20 14:12:17] [02:34:26.210,479] <inf> sta: ==================
    [2023-11-20 14:12:17] [02:34:26.210,510] <inf> sta: State: SCANNING
    [2023-11-20 14:12:18] [02:34:26.510,620] <inf> sta: ==================
    [2023-11-20 14:12:18] [02:34:26.510,650] <inf> sta: State: SCANNING
    [2023-11-20 14:12:18] [02:34:26.810,791] <inf> sta: ==================
    [2023-11-20 14:12:18] [02:34:26.810,821] <inf> sta: State: SCANNING

    I tested multiple times today and the issue was very repeatable.

    What are we doing wrong? Other customers must be using the nrf7002. In our testing, the drivers are completely unstable.

    dejans said:
    With regard to your Wi-Fi 4 issue, we have done some testing using wi-fi shell sample and there were no issues on our side.

    Could you elaborate on how you tested? Our use case seems like an extremely basic test case:
    * connect to wifi
    * get http end point
    * disconnect from wifi
    * power off wifi
    * wait for period of time
    * power on wifi
    * repeat
    Do you have any suggestions on how to prove that this mode of operation is possible for extended periods of time?

  • 0 in reply to bcornell

    Hi,

    bcornell said:
    I have rebased using the latest development branch and the behavior has changed. After 15 minutes, on wifi 6, I get an endless stream of State:Scanning messages

    This is unexpected. I have asked internally about this. 

    bcornell said:
    Could you elaborate on how you tested? Our use case seems like an extremely basic test case:
    * connect to wifi
    * get http end point
    * disconnect from wifi
    * power off wifi
    * wait for period of time
    * power on wifi
    * repeat

    For wi-fi shell test, we used the following repeating sequence:

    net iface up
wifi scan
wifi connect
wifi status
net ping
net stats
wifi disconnect
net iface down

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hi,

    Could you please add CONFIG_WPA_SUPP_LOG_LEVEL_DBG=y to your configuration and provide full log (from very beginning) when using Wi-Fi 6?

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hello,

    It appears that our issues may be related to timing. We tested yesterday without the very verbose dump_rpu_stats function you previously provided. When we added the logging you requested and re-enabled the dump_rpu_stats function, the error took significantly longer to occur.

    We have uploaded this mornings log here: https://dl.defelsko.com/downloads/nordic_logs_nov21.zip

    This is the result of running the same project that I have been running, but with CONFIG_WPA_SUPP_LOG_LEVEL_DBG=y and the latest version of NCS from github.

  • 0 in reply to bcornell

    Hi,

    bcornell said:
    It appears that our issues may be related to timing. We tested yesterday without the very verbose dump_rpu_stats function you previously provided. When we added the logging you requested and re-enabled the dump_rpu_stats function, the error took significantly longer to occur.

    Thank you for the update.

    Which error did you get? Can you show the error? How long did it take for error to appear?

    Best regards,
    Dejan

     

Reply
  • 0 in reply to bcornell

    Hi,

    bcornell said:
    It appears that our issues may be related to timing. We tested yesterday without the very verbose dump_rpu_stats function you previously provided. When we added the logging you requested and re-enabled the dump_rpu_stats function, the error took significantly longer to occur.

    Thank you for the update.

    Which error did you get? Can you show the error? How long did it take for error to appear?

    Best regards,
    Dejan

     

Children
Related