• State Not Answered
  • Replies 48 replies
  • Subscribers 69 subscribers
  • Views 4599 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 bcornell

    Hi,

    I have tested your project for little more than 1 hour and could not reproduce your issue. 

    With a purpose of reproducing the issue, it would be useful if you could test multiple times with the same board and also use another board if you have it available for testing. You should also consider connecting to another access point to check if the issue appears there as well.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hello,

    The error we have been getting when testing with our main development board and new WiFi 6 access point occurs after 2 or 3 hours and we see the message I posted previously. We have tested this 5 or 6 times with the same result every time.

    Today, as suggested, we tested on a different development board and with a different (older WiFi 4) access point.

    After 3 hours, it stopped operating with this message:

    [2023-10-25 14:29:12] addrinfo @0x2006c038: ai_family=1, ai_socktype=1, ai_protocol=6, sa_family=1, sin_port=5000
    [2023-10-25 14:29:12] sock = 9
    [2023-10-25 14:29:12] OK
    [2023-10-25 14:29:12] FAIL

    We restarted the development board and after 3 hours got the same message.

    Neither board has run for 4 continuous hours without crashing, but they always run longer than an hour and a half.

    Switching routers/development boards does not fix the problem.

  • 0 in reply to bcornell

    Hi,

    Thank you for this update and additional information.

    Which access points did you use (manufacturer and version) and which band did you use for your testing?

    Best regards,
    Dejan

  • 0 in reply to dejans

    We have an old D-Link DIR-601B1 which was tested at 2.4GHz and a mesh network using multiple Cisco Business 150AX Access Points which support both 2.4GHz and 5GHz. The development board connects to that network using the 5Ghz band.

  • 0 in reply to bcornell

    Hi,

    Could you please provide a full crash log in both cases (old and new access point)?
    In addition, could you provide elf files from your project's zephyr folder in both cases?

    Best regards,
    Dejan

Reply Children
Related