nrf5340 ble secure fault

RE: nrf5340 ble secure fault

Håkon Alseth — Fri, 19 Apr 2024 07:43:17 GMT

Hi,

Thank you for updating and sharing the root cause.

Let us know if you run into any more issues or have questions.

Hope you have a wonderful weekend!

Kind regards,

Håkon

RE: nrf5340 ble secure fault

adunk — Thu, 18 Apr 2024 15:00:30 GMT

The FAULT doesn't occur when I remove the

k_poll_signal_raise(&pair_signal, 0);

Turns out I'm not init'ing the signal properly which was causing the FAULT. Thanks for the help!

RE: nrf5340 ble secure fault

adunk — Thu, 18 Apr 2024 13:49:42 GMT

I bumped up these in prj.conf:

CONFIG_HEAP_MEM_POOL_SIZE=4096

CONFIG_MAIN_STACK_SIZE=4096

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

Unfortunately it had no effect. Same fault.

[00:00:09.926,055] <inf> ble_supv: Regular advertising started

[00:00:10.045,867] <inf> ble_supv: Connected
[00:00:10.498,596] <inf> ble_supv: LESC OOB data requested

[00:00:11.100,372] <inf> ble_supv: Pairing completed: D1:3A:F6:65:C0:9C (random), bonded: 1

[00:00:11.100,372] <err> os: ***** BUS FAULT *****
[00:00:11.100,372] <err> os: Precise data bus error
[00:00:11.100,372] <err> os: BFAR Address: 0x4559
[00:00:11.100,402] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000001 r2/a3: 0x00004559
[00:00:11.100,402] <err> os: r3/a4: 0x20008ea8 r12/ip: 0x00000000 r14/lr: 0x00000edb
[00:00:11.100,433] <err> os: xpsr: 0x21000000
[00:00:11.100,433] <err> os: Faulting instruction address (r15/pc): 0x0001397e
[00:00:11.100,463] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:11.100,494] <err> os: Current thread: 0x20001828 (unknown)

RE: nrf5340 ble secure fault

Håkon Alseth — Thu, 18 Apr 2024 13:25:21 GMT

Try to increase the workqueue stack size, by adjusting this configuration? CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE

Kind regards,

Håkon

RE: nrf5340 ble secure fault

adunk — Thu, 18 Apr 2024 12:35:00 GMT

Here's line 213. Keep in mind this is OOB pairing over UART which is successful with the nrf52833 DK but for this I am using the nrf5340 which doesn't work with the same code. This code was based off of the NFC OOB pairing sample which is very similar and identical in this function.

RE: nrf5340 ble secure fault

adunk — Thu, 18 Apr 2024 12:26:17 GMT

Here's the results:
PC
Cmd: addr2line 0x000138c6
Output: zephyr/include/zephyr/sys/dlist.h:509

LR
Cmd: addr2line 0x00000edb

Output: src/ble_supervisor.c:213

Thread:
.bss.bt_workq 0x00000000200015c8 0xa0 zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj)

RE: nrf5340 ble secure fault

Håkon Alseth — Thu, 18 Apr 2024 12:05:29 GMT

Hi,

In order to find the source of the assertion, you should map the faulting address(es) to your source code, using addr2line, as explained in here from step 12 and down:

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/topic/exercise-2-11/

Then you can also search for the "current thread" in your build-folder/zephyr/zephyr.map file, but omit the "0x" when searching (example: 0x200015c8 -> 200015c8).

This way, you can see which thread the assert came from.

Could you do this and post the results of addr2line on "LR" and "PC"?

Kind regards,

Håkon

RE: nrf5340 ble secure fault

adunk — Thu, 18 Apr 2024 11:33:20 GMT

Here's the updated fault that occurs after I'm told the pairing is complete.:

[00:00:06.681,945] <inf> ble_supv: Regular advertising started

[00:00:06.789,520] <inf> ble_supv: Connected
[00:00:07.242,218] <inf> ble_supv: LESC OOB data requested

[00:00:07.843,933] <inf> ble_supv: Pairing completed: D1:3A:F6:65:C0:9C (random) , bonded: 1

[00:00:07.843,963] <err> os: ***** BUS FAULT *****
[00:00:07.843,963] <err> os: Precise data bus error
[00:00:07.843,963] <err> os: BFAR Address: 0x4559
[00:00:07.843,994] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000001 r2/a3: 0x0 0004559
[00:00:07.843,994] <err> os: r3/a4: 0x20005988 r12/ip: 0x00000000 r14/lr: 0x0 0000edb
[00:00:07.843,994] <err> os: xpsr: 0x21000000
[00:00:07.843,994] <err> os: Faulting instruction address (r15/pc): 0x000138c6
[00:00:07.844,024] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:07.844,085] <err> os: Current thread: 0x200015c8 (unknown)

The pairing complete callback where the log statement occurs and the bus fault seems to occur:

static void pairing_complete(struct bt_conn *conn, bool bonded)

{

char addr[BT_ADDR_LE_STR_LEN];

bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));

LOG_INF("Pairing completed: %s, bonded: %d\n", addr, bonded);

k_poll_signal_raise(&pair_signal, 0);

bt_le_oob_set_sc_flag(false);

bt_le_oob_set_legacy_flag(false);

}

RE: nrf5340 ble secure fault

adunk — Wed, 17 Apr 2024 18:01:48 GMT

I have changed the dts from _ns to nrf5340dk_nrf5340_cpuapp.dts and am no longer seeing the SECURE FAULT to try to isolate it to whether it is a TFM issue. Here's the new fault which occurs at exactly the same location when the BLE pairs:

[00:00:06.844,848] <inf> ble_supv: Pairing completed: D1:3A:F6:65:C0:9C (random), bonded: 1

[00:00:06.844,879] <err> os: ***** BUS FAULT *****
[00:00:06.844,879] <err> os: Precise data bus error
[00:00:06.844,909] <err> os: BFAR Address: 0x4559
[00:00:06.844,909] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000001 r2/a3: 0x00004559
[00:00:06.844,909] <err> os: r3/a4: 0x20005988 r12/ip: 0x20001808 r14/lr: 0x00000edb
[00:00:06.844,940] <err> os: xpsr: 0x21000000
[00:00:06.844,940] <err> os: Faulting instruction address (r15/pc): 0x000138c6
[00:00:06.844,970] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:06.845,001] <err> os: Current thread: 0x200015c8 (unknown)