nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

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

Parents
  • 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

Reply
  • 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

Children
  • 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

  • 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

  • Hello everyone,

    I am trying to get the smp_client_ble sample to work, provided in: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/client_smp/smp_client_ble

    However it seems that the ZCBOR library has been updated and the included patch does not work anymore. I tried following this ticket and doing some changes, for example increasing the size of the array version_key and changing functions like zcbor_new_decode_state() to match the lastest ZCBOR update, however the image list, upload, and confirm are not working at all.

    I am getting the following errors:

    1) image list:

    f3--- 8 messages dropped ---
    bed5ea8b2112f4cc6a153cdc7f2fc11c2c485a221d317bf5135
          bootable: true
    Decoding error, pending value (err: 11)

    2) upload 

     --- 11 messages dropped ---
                                           | (0/483328 bytes)Error in image upload response: 1

    3) test

    Decoding error, start_decode images->list  (err: 10)

    Here are the errors with CONFIG_ZCBOR_VERBOSE enabled:

    1) image list:

    zcbor_map_start_decode New backup (level 0)
    zcbor_tstr_decode rem: 133, cur: 0x66, ec: 0xfffffff0, err: 0, value_extract
    zcbor_list_start_decode New backup (level 1)
    zcbor_map_start_decode New backup (level 2)
    zcbor_tstr_decode rem: 124, cur: 0x64, ec: 0xfffffff0, err: 0, value_extract
    zcbor_int32_decode zcbor_int_decode rem: 119, cur: 0x0, ec: 0xffffffef, err: 0, value_extract
    zcbor_tstr_decode rem: 118, cur: 0x67, ec: 0xffffffee, err: 0, value_extract
    zcbor_tstr_decode rem: 110, cur: 0x65, ec: 0xffffffed, err: 0, value_extract
    zcbor_tstr_decode rem: 104, cur: 0x64, ec: 0xffffffec, err: 0, value_extract
    zcbor_bstr_decode rem: 99, cur: 0x58, ec: 0xffffffeb, err: 0, value_extract
    zcbor_tstr_decode rem: 65, cur: 0x68, ec: 0xffffffea, err: 0, value_extract
    zcbor_bool_expect zcbor_simple_expect zcbor_simple_decode zcbor_simple_decode rem: 56, cur: 0xf5, ec: 0xffffffe9, err: 0, value_extract
    zcbor_tstr_decode rem: 55, cur: 0x67, ec: 0xffffffe8, err: 0, value_extract
    zcbor_bool_expect zcbor_simple_expect zcbor_simple_decode zcbor_simple_decode rem: 47, cur: 0xf4, ec: 0xffffffe7, err: 0, value_extract
    simple value 20 != 21
    ZCBOR_FAIL rem: 47, cur: 0xf4, ec: 0xffffffe7, err: 11, WEST_TOPDIR/modules/lib/zcbor/src/zcbor_decode.c:1081
    f3--- 8 messages dropped ---
    bed5ea8b2112f4cc6a153cdc7f2fc11c2c485a221d317bf5135
          bootable: true
    Decoding error, pending value (err: 11)

    2) upload:

    rem: 299, cur: 0x65, ec: 0x0, err: 0, value_encode_len
    rem: 293, cur: 0x0, ec: 0x1, err: 0, value_encode_len
    rem: 292, cur: 0x64, ec: 0x2, err: 0, value_encode_len
    rem: 287, cur: 0x58, ec: 0x3, err: 0, value_encode_len
    rem: 135, cur: 0x63, ec: 0x4, err: 0, value_encode_len
    rem: 131, cur: 0x1a, ec: 0x5, err: 0, value_encode_len
    rem: 126, cur: 0x63, ec: 0x6, err: 0, value_encode_len
    rem: 122, cur: 0x0, ec: 0x7, err: 0, value_encode_len
    rem: 121, cur: 0x63, ec: 0x8, err: 0, value_encode_len
    rem: 117, cur: 0x45, ec: 0x9, err: 0, value_encode_len
    rem: 111, cur: 0x67, ec: 0xa, err: 0, value_encode_len
    rem: 103, cur: 0xf4, ec: 0xb, err: 0, value_encode_len
     --- 10 messages dropped ---
                                            | (0/483328 bytes)zcbor_map_start_decode New backup (level 0)
    zcbor_tstr_decode rem: 5, cur: 0x62, ec: 0xfffffff0, err: 0, value_extract
    zcbor_int32_decode zcbor_int_decode rem: 2, cur: 0x1, ec: 0xffffffef, err: 0, value_extract
    Error in image upload response: 1

    3) test:

    rem: 299, cur: 0x64, ec: 0x0, err: 0, value_encode_len
    rem: 294, cur: 0x58, ec: 0x1, err: 0, value_encode_len
    rem: 260, cur: 0x67, ec: 0x2, err: 0, value_encode_len
    rem: 252, cur: 0xf4, ec: 0x3, err: 0, value_encode_len
    zcbor_map_start_decode New backup (level 0)
    zcbor_tstr_decode rem: 5, cur: 0x62, ec: 0xfffffff0, err: 0, value_extract
    zcbor_list_start_decode ZCBOR_ERR(10) ZCBOR_FAIL rem: 2, cur: 0x1, ec: 0xffffffef, err: 10, WEST_TOPDIR/modules/lib/zcbor/src/zcbor_decode.c:51
    ZCBOR_FAIL rem: 2, cur: 0x1, ec: 0xffffffef, err: 10, WEST_TOPDIR/modules/lib/zcbor/src/zcbor_decode.c:648
    Decoding error, start_decode images->list  (err: 10)

    any help on this would be greatly appreciated

    regards,

    Omar

Related