I have migrated an application based on the peripheral uart sample, running on a Fanstel BT40 board, from nRF Connect SDK v1.6.1 to v2.0.0. The application receives one line-at-a-time via a BLE NUS receive callback from a 115 KB text file, each line 44 bytes long, transmitted from an Android Smartphone over Bluetooth. This application receives 100% of the file under v1.6.1 but under v2.0.0, it disconnects anywhere after13% to 20% of the file is received. I am able to log the following messages via RTT to the nRF Terminal under Visual Studio Code:
[00:01:07.837,860] <inf> primary_pump: Disconnected: F8:CF:C5:C3:6A:1D (public) (reason 34)
[00:01:21.632,598] <err> mpsl_init: MPSL ASSERT: 112, 2152
[00:00:17.563,293] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:01:21.632,629] <err> os: ***** HARD FAULT *****
[00:01:21.632,629] <err> os: Fault escalation (see below)
[00:01:21.632,659] <err> os: ARCH_EXCEPT with reason 3
[00:01:21.632,690] <err> os: r0/a1: 0x00000003 r1/a2: 0x0000001d r2/a3: 0x0000001c
[00:01:21.632,690] <err> os: r3/a4: 0x20001cc8 r12/ip: 0x00000000 r14/lr: 0x00015809
[00:01:21.632,720] <err> os: xpsr: 0x61000018
[00:01:21.632,751] <err> os: Faulting instruction address (r15/pc): 0x0002bcbc
[00:01:21.632,751] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:01:21.632,781] <err> os: Fault during interrupt handling
[00:01:21.632,812] <err> os: Current thread: 0x200017d8 (mainCommsThreadID)
[00:01:24.477,447] <err> fatal_error: Resetting system
What does reason 34 mean when the connection is lost? And what is causing this hard fault? Is it related to non-volatile storage? Why would it run to completion under v1.6.1 but not under v2.0.0 of the SDK? I have found that the BT stack is still operational after it disconnects because I can then connect with the UART Utility Service in nRF Toolbox from another smartphone immediately afterwards.
I appreciate any help you can give to point me in the right direction.
Alec
