nrf5340 ble secure fault

[adunk]

My setup is a custom board with a nrf5340 which acts as the BLE Central and SDK 2.6.99. When I use a 52833 DK as the peripheral which has the BAS service I can connect and pair using OOB pairing and receive the BAS notifications. But when I use the 5340 DK, right when the BLE connects I get a:

[00:00:05.810,882] <err> os: ***** SECURE FAULT *****
[00:00:05.810,913] <err> os: Address: 0x0
[00:00:05.810,913] <err> os: Attribution unit violation
[00:00:05.810,913] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000001 r2/a3: 0x0 0000020
[00:00:05.810,943] <err> os: r3/a4: 0x20009d50 r12/ip: 0x20009880 r14/lr: 0x0 0008edb
[00:00:05.810,943] <err> os: xpsr: 0x21000000
[00:00:05.810,943] <err> os: Faulting instruction address (r15/pc): 0x0001b8a2
[00:00:05.810,974] <err> os: >>> ZEPHYR FATAL ERROR 41: Unknown error on CPU 0
[00:00:05.811,004] <err> os: Current thread: 0x20009638 (unknown)

I can't find any documentation on a SECURE FAULT. 

My settings:

CONFIG_LOG=y

CONFIG_GPIO=y

CONFIG_SERIAL=y

CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_UART_LINE_CTRL=n

CONFIG_MODBUS=y

CONFIG_MODBUS_ROLE_SERVER=y

# Enable the BLE stack with GATT Client configuration

CONFIG_BT=y

# Enable the BLE stack with GATT Client configuration

CONFIG_BT_PRIVACY=n

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_SMP=y

CONFIG_BT_SMP_APP_PAIRING_ACCEPT=y

#add support for BAS

CONFIG_BT_DIS=y

CONFIG_BT_BAS=y

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_MAIN_STACK_SIZE=3072

# This example requires more workqueue stack

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_POLL=y

# Enable bonding

CONFIG_BT_SETTINGS=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_FLASH_MAP=y

CONFIG_NVS=y

CONFIG_SETTINGS=y

#enable comm between cores

CONFIG_BT_HCI_IPC=y

CONFIG_MBOX_NRFX_IPC=y

[adunk]

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)

[adunk]

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);

}

[Håkon Alseth]

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

[adunk]

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)

[adunk]

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.