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

[Tim Hwang]

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

[Simon]

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

[Tim Hwang]

Thanks for updating.
Please find attached.

1) I found z_main_thread is located 0x20002350 

zephyr.map
.bss.z_main_thread
0x20002350 0x80 zephyr/kernel/libkernel.a(init.c.obj)
0x20002350 z_main_thread

2) According to other case, I call boot_write_img_confirmed() every time. Is this normal?

(+) [nRF Connect SDK]Sometimes DFU failed to update binary without confirm. - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)
void main(void)
{
boot_write_img_confirmed();
...
}

3) CONFIG_THREAD_NAME=y
I'll chage it then test it again.

Once this situation happened, I have to flash via jtag again. it is real problem.
We have no choice but to open product's cover and flash firmware via flash.

[Simon]

Try increasing CONFIG_MAIN_STACK_SIZE. You can check the file hello_world\build\zephyr\.config to see what the actual value is.

Best regards,

Simon

[Tim Hwang]

Thanks for updating.
I'm testing it too.

Plus.
I change CONFIG_MAIN_STACK_SIZE from 1024 to 2048.

Memory region Used Size Region Size %age Used
FLASH: 214972 B 232960 B 92.28%
SRAM: 65408 B 64 KB 99.80%
IDT_LIST: 0 GB 2 KB 0.00%

Used 99.8% is it okay?

[Simon]

Check out https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/nrf/app_memory.html#bluetooth to see how you can reduce the FLASH and RAM footprint for a Bluetooth sample.

This prj.conf specifically may be useful: https://github.com/nrfconnect/sdk-nrf/blob/v2.0.1/samples/bluetooth/peripheral_uart/prj_minimal.conf 

Best regards,

Simon

[Tim Hwang]

Thanks for good information. it is very helpful.

My project requires maximum performance. We read UART from host and send it to Android via BLE.
(bandwidth 60 KBytes/sec). So that it need much ram to run.
What I asked you was if "Used 99.8%" itself is fine.
2048 bytes of CONFIG_MAIN_STACK_SIZE is fine?
0.02% of ram is left. Is it okay?
If we need more margin(0.02%), I have to reduce my buffer for ring buffer or so.
What is your opinion?

I will test "CONFIG_MAIN_STACK_SIZE=2048" until today. 
Thanks.

[Tim Hwang]

Hello.

I did stress test with two product. And one of device was reset without any log last night. (Stress test means receiving data from UART and send it to Android)
I already did lots of times it was fine so far. 

[rtt log] silent reset
00> connect_done secmode(4)
00> auth_handler 1
00> *** Booting Zephyr OS build v2.7.99-ncs1-1 ***
00>
00> Starting Bluetooth Peripheral HIDS keyboard example for RFR
00> ## build time: Jul 26 2022 09:49:04
00> ver V1.3.7

[Changes & SRAM]
V1.3.6
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_BT_MAX_PAIRED=6
RINGBUFFER size: 24KB
[264/272] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 214636 B 232960 B 92.13%
SRAM: 64672 B 64 KB 98.68%
IDT_LIST: 0 GB 2 KB 0.00%
[272/272] Generating zephyr/merged.hex

v1.3.7
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT_MAX_PAIRED=4
RINGBUFFER size: 24KB
[264/272] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 214636 B 232960 B 92.13%
SRAM: 65408 B 64 KB 99.80%
IDT_LIST: 0 GB 2 KB 0.00%
[272/272] Generating zephyr/merged.hex

 V1.3.8 <- Under Testing
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT_MAX_PAIRED=6
RINGBUFFER size: 24KB -> 22KB
[264/272] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 214636 B 232960 B 92.13%
SRAM: 63360 B 64 KB 96.68%
IDT_LIST: 0 GB 2 KB 0.00%

Stress test requires lots of time(a day). So I hope you give me your opinion current my project situation.