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

[DavidKaplan]

This morning I found a few problems:

 a) I am still using v2.0.2 for this project but applied the patch correctly in zcbor_decode.c only in v2.2.0 which I am using for newer projects.

 b) I fixed a problem keeping my ring buffer full. I use a ring buffer with the image streamed from the host to the central instead of from the central's flash.

 c) My custom printf function was evidently causing a problem in smp_upload_rsp_proc() so instead of printing, I just update an error parameter

I was able to finish uploading the send_upload2() function or at least it does not show any error.

Now I understand that I need to call send_smp_test() to set the pending flag but it gives an error.

I then saw that it uses the hash_value_secondary_slot variable as a parameter so I try to call send_smp_list() first so it will be updated.

When I call send_smp_list() the central resets.

I tried to call bt_disable() in send_smp_list() so I could single step to where the problem is, but this did not help as the ble crashes. How can I find the problem?

My sensor boards have the standard nRF52840 image setup.

So, I understand that I need to list,test & reset the sensor board?

Thanks David

[DavidKaplan]

As happens all too often, I awoke in the middle of the night and thought that I could debug the smp_list_rsp_proc() function by disconnecting the sensor 's BLE at the start of the function.

I found the reason for the smp_list_rsp_proc() function's problem in my case.

I found that my sensors are returning what is called the version_key with a length of 7 bytes whereas there are only 5 allocated. I just changed this to 16 for now and no crashes after removing the sensor disconnect lines which I inserted for debugging.

			//Decoding version key 
			char version_key[5]; // my key is 7 ?!?
			ok = zcbor_tstr_decode(zsd, &value);
			if (!ok) {
				printk("Decoding error, version key (err: %d)\n", zcbor_pop_error(zsd));
				return;
			}  /*else if (value.len != 6) {

I am testing my code now, but I have a couple of new questions.

1) I have a MTU of about 491 when uploading. I set the  UPLOAD_CHUNK to 400 in send_upload2().

I would like to calculate the payload at runtime according to the current MTU.

I am a little stuck on figuring out the whole payload size.

send_upload2()
...
  while (!update_complete){
           uint16_t mtu = bt_gatt_get_mtu(dfu_smp.conn);
           uint16_t user_payload_len = ?!?
             ...
			(zse->payload - smp_cmd.payload);
             ...			
           if (user_payload_len>(mtu-header_size)){
             user_payload_len = (mtu-header_size);
           }

2) My sensor code is currently quite large 365 KB (373,888 bytes).

I saw a broken link that might help in the release version to safely cut its size.

 Best practice advice for Zephyr debug and release configurations. 

I will get back on my DFU testing.

Thank you David

[Sigurd Hellesvik]

Hi David,

I will continue helping you with this case.

There are two ways to mark an DFU image as "test".
One is to use the SMP command.
The other is to tag the image before you send it.

For debugging purposes, can you try the second one as well?

I'm thinking that if you upload a "pre-tagged" image to the SMP Server, it should automatically update on its next reboot.

To sign an image manually you use imgtool.
To mark it as "test" you use the "--pad" option.

The command will look something like this:

<NRF_CONNECT_PATH>/bootloader/mcuboot/scripts/imgtool.py sign --header-size 0x200 --align 4 --slot-size 0x79e00  --version 1.0.0 --pad-header --pad --key <SIGNING_KEY_PATH> build/zephyr/app_to_sign.bin app_manually_signed.bin

To find the other variables used for this command (to generate app_update.bin), you can use "west -vvv build -p -b <BOARD_NAME>" and search the log for "imgtool".

Does the image swap if you mark the image as "test" before uploading it?

EDIT: Did not see your previous message before I sent this one.
I will read through it now.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Read through your newest message, and here are my comments for now:

DavidKaplan said:

2) My sensor code is currently quite large 365 KB (373,888 bytes).

I saw a broken link that might help in the release version to safely cut its size.

 Best practice advice for Zephyr debug and release configurations. 

I will get back on my DFU testing.

We have some official docs on optimizing memory usage on Optimizing application.
I would probably start by having a look at the tips there.

DavidKaplan said:

1) I have a MTU of about 491 when uploading. I set the  UPLOAD_CHUNK to 400 in send_upload2().

I would like to calculate the payload at runtime according to the current MTU.

I am a little stuck on figuring out the whole payload size.

I will have to look into this as well, and will let you know what I find out.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Hi again,

Sorry for the quick succession of answers,
but I asked a colleague who knows a bit more than me about Bluetooth Low Energy, and they say that the MTU is the payload size + 3 bytes of op-code and handle:
payload = mtu - 3

Regards,
Sigurd Hellesvik