[nRF Connect SDK](Urgent)Assert after DFU via OTA

Target nRF52832(nrf52dk_nrf52832)
SDK NCS v1.9.1

Normally OTA works well.
I found unexpected assert after OTA is done.
Can you please review my assert code with my elf.


00> I: SoftDevice Controller build revision:
00> I: 0e e7 c5 66 67 18 3c ac |...fg.<.
00> I: b3 d2 cc 81 a3 dc f1 c0 |........
00> I: c0 36 02 22 |.6."
00> I: No ID address. App must call settings_load()
00> E: ***** MPU FAULT *****
00> E: Stacking error (context area might be not valid)
00> E: Data Access Violation
00> E: MMFAR Address: 0x20006190
00> E: r0/a1: 0x00000000 r1/a2: 0x000347f9 r2/a3: 0x00000000
00> E: r3/a4: 0x000347f9 r12/ip: 0xec7ff16f r14/lr: 0x29302810
00> E: xpsr: 0x38132000
00> E: Faulting instruction address (r15/pc): 0xf2e63a6d
00> E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
00> E: Current thread: 0x20002350 (unknown)
00> E: Resetting system

6165.build.7z

Parents
  • It seems like a stack overflow happens. Could you set CONFIG_THREAD_NAME=y, so we can see what thread that caused the overflow. As you can see now the thread is unknown:

    00> E: Current thread: 0x20002350 (unknown)

    Then rebuild, trigger the fault again and upload the new log. Then I will tell you how to increase the stack size of that thread.

    Also the uploaded .elf file is corrupted. Could you upload it again?

    Best regards,

    Simon

  • I have to tell you another view of this issue.
    When this issue was made, BLE was reset repeatedly with those logs.

    I have no choice but to flash same binary to recover it.
    After then I cannot made this issue again easily. ( I could not make same issue again)

    On the other hand I change CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE from 2048 to 512.
    I could this issue immediately.

    I'm not sure if this issue is from stack over flow.

    Soon, one of my customer will test our product to buy.
    I'm expecting you give me any opinion.

    Thank you.

Reply
  • I have to tell you another view of this issue.
    When this issue was made, BLE was reset repeatedly with those logs.

    I have no choice but to flash same binary to recover it.
    After then I cannot made this issue again easily. ( I could not make same issue again)

    On the other hand I change CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE from 2048 to 512.
    I could this issue immediately.

    I'm not sure if this issue is from stack over flow.

    Soon, one of my customer will test our product to buy.
    I'm expecting you give me any opinion.

    Thank you.

Children
  • Hello, sorry for the delay on this. In July, most of the support team are on vacation and you can expect slower responses. I will reply tomorrow (Friday)

    Best regards,

    Simon

  • Tim Hwang said:
    What I asked you was if "Used 99.8%" itself is fine.

    I think it should be fine.

    Tim Hwang said:
    On the other hand I change CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE from 2048 to 512.
    I could this issue immediately.

    I'm not sure if this issue is from stack over flow.

    Okay, so right after you change CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE from 2048 to 512 the issue happens, then it's likely a stack overflow.

    I'm not sure if I understood your questions correctly, let me know if not.

    However, I will go on vacation the next two weeks, so I'm not able to reply until 15th of Aug. If that is too long to wait, could you open a new ticket and point to this one?

    Best regards,

    Simon

Related