Bluetooth mesh Provisioning with NRF54L15 and SDK 3.01

I have a couple questions regarding the Bluetooth Mesh provisioner role and TF-M builds.

I am using an NRF54L15 and currently swapped to v3.01. Previously on versions <3.0 I was able to build my app that provisions BLE Mesh devices using the cpuapp version of the board. Now I it only compiles using the Non-secure TF-M version. 

Using the TF-M version is fine, only problem I have is that I was looking at the board file and UART30 is disabled when using the non-secure version. I am using UART30 for my custom board. 

So my questions are:

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?

2) If I need to use the Non-Secure version, is disabling UART30 required?

You can duplicate my problem using the "mesh_provisioner" sample with the NRF54L15DK with SDK v3.01. 

Thanks,

Parents
  • 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'

    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_set':

  • Hello Doug K,

    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?

    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.

    2) If I need to use the Non-Secure version, is disabling UART30 required?

    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

Reply Children
  • 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. 

  • Doug K said:
    So I believe my only solution is to configure the board without TF-M using trusted storage feature, correct?

    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.

Related