BUS Fault on BLE connection

I have dev kit nRf54LM20 - DK with specs:
PCA10184
0.7.0
2026.12
1051821506

I am using 3.3.0 SDK. When I run peripheral sample project from NCS 3.3.0 it works completely fine. But using my custom project, whenever I try to make a connection with LightBlue App firmware throws BUS Fault Error and get stucks in this state until I reboot it from reset button.
I am not able to understand the exact issue.


Logs are:

[00:12:16.361,389] : Connecting as Peripheral
[00:12:16.366,638] : Peripheral Connected: 00:EC:BE:20:00:EC (0xb0)
[00:12:16.389,434] : BLE Peripheral Connected: 1, Server Key Stat: 0***** BUS FAULT *****
Precise data bus error
BFAR Address: 0x2000000
r0/a1: 0x02000000 r1/a2: 0x001b100e r2/a3: 0x00000000
r3/a4: 0x20068340 r12/ip: 0x00000000 r14/lr: 0x0004afbb
xpsr: 0x01000000
Faulting instruction address (r15/pc): 0x0004a848

  • Hi,

     Can you please find the associated .dtsi file to see the declared RAM base address and size. For nRF54LM20A, the ram starts from 0x20000080 while from  your logs, it starts at 0x2000000. This has 1 i missing digit and thus falls far outside that range leading to  an invalid/corrupted pointer.
    This could be the probable reason.
    Can you please fix this issue and let us know if you face more issues.

    Regards

    Pallavi

  • Whenever I was having crash during connection, it was usually due to memory corruption. And often here:

    static atomic_ptr_t buf_rx_freed_cb;
    
    static void buf_rx_freed_notify(enum bt_buf_type mask)
    {
    	bt_buf_rx_freed_cb_t cb;
    	bool in_isr = k_is_in_isr();
    
    	if (!in_isr) {
    		k_sched_lock();
    	}
    
    	cb = (bt_buf_rx_freed_cb_t)atomic_ptr_get(&buf_rx_freed_cb);
    
    	if (cb != NULL) {
    		cb(mask); <-------------------
    	}
    
    	if (!in_isr) {
    		k_sched_unlock();
    	}
    }

    Linker placed buf_rx_freed_cb (which you can inspect in zephyr.map) after some static array, and code managing that array was having a bug and was writing outside of array, overwriting this callback pointer with some garbage. In my case either it was broken Segger RTT driver, or my code.

    I recommend:

    1. Enable coredump, decode it and check what pointer is being resolved in place where crash happens

    2. If that pointer is statically allocated, inspect zephyr.map to see what code is placed just before it - this is your suspect

Related