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]

Hi David,

I did not change Simons list function.

It worked as is. But I have not tried to upload a new image yet, meaning only 1 image lives on the device.
It only lists 1 slot in this case. I suspect it will list 2 slots if I upload an image to the secondary slot.

I will let you know when I have tested this.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

I am able to use Simons sample to upload images in v2.0.0.

However, it fails in v2.2.0, and I have not been able to figure out why yet.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

I am now able to perform DFU in v2.2.0.

To track my changes, I uploaded Simons's sample to my GitHub as an SMP Central Sample.
The issue was that the flash driver device had to change.

In addition, I added MCUboot and mcumgr functionality to the sample to make it easier to upload new images to the device.

Does this sample work for you?

Is the next step to do the DFU without using flash to store the image between the transfer?

Regards,
Sigurd Hellesvik

[DavidKaplan]

Thank you very much.

I will have to look at the sample tomorrow and I will get back to you.

I am working on a different high priority issue right now.

Thanks David

[DavidKaplan]

I started to check this when I was pulled back off it for other critical things.

Maybe tomorrow.

I have three questions

1) send_smp_reset

 In the Github code it looks like the fix you made to this function was not updated:

Fix:
smp_cmd.header.len_h8 = (uint8_t)((payload_len >> 8) & 0xFF);
smp_cmd.header.len_l8 = (uint8_t)((payload_len >> 0) & 0xFF);

 GitHub;

smp_cmd.header.len_h8 = 0;
smp_cmd.header.len_l8 = 0;

2) send_upload2

 In the packet format, the len should be always 0x5B68?

 I thought it was the image length but your image size in the example is not this.

   zcbor_tstr_put_lit(zse, "len");

   // zcbor_uint64_put(zse, (uint64_t)ami_state->dfu.ImageSize.ulong);

    zcbor_uint64_put(zse, (uint64_t)0x5B68);

3) When I compile, I get a warning when string compare is used with a word and not a string.

I guess this is OK from my previous debugging, I just try to get rid of warning so I will notice new ones.

ami_smp.c:752:35: warning: multi-character character constant [-Wmultichar]
752 | } else if(!strncmp(value.value, 'rc', 2)){

zcbor_uint64_put(zse, (uint64_t)0x5B68);

Thanks David

[DavidKaplan]

Another question.

In send_upload2(), the start and last addresses are taken from the bootloader partisan.

The image uploaded is of variable size.

Does the current code just return with "flash_read failed with error:" ?

Or where is the image file length used?

int last_addr = PM_MCUBOOT_SECONDARY_END_ADDRESS;
int start_addr = PM_MCUBOOT_SECONDARY_ADDRESS;

...

err = flash_read(flash_dev, curr_addr, data, upload_chunk);
if (err != 0) {
  printk("flash_read failed with error: %d\n", err);
  return;
}

Thanks David