Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

RE: Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

Doug K — Thu, 29 May 2025 14:15:51 GMT

Thank you. I will try those out.

RE: Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

Hieu — Wed, 28 May 2025 23:18:15 GMT

[quote user="Doug K"]So I believe my only solution is to configure the board without TF-M using trusted storage feature, correct?[/quote]

I don't think you need to give up TF-M. CONFIG_TFM_SECURE_UART20 or CONFIG_TFM_SECURE_UART21 should work. You can use either of them and overlay the application DeviceTree to disable the corresponding UART instance instead.

I am out of office now and cannot verify it; but if you want to use TF-M, please give it a try.

As for adding CONFIG_TRUSTED_STORAGE, it is not necessary because the Mesh stack will try to enable it. It doesn't hurt to explicitly set it though.

RE: Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

Doug K — Wed, 28 May 2025 22:01:57 GMT

UART30 is required for my application as I am using the pins on port 0. Doing a new Rev of the board is not an option at this point in the project.

So I believe my only solution is to configure the board without TF-M using trusted storage feature, correct? To do this I'd simply add to my board file or prj.conf:

CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE=n
CONFIG_SPI_NOR=n
CONFIG_NVS=n
CONFIG_NVS_LOOKUP_CACHE=n
CONFIG_SETTINGS_NVS_NAME_CACHE=n
CONFIG_ZMS=y
CONFIG_SETTINGS_ZMS_CUSTOM_SECTOR_COUNT=y
CONFIG_SETTINGS_ZMS_SECTOR_COUNT=8
CONFIG_ZMS_LOOKUP_CACHE=y
CONFIG_ZMS_LOOKUP_CACHE_SIZE=512
CONFIG_ZMS_LOOKUP_CACHE_FOR_SETTINGS=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=5120

and also add:

CONFIG_TRUSTED_STORAGE=y

Thanks, I will give this a shot. Let me know if there are any more caveats.

RE: Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

Hieu — Wed, 28 May 2025 21:11:55 GMT

Hello Doug K,

[quote user=""]1) Why does the Bluetooth Mesh Provisioning Sample require the Non-Secure build? Can it work with the "cpuapp" build with some config options added?[/quote]

From NCS v3.0.0, the Bluetooth Mesh stack uses PSA Crypto API instead of the deprecated TinyCrypt API. The Trust Storage feature of this new API requires ZMS on the nRF54L15 secure target, which isn't enabled by default.

Samples specific to NCS have been updated to account for that. However, the sample you are using is from Zephyr, and didn't have this setup yet.

The simplest fix is to copy the content ofnrf54l15dk_nrf54l15_cpuapp.conf file from a sample under nrf/samples/bluetooth/mesh to your project's configurations.

[quote user=""]2) If I need to use the Non-Secure version, is disabling UART30 required?[/quote]

On the Non-Secure target, UART30 is reserved for TF-M. The simplest way is to use a different UART instead. Is that possible for you?

Regards,

Hieu

RE: Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

Doug K — Tue, 27 May 2025 18:19:01 GMT

I am having some issues posting the console output here. I'll see if I can get a shortened version posted:

ncs/toolchains/0b393f9e1b/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr/libzephyr.a(trusted_backend_aead.c.obj): in function `trusted_get_info':

ncs/v3.0.1/nrf/subsys/trusted_storage/src/aead/trusted_backend_aead.c:62: undefined reference to `storage_get_object'

ncs/v3.0.1/nrf/subsys/trusted_storage/src/aead/trusted_backend_aead.c:102: undefined reference to `storage_get_object'