Keep BLE Connection alive during a DFU

[rgangwan]

Hello!

I have been using the nRF Connect SDK and implementing DFU into my application.

My app currently advertises and connects on an interval (defined in an RTOS thread) as a means of power saving.

So for example, every 60 seconds of being idle I start advertising. I then advertise/connect for only 30 seconds before turning off and staying idle again.

Now, I have added DFU and tested with the nRF Connect App. Due to only connecting for 30 seconds, if the DFU package is too long and takes too much time the peripheral disconnects and the DFU fails to send. 

There are either two things I think I can do:

1. Determine (through some interrupt handler ) that a DFU package needs to be sent and dynamically change the ON interval (so it stays connected for longer -- long enough to accept the full DFU package)

2. Find a way that when a DFU process starts, the connection is kept on until it completes (either the bootloader keeps the connection alive, or some other configuration exists to make this possible)

In the old nRF5 SDK, I had done this same thing before, and it seems like then the DFU package was small enough to complete within 30 seconds. Now, with the nRF Connect SDK, it takes around 1min before an update completes (using an MTU of 498). 

I am unaware if the second solution is an option, but that would be ideal. Otherwise, I'm not sure how, upon receiving a request to DFU, can change in the application code the interval at which I stay connected.

Any assistance is appreciated! Thanks!

[nordicator_prim3]

Hello,

(I'm not with nordic just a random dude). I've run into similar problems and I don't see a good way to hook into the smp code without changing it, but there may be something I'm missing!

It would be ideal if your device wasn't always in "DFU mode"; is there a button press or a bluetooth command you could send to it that would tell it to be in "DFU mode"? That would give you a way to know to expect that longer duration transmission and it would also prevent random people from putting firmware on the device when you didn't intend them to.

The way I've handled it in the past is to advertise on a different GATT/attributes than the smp server one for my main application. The application can then parse ocmmands sent to it over bluetooth from an app or computer or something. When I do want to upgrade the firmware I send a command to it that says to stop advertising the application GATT and to start advertising the way smp server expects. Then you would have a hook that would let the bluetooth stay on long enough to complete the transaction.