BLE DFU Over SMP With Matter

I was able to turn ON  the Nordic’s BLE DFU over SMP + BLE  NUS   using  Matter Lock sample code successfully.  

The “DFU over SMP” is really great  but further customization is needed for us.

The service is always  ON (before  or after Matter  provisioning)  from power up. In our use case, we want the service to not start after power up. The user will select  when to upload the new FW (this is like buttonless DFU).

  1. Can you please let me know how we can achieve the below?
    1. The DFU over SMP is not started at power up.
    2. The service is started and stopped  by our Application code.
    3.  I looked at the “dfu_over_smp.cpp” which  has the API’s for Init and StartServer. It does not have an API for stopping the service. I added the code to stop the services (the NUS has a stop service). and tried. It  stops the service and  also affected the Matter BLE services and provisioning.
  2. How do we add security and bonding (it is my understanding that Matter standard prohibits bonding)?

I am looking for additional documentation and recommendations. It is possible for me  to modify the source code however; it will make the migration to (future) SDK updates very difficult.  The nRF54L15 is  supported from V2.7.0 and since it is new, I am expecting improvements in the future SDK releases.

The target platform is nRF54L15 and  the SDK is V2.7.0.

Thanks in advance!

Subu

  • Hi Subu,

    I will need some time to look into your questions. I will follow-up with you next week.

    Hieu

  • Hi Hieu,

    Can you please let me know the updates?  Thank you.

  • Hi Subu,

    Sorry it took a long time. I would like to be more certain before I reply to you, but since it's so late already, here is what I have found:

    Can you please let me know how we can achieve the below?
    1. The DFU over SMP is not started at power up.
    2. The service is started and stopped  by our Application code.

    First, you need CONFIG_BT_GATT_DYNAMIC_DB and CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION, though the latter config selects the first one.

    Note that the SMP Server is still registered after initialization regardless, so you need to unregister it first, if you want the device to start without SMP Server by default.

    After that, you just register and unregister the service as needed.

    Next comes the part where I am not sure, which is where all of that should be done. I am new to Matter and C++, so I am not 100% sure, but it seems all BLE operations are done via the BLEManagerImpl and BLEAdvertisingArbiter singletons.

    However, I don't see how to register and unregister service using the existing Matter APIs yet.

    How do we add security and bonding (it is my understanding that Matter standard prohibits bonding)?

    Matter spec, section 5.4.2.5, requires that BLE Advertising be done with Random Static Address, and that this must be changed every boot.

    However, in BLE, if bonding happens, the Random Static Address is treated as an Identity Address. Then if the Identity Address is changed, then the peer will not be able to find the device anymore.

    I think this is what has led you to understand that Matter prohibits bonding.

    If so, note that section 5.4.2.5 says this:

    5.4.2.5. Using BLE
    This section provides details of how a device announces its commissionable status using BLE technology.
    Nodes currently commissioned into one or more fabrics SHALL NOT employ this method.
    NOTE Need to add link(s) to BLE specification.

    So, the Random Static Address requirement is only applicable to the Matter BLE Service for Commissioning purposes.

    Therefore, if we create a separate BLE identity, and setup the other BLE services on that ID, then bonding can happen.

    It's here that I also arrived at the same issue: I don't know how to implement the additional ID with Matter's setup yet.


    Do you think that these are sufficient tips for you to continue your project yet?

  • Hi Hieu, I don't think the information that you provided will be enough for me to continue the project.

    As you mentioned, all the BLE operations are done via BLEManagerImpl and BLEAdvertising Arbiter singltons.

    I already tried adding a code/call for shutting down the BLE DFU services using the BLE advertising Arbiter (BLE NUS services has an example) and when I do that, it  messes up the Matter BLE advertisement also.

    The code for shutting down the BLE service is already there. Nordic needs to add that to the DFU service.

    The API for starting and stopping Matter BLE advertisement is also there. All we need is that someone from Nordic Matter team to look and specify it. It will help not only me but every company. Currently, the DFU service will not be usable because it allows anyone to upload a file. So what I am asking will be useful for everyone.

    Can please ask the Matter team for  what changes will be required to shutdown, and start the BLE services carefully without impacting Matter BLE? 

    Thanks.

    Subu

  • Hi Subu,

    I am still looking into the issue. My apology for the wait.

    SubuMuthu said:
    Currently, the DFU service will not be usable because it allows anyone to upload a file. So what I am asking will be useful for everyone.

    Would an alternative solution be to limit BLE accessibility to only user with physical access?

    Regards.

    Hieu

Related