nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

[DavidKaplan]

We have nrf52840 S140 BLE Central device that currently connects to TI based sensors. I have implemented code that can upgrade those TI sensors' firmware using the TI BLE protocol.

Now we are developing our own BLE peripheral sensors also based on the nrf52840 but now using the newly supported Zephyr 2.0.0. RF connect stuff. I can update the sensors using the Nordic Android program (unauthenticated for now) and now need to implement upgrading BLE DFU using our central device which connects to a cellular gateway.

I do not want to reinvent the wheel, writing existing code, like I had to do with the TI sensors.

Could you point me to code that allows a Central device to update a peripheral device BLE DFU?

If not where can I look to reinvent another wheel?

Thanks David

[Sigurd Hellesvik]

DavidKaplan said:

When pressed button#2 and saw that the central tries to upload all of second slot and not just the image size.

Is this what you saw too?

Maybe I should upload with my code the entire slot instead of just the app_update.bin file size?

Yes. I think it is a good idea to start by uploading the entire slot.
Then if that works, we can try to upload less data after.

DavidKaplan said:

Should the padded data be zero or 0xFF?

Are you generating the file manually?

I recommend that you first try to use build/zephyr/app_update.bin without any changes.

DavidKaplan said:

So, I can't reproduce a DFU successfully like you, so it is evident that I am doing more than one thing wrong.

I will upload a video to the private case of how I do this so you can look at all my steps in detail.
I hope that can be helpful.

Regards,
Sigurd Hellesvik

[DavidKaplan]

Finally!

 I watched your video (a big effort on your part, thank you) and tried the following that solved all of my SMP DFU problems.

It works in my custom central board with the image being streamed from a host.

1) Upload whole sensor slot size (not central slot size) or until I get an error#1 in smp_upload_rsp_proc() 

"Error in image upload response:1" after actual image was already transferred.

The data I upload in the slot after the actual image I just set to 0xFF. I don't think that this really matters.

2) Increased smp_buffer payload to handle larger chunks. My MTU is 498 I think. I can use a chuck size of 428.

I just increased its size to 512 to be safe. When 300 is used you sure don't need 512 if you are short on ram.

/* Buffer for response */
struct smp_buffer {
struct bt_dfu_smp_header header;
uint8_t payload[512]; // was 300
};
#define UPLOAD_CHUNK 424 // (50 worked) This has to be at least 32 bytes, since first it has to send the whole header (which is 32 bytes)

This has been a long ride and I really appreciate your help.

One last thing.

Could you point me to a current thread about adding back the key to the bootloader in Zephyr v2.2.0 ?

Thank you!

David

[Sigurd Hellesvik]

DavidKaplan said:

Finally!

Hurray!

I still remember you asking if it is possible to stream the data directly instead of storing it in the flash of the SMP Central.
We do not have a solution for that, so you will have to make it yourself if you need it.
But now that you can perform an update from the SMP Client with flash storage, it is a good starting point!

DavidKaplan said:

Could you point me to a current thread about adding back the key to the bootloader in Zephyr v2.2.0 ?

Official documentation can be found at Adding MCUboot as an immutable bootloader.

I have an unofficial sample of adding this using CMake for relative paths at MCUboot Custom Key with SMP Server.

Regards,
Sigurd Hellesvik