DFU and Static Passkey Support for BLE_Gateway Example

[rifatmahmud]

Can dfu and Passkey support be enabled in BLE_Gateway example. Any lead into this issue would be very helpful. Thanks.

[trond-snekvik]

Could you extend a bit on what you're looking for when you say passkey?

We are working on DFU at the moment, and expect to have something sometime this month. We aim to do a mesh-wide concurrent update (no device-by-device update, that's too slow), where you can choose to update your application, Softdevice or bootloader. We're also planning on adding a signing mechanism to the DFU, to ensure that no one overloads your firmware without authorization. We're looking into serial-access to DFU atm, but if there's interest, we might provide a GATT-interface version (although that might have some implications on what parts of the FW you can update). The intention is to target all versions of the nRF51 with DFU (including the 128kB Flash version).

We haven't looked too much into adding single-device DFU support, but if you want, it should be possible to implement the SD BLE DFU mechanism with the mesh. This requires some adjustments from your application, but there's nothing in the mesh framework explicitly stopping you.

[rifatmahmud]

Here are the situations I am facing.

BLE Gateway example allows any mobile application to connect to it GATT service, without any authentication. I tried to add the authentication, as demonstrated in various nRF51 SDK examples, but failed to do so. I assume, it need some changes on your main rbc_mesh library, also need to enable device_manager, which is not available in the mesh examples.

In case of DFU, I actually want the OTA one. To enable dfu on rbc_mesh examples, I also need to have device_manager. The examples are not clear enough for me on how to do it successfully.

[olsky]

@trond-snekvik :+1:

a mesh-wide update is the first thing which comes after having mesh at all :) much appreciated! I would contribute to it as well.

thumbs up! great work guys you rock :100:

Cheers OL

[trond-snekvik]

I see. I actually think you can get away without altering the mesh itself, you just have to be careful about your ordering when initializing.

I think it's best to attack the problem from the other side of things - integrate the mesh into an SDK example which uses the device manager, OTA DFU and passkey handling rather than adding it to the mesh. For instance, the ble_app_hrs example (under ble_peripheral in SDK8.1) is a rather clean implementation of what you're looking for, with some additional sensor simulation and a couple of extra services that you don't need but can easily remove. I made a fast gist of the main.c file in that example that you can replace the original with here. I haven't added any mesh functionality, but you should be able to insert mesh_init() at line 607. You also have to look into intercepting GATT- and soc-events. GATT events end up in ble_evt_dispatch(), soc-events in sys_evt_dispatch(). Call rbc_mesh_ble_evt_handler() and rbc_mesh_sd_evt_handler() in these callbacks respectively.

I'm sorry that I can't provide a full example at this point, but I'll put it up on the todo-list.

@olsky: Thanks, we want to do a couple of iterations on the DFU-project to see what works and what doesn't, and will be very happy for all the feedback and contributions we can get :+1:

[olsky]

@trond-snekvik would be great! looking forward to get some previews :)

What I'm on currently:

• dedicated a channel for DFU (say ch:0), where I place my custom command packets (start dfu, data, end)
• start dfu has info on: size, SD or APP, a crc
• data packet has a sequence number and a fragment of the data, which are written to flash
• on dfu-end event/packet -- check crc and if all ok -> replace and restart.

Currently a tricky part is to set the right send-packet frequence time, as if it is too short I get the value not propagated to all the nodes. This brough me to a small multicast-test-value function to check the propagation time over the whole mesh.

just my two cents :)