Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Sydney — Mon, 26 Nov 2018 02:28:08 GMT

If anyone comes across this in the future, it's worth mentioning that I did go the route of porting my entire project, application and bootloader, to SDK 15.2. Where I was previously getting about 2.2-2.4KB/s max with the desktop version of nRF Connect (using an nRF52840 USB dongle as its radio), I now get about 10KB/s with the connection interval configured to 7.5ms (minimum possible). So a 4-5x improvement compared to SDK14. My Galaxy S9 running Android 8.0 is a bit slower at around 8-9KB/s, probably due to Android's inability to set the connection interval any lower than 11.25ms.

I got those speeds using the BLE debug version of the secure_bootloader example, changing essentially nothing in the code except some LED stuff to get it compiling for my board. I updated sdk_config.h to set minimum connection interval to 7.5ms. I also configured it to override the default number of BLE DFU buffers (which appeared to be 16-17 if I followed the macros correctly) and set it to 32 buffers, but that didn't seem to make a difference. I'm not sure if there are any other settings that may be able to get it to go any faster, but I'm pretty happy with the improvements already.

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Sydney — Sat, 17 Nov 2018 09:03:03 GMT

Good to know. Do you know the data rate you're getting on the transfer with SDK15? Or do you know how big your firmware image is?

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Andy — Sat, 17 Nov 2018 08:33:25 GMT

But I migrated from SDK 13, I don't know what the performance of SDK 14 is.

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Andy — Sat, 17 Nov 2018 08:32:50 GMT

For me, an update that used to take roughly 1.5 minutes now finishes in 15 seconds.

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Sydney — Sat, 17 Nov 2018 08:27:36 GMT

Thanks for the feedback. I think I am going to take a bit of time to size up the work involved with just porting everything to SDK 15.2.

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Sydney — Sat, 17 Nov 2018 08:26:28 GMT

Thanks. This isn't the answer I was hoping for, but it is the clarification I needed. I'm going to take a day or so to see how much work it will be to just port my whole project over to SDK 15.2, but I have a feeling I'm going to end up just sticking with SDK 14 across the board.

Do you have any idea how much faster the SDK15+ BLE bootloader updates have made the transfer process?

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Andy — Thu, 15 Nov 2018 09:00:31 GMT

If you haven't customized the bootloader, migrating it to SDK 15 is pretty easy. I also didn't have a lot of trouble migrating my application from SDK 14 to 15. I wouldn't consider migration a horrible idea.

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Einar Thorsrud — Thu, 15 Nov 2018 08:53:07 GMT

Hi,

1) Using larger MTU and DLE is not enough to get to the same speeds as the bootloader from SDK 15. The request handling library was entirely rewritten to be more efficient. The buffer management in the SDK 14 bootloader is the main bottleneck that was improved.

2) If you want to use the SDK 15.2 bootloader, then I suspect it is easier to migrate the application as well. The alternative is as you write, to migrate the SDK 15.2 bootloader to S132 version 5, but I am not convinced that it will be less work.

3) It is definitely possible to use an application based on SDK 14 and a bootloader based on SDK 15.2. However, that means that you have to migrate one of them to a different SoftDevice API, and there have been significant changes. There are also a few other changes related to buttonless DFU, bond sharing etc. that you may need to account for.

Without knowing details of your application, I would assume that the effort put in to migrating the application to a new SDK version or bootloader to a different SoftDevice version is similar, and then it seems to me that migrating your application to SDK 15.2 is the best solution (unless you just stick with everything from SDK 14, including a slower bootloader).

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Sydney — Wed, 14 Nov 2018 18:12:01 GMT

I agree that ideally we would rarely need to do firmware updates. But the reality is that we will likely need customers to be able to do it at some point, and three minutes per device is a pretty tough ask of our users when some users may be managing tens or more of our devices. And I currently have a small window where bootloader changes are much easier to make than they will be going forward, so I'm hoping to get some optimizations in now.

So a few questions on the topic.
1) It seems like it shouldn't be that difficult to get MTU and DLE negotiation working on the SDK14 bootloader. But even if I can get it working, would DFU transfer speed even benefit? Or does the bootloader also need the other changes from SDK15+ to benefit from longer MTUs and DLE?
2) Porting our application to SDK15.2 is probably quite a bit more work than just porting over our bootloader, so I'd really like to avoid going down that route if possible. So if our application is SDK14 with S132 v5.0.0, would there be any issues trying to use an SDK15.2 bootloader that must also use S132 v5.0.0?
3) Related to 2, would there be any concerns about running an application based on SDK14 but a bootloader based on SDK15.2?

RE: Can the SDK15 BLE DFU speed improvements be backported to an SDK14 bootloader?

Einar Thorsrud — Wed, 14 Nov 2018 14:14:55 GMT

Hi,

You are right that there are a lot of changes between SDK 14 and SDK 15. Particularly the bootloader was significantly modified, so unfortunately it is difficult to isolate all changes. DFU is typically not performed very often by the end customer so I suggest you consider sticking with the current bootloader. Alternatively, migrating to the full SDK 15.2 bootloader could be an option.