DFU for external BLE Sensor

RE: DFU for external BLE Sensor

davidpatton — Wed, 17 Nov 2021 13:40:43 GMT

Hi,

One other IMPORTANT thing to note is that if the SHA is sent with the first Upload packet and the upload fails in the middle (let's say at byte number 253400), when it restarts if will start from where it left off, i.e., when the upload is retried and the first block is sent the Peripheral will respond with the offset where the transfer should resume, i.e., 253400 in this case. This is not true if the SHA is not sent with the first Upload packet. This took a lot of work to figure this out so I thought I would share it for others benefit. NOTE: Sending the SHA is optional.

Thanks,

Dave Patton

RE: DFU for external BLE Sensor

Vidar Berg — Wed, 17 Nov 2021 08:26:00 GMT

Hi Dave,

Thank you for the update. Actually, it seems like this hash digest is only used as an identifier for the upload session, and not for data integrity checks as I had expected. So the way the hash is computed may differ between different DFU clients. We need to document this better..

Here's the function that checks the hash in the first packet:

https://github.com/zephyrproject-rtos/mcumgr/blob/c854c85ec75d624c47058bc4ac0ab9b12e2dd0e7/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c#L587

Best regards,

Vidar

RE: DFU for external BLE Sensor

davidpatton — Tue, 16 Nov 2021 19:19:17 GMT

Hi Vidar,

I don't think the information the developer provided is correct. Through testing and trial and error I verified that the SHA is actually calculated over the entire image, i.e.,

Image Header (512 bytes)
Image Data (501,244 bytes)
Image Trailer (151 bytes)

Just thought I would share this info with you in case someone else needs it.

Many thanks for your help,

Dave Patton

RE: DFU for external BLE Sensor

Vidar Berg — Tue, 16 Nov 2021 16:17:58 GMT

Hi,

Please check if he has kept the "documentation folder. The is a release_notes.txt file in it which says what SDK version it is.

RE: DFU for external BLE Sensor

Vidar Berg — Tue, 16 Nov 2021 16:16:16 GMT

Hi Dave,

One of our developers pointed out to me that the sha256 sent along with the first packet (when offset == 0) is actually only of the data sent in that packet. In other words, this has digest not the same one that you will find in the image trailer:

The nRF5 SDK includes a sha library in \components\libraries\sha256 that you can use.

Vidar

RE: DFU for external BLE Sensor

davidpatton — Mon, 15 Nov 2021 16:19:19 GMT

Hi,

I took this project over from someone who no longer works at the company and I am not 100% sure which SDK it is based on, I just know it is an SDK prior to 16. Is there a way to identify which SDK it is based on? Yesterday I actually pulled the GATT QUEUE stuff from SDK 16, i.e., nrf_ble_gq.c and nrf_ble_gq.h as well as nrf_queue.c and nrf_queue.h and I was able to get our project working with the original SMP implementation that you provided so the weirdness that I described in the question from last week is thankfully gone.

Thanks,

Dave Patton

RE: DFU for external BLE Sensor

davidpatton — Mon, 15 Nov 2021 16:12:49 GMT

Hi Vidar,

I have been unable to locate the last 3 bytes of the SHA in the image trailer. I know what these 3 bytes are because I collected the entire OTA process between the nRFConnect android app and the Peripheral that is being updated. I have attached both the RAW image file that contains the image header and image trailer as well as a "c" based header file that shows the HEX representation of the data in the RAW image file. The SHA that is being sent for the files attached is: 0xD1, 0x01, 0x34

The CBOR object that is sent with this is as follows: char cSha[] = {0x63, 0x73, 0x68, 0x61, 0x43, 0xD1, 0x01, 0x34};

I don't think the SHA is in the image file but if I am wrong can you point out where the SHA is inside the image file. If the SHA is not in the image file I will need to be able to calculate the SHA myself in c code in the nRF5 SDK. In this case can you provide some example code that performs this calculation?

Thanks,

Dave Patton

devzone.nordicsemi.com/.../480_2D00_00099_2D00_R1.27.2.1632834244_5F00_FOTA.bin devzone.nordicsemi.com/.../Image1.27.2.h

RE: DFU for external BLE Sensor

Vidar Berg — Mon, 15 Nov 2021 16:06:05 GMT

Hi,

I'm afraid I can't think of any obvious explanations to the 2 problems you described. Is there chance you can share this project here or in a private support ticket so I can try to review the project configuration?

[quote user="davidpatton"] Is it possible to implement the SMP stuff in an earlier SDK?[/quote]

Yes, but it will be more work if you use an older old SDK version. Which SDK/Softdevice are you using?

RE: DFU for external BLE Sensor

davidpatton — Fri, 12 Nov 2021 22:22:07 GMT

Hi,

I am still struggling with the integration of the SMP stuff into our real app, I detailed some issues in the last message. The funny thing is that the SMP stuff is working in our real app now. The addition of the SMP stuff into our real app has broken so many things now and I believe it is because our real app is based on an earlier SDK. Is it possible to implement the SMP stuff in an earlier SDK?

RE: DFU for external BLE Sensor

davidpatton — Fri, 12 Nov 2021 00:17:38 GMT

Hi,

I am having 2 very weird problems, one seems like it may be compiler related. The other one I am clueless about. I will explain both below.

************************* PROBLEM #1 ********************************

See the code below:

BLE_NUS_C_DEF(m_ble_nus_c);

uint32_t ble_nus_c_init(ble_nus_c_t * p_ble_nus_c, ble_nus_c_init_t * p_ble_nus_c_init)
{
    uint32_t      err_code;
    ble_uuid_t    uart_uuid;
    ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_ble_nus_c);
    VERIFY_PARAM_NOT_NULL(p_ble_nus_c_init);

    err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_ble_nus_c->uuid_type);
    VERIFY_SUCCESS(err_code);

    uart_uuid.type = p_ble_nus_c->uuid_type;
    uart_uuid.uuid = BLE_UUID_NUS_SERVICE;

    p_ble_nus_c->conn_handle           = (uint16_t)0x1111;
    p_ble_nus_c->conn_handle           = BLE_CONN_HANDLE_INVALID;
    p_ble_nus_c->evt_handler           = p_ble_nus_c_init->evt_handler;
    p_ble_nus_c->handles.nus_tx_handle = (uint16_t)0x2222;
    p_ble_nus_c->handles.nus_tx_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_nus_c->handles.nus_status_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_nus_c->handles.nus_buffer_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_nus_c->handles.nus_rx_handle = BLE_GATT_HANDLE_INVALID;

	print_trace("ble_nus_c_init(1) p_ble_nus_c->conn_handle: %d", p_ble_nus_c->conn_handle);
    err_code = ble_db_discovery_evt_register(&uart_uuid);
	print_trace("ble_nus_c_init(2) p_ble_nus_c->conn_handle: %d", p_ble_nus_c->conn_handle);

	return err_code;
}

/**@brief Function for initializing the Nordic UART Service (NUS) client. */
static void nus_c_init(void)//FA191118
{
	ret_code_t  err_code;
	ble_nus_c_init_t init;

	init.evt_handler = ble_nus_c_evt_handler;

	err_code = ble_nus_c_init(&m_ble_nus_c, &init);
	APP_ERROR_CHECK(err_code);
}

void main(void)
{
    nus_c_init();
}

What is happening is that when I run this line of code: p_ble_nus_c->conn_handle = (uint16_t)0x1111; it does not set the conn_handle to 0x1111, it sets it to 0x0011 and also sets part of the nus_tx_handle when this instruction is executed. I have attached a screen shot of the debugger showing this.

This started happening after I pulled the SMP implementation from the dev board project to our real project. Our real project was based on a SDK that did not contain the GAT QUEUE stuff, i.e., nrf_ble_gq.c and nrf_ble_gq.h. I therefore copied these file from the 17.1SDK into our real project. I then had to replace the nrf_queue.c and nrf_queue.h in our real project with the files from the 17.1SDK to get the project to build. The SMP service stuff is now working in our real project.

************************* PROBLEM #2 ********************************

I can no longer initialize the watchdog. Here is the code:

static void watchdog_init(void)
{
	uint32_t err_code = NRF_SUCCESS;
	//Configure WDT.
	nrf_drv_wdt_config_t config = NRF_DRV_WDT_DEAFULT_CONFIG;
	err_code = nrf_drv_wdt_init(&config, wdt_event_handler);
	APP_ERROR_CHECK(err_code);
	err_code = nrf_drv_wdt_channel_alloc(&m_channel_id);
	APP_ERROR_CHECK(err_code);
	nrf_drv_wdt_enable();
}

int main(void)
{
    watchdog_init();
}

It is crashing inside watchdog_init() at this line: err_code = nrf_drv_wdt_init(&config, wdt_event_handler);

Look at this line: nrf_drv_wdt_config_t config = NRF_DRV_WDT_DEAFULT_CONFIG;

Below is a Debug Watch showing the values:

When I single step through the functions I get to the function below

nrfx_err_t nrfx_wdt_init(nrfx_wdt_config_t const * p_config,
                         nrfx_wdt_event_handler_t  wdt_event_handler)
{
    NRFX_ASSERT(p_config);
    nrfx_err_t err_code;

#if !NRFX_CHECK(NRFX_WDT_CONFIG_NO_IRQ)
    NRFX_ASSERT(wdt_event_handler != NULL);
    m_wdt_event_handler = wdt_event_handler;
#else
    NRFX_ASSERT(wdt_event_handler == NULL);
    (void)wdt_event_handler;
#endif
    if (m_state == NRFX_DRV_STATE_UNINITIALIZED)
    {
        m_state = NRFX_DRV_STATE_INITIALIZED;
    }
    else
    {
        err_code = NRFX_ERROR_INVALID_STATE;
        NRFX_LOG_WARNING("Function: %s, error code: %s.",
                         __func__,
                         NRFX_LOG_ERROR_STRING_GET(err_code));
        return err_code;
    }

    nrf_wdt_behaviour_set(p_config->behaviour);

    nrf_wdt_reload_value_set((p_config->reload_value * 32768) / 1000);

#if !NRFX_CHECK(NRFX_WDT_CONFIG_NO_IRQ)
    NRFX_IRQ_PRIORITY_SET(WDT_IRQn, p_config->interrupt_priority);
    NRFX_IRQ_ENABLE(WDT_IRQn);
#endif

    err_code = NRFX_SUCCESS;
    NRFX_LOG_INFO("Function: %s, error code: %s.", __func__, NRFX_LOG_ERROR_STRING_GET(err_code));
    return err_code;
}

I set a breakpoint at this line: NRFX_IRQ_PRIORITY_SET(WDT_IRQn, p_config->interrupt_priority);

And then look at the p_config variable which should be filled with NRF_DRV_WDT_DEAFULT_CONFIG but it is not. I have attached a debug screen showing this below.

If after entering the nrfx_wdt_init function I stop at a breakpoint and adjust the p_config data values to be those of NRF_DRV_WDT_DEAFULT_CONFIG Before NRFX_IRQ_PRIORITY_SET(WDT_IRQn, p_config->interrupt_priority); is called then I do not get a crash. This is similar to the first problem, the compiler seems like it is messing things up.

I am guessing that this may have been caused by adding in the SMP stuff to our real project since it did not happen prior to that. I have been beating my head against a wall all day trying to make sense of this. I am really hoping that you have some ideas.

Thanks,

Dave Patton

RE: DFU for external BLE Sensor

davidpatton — Thu, 11 Nov 2021 15:31:31 GMT

Nevermind, I solved it. My project has a queue dir that contained the QUEUE files nrf_queue.h and nrf_queue.c from the earlier SDK. I copied those files from the 17.1SDK and the code now builds.

Thanks,

Dave

RE: DFU for external BLE Sensor

davidpatton — Thu, 11 Nov 2021 14:49:45 GMT

Hi,

I forgot to mention that the file that gets the compile error contains these header includes>

#include "../../nRF_Includes/queue/nrf_queue.h"
#include "../../nRF_Includes/nrf_ble_gq/nrf_ble_gq.h"

I would have expected these headers to resolve the compile issues but they did not.

RE: DFU for external BLE Sensor

davidpatton — Thu, 11 Nov 2021 14:46:09 GMT

Hi,

I did the DFU via SMP project on the Dev kit to get it working. I now have to move that code to our real project that has many other things in it. Unfortunately our project was based on an SDK that did not contain the BLE GATT QUEUE. I copied the /ble/nrf_ble_gq directory from the 17.01 SDK to our project to add the BLE GAT QUEUE. Then I added the following to the skd_config.h file:

// <e> NRF_QUEUE_ENABLED - nrf_queue - Queue module
//==========================================================
#ifndef NRF_QUEUE_ENABLED
#define NRF_QUEUE_ENABLED 1
#endif

// <o> NRF_BLE_GQ_BLE_OBSERVER_PRIO
// <i> Priority with which BLE events are dispatched to the GATT Queue module.

#ifndef NRF_BLE_GQ_BLE_OBSERVER_PRIO
#define NRF_BLE_GQ_BLE_OBSERVER_PRIO 1
#endif

// <e> NRF_BLE_GQ_ENABLED - nrf_ble_gq - BLE GATT Queue Module
//==========================================================
#ifndef NRF_BLE_GQ_ENABLED
#define NRF_BLE_GQ_ENABLED 1
#endif
// <o> NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE - Default size of a single element in the pool of memory objects.
#ifndef NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE
#define NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE 20
#endif

// <o> NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT - Default number of elements in the pool of memory objects.
#ifndef NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT
#define NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT 8
#endif

// <o> NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN - Maximal size of the data inside GATTC write request (in bytes).
#ifndef NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN
#define NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN 2
#endif

// <o> NRF_BLE_GQ_GATTS_HVX_MAX_DATA_LEN - Maximal size of the data inside GATTC notification or indication request (in bytes).
#ifndef NRF_BLE_GQ_GATTS_HVX_MAX_DATA_LEN
#define NRF_BLE_GQ_GATTS_HVX_MAX_DATA_LEN 16
#endif

To me this looks like all that should be required but I am getting a compile error that I can't figure out. I tried searching online for others having this issue but I have been unable to find anything, can you help with this. The code that is generating the error is:

NRF_BLE_GQ_DEF(m_ble_gatt_queue, /**< BLE GATT Queue instance. */
NRF_SDH_BLE_CENTRAL_LINK_COUNT,
NRF_BLE_GQ_QUEUE_SIZE);

Building ‘SkyHub’ from solution ‘Solution ‘SkyHub’’ in configuration ‘Release’
Preprocessing file_transfer.c
Preprocessing packet_processing.c
Preprocessing pc_uart_interface.c
Preprocessing mobile_app_interface.c
Preprocessing sky_dfu.c
Preprocessing skybitz_app.c
Preprocessing int_flash.c
Preprocessing mx25flash_spi.c
Preprocessing spi_flash.c
Preprocessing skycam_ota.c
Preprocessing con_controller.c
Compiling ‘file_transfer.c’
Compiling ‘packet_processing.c’
Compiling ‘pc_uart_interface.c’
Preprocessing rtc_timer.c
Compiling ‘mobile_app_interface.c’
Compiling ‘sky_dfu.c’
Compiling ‘mx25flash_spi.c’
Compiling ‘int_flash.c’
Compiling ‘skybitz_app.c’
unknown type name 'm_ble_gatt_queuereq_queue'
expected declaration specifiers or '...' before numeric constant
expected declaration specifiers or '...' before 'NRF_QUEUE_MODE_NO_OVERFLOW'
expected declaration specifiers or '...' before numeric constant
'm_ble_gatt_queuereq_queue' undeclared here (not in a function); did you mean 'm_ble_gatt_queuepurge_queue'?
conversion from 'unsigned int' to 'unsigned char' changes value from '4022250974' to '222' [-Woverflow]
Compiling ‘spi_flash.c’
Compiling ‘skycam_ota.c’
Compiling ‘con_controller.c’
Compiling ‘rtc_timer.c’
Build failed

Thanks,

Dave Patton

RE: DFU for external BLE Sensor

Vidar Berg — Thu, 11 Nov 2021 11:55:54 GMT

Hi Dave,

Are you sure you need to create a new project for this? Normally it's sufficient to just change the board file (Using the SDK with other boards) in addition to maybe updating some of the global pre-processor defines. Anyway. The code in nrf_queue.c should become enabled as long as NRF_QUEUE_ENABLED==1. Maybe it's being defined as '0' elsewhere in your project?

Vidar

RE: DFU for external BLE Sensor

davidpatton — Wed, 10 Nov 2021 23:19:09 GMT

Hi, I am trying to move this code into my non-dev board project and for this file nrf_queue.c this is at the top of the file.

#if NRF_MODULE_ENABLED(NRF_QUEUE)

This currently is false so none of the code in this file is active. I added this to my sdk_config.h

// <e> NRF_QUEUE_ENABLED - nrf_queue - Queue module
//==========================================================
#ifndef NRF_QUEUE_ENABLED
#define NRF_QUEUE_ENABLED 1
#endif
// <q> NRF_QUEUE_CLI_CMDS - Enable CLI commands specific to the module

however, that did not enable the code in nrf_queue.c. How can I enable this code?

Thanks

Dave

RE: DFU for external BLE Sensor

Vidar Berg — Mon, 08 Nov 2021 14:40:38 GMT

Hi Dave,

It's the sha-256 digest of your signed image, but only the first 3 bytes of it: https://github.com/zephyrproject-rtos/mcumgr/blob/master/cmd/img_mgmt/src/img_mgmt.c#L493-L501

The easiest way to get the digest (is placed in the image trailer) is to use the imgtool and run imgtool verify <signed_image>

Best regards,

Vidar

RE: DFU for external BLE Sensor

davidpatton — Sun, 07 Nov 2021 18:31:11 GMT

Hi,

There is one piece of information that I have been unable to figure out. The first block of data in the upload contains the entire image length and a "sha" field. Below is a real example of the data in both binary and the "json" representation of the cbor data. I need to know exactly what the "sha" is and how to calculate it so I can include the "sha" with my uploads.

Binary data = SMPHeader|CBOR_Data packet: 020000f400010001bf646461746158d53db8f3960000000000020000fca5070000000000011b0100860e536100000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff636c656e1a0007a8936373686143525249636f666600ff

SMPHeader: 020000f400010001

CBOR_Data: bf646461746158d53db8f3960000000000020000fca5070000000000011b0100860e536100000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff636c656e1a0007a8936373686143525249636f666600ff

cbor json: {"data": h'3DB8F3960000000000020000FCA5070000000000011B0100860E536100000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF', "len": 501907, "sha": h'525249', "off": 0}

Thanks,

Dave Patton

RE: DFU for external BLE Sensor

Vidar Berg — Thu, 04 Nov 2021 07:51:08 GMT

Excellent! I did not even think of using debug logs from the phone. My plan was to try to log the data from the DFU target. I didn't get that far though. Not sure if I would have been able to log the data fast enough either.

I will report the missing documentation as a feature request. Hopefully we can add it so others who are developing their own DFU clients in the future do not have to reverse engineer the protocol like you had to.

Thanks for the update.

Vidar

RE: DFU for external BLE Sensor

davidpatton — Wed, 03 Nov 2021 20:23:55 GMT

Hi,

I figured it out and just had my first successful Image Upload! I actually discovered "adb" which is android debug and set that up which allowed me to capture EVERYTHING that nRfConnect was sending while it was doing a firmware update of the sensor. Then I used looked at the capture file with the Wireshark application which allowed me to see the raw bytes that were being sent. Once I had that I was able to figure it out. Really there is literally no decent documentation ANYWHERE that describes the DFU vis SMP process on a byte level which is what is needed if you are developing a solution from scratch.

Anyway, I wanted to thank you again for the help that you gave me, without that I would still be struggling.

Many Thanks,

Dave Patton

RE: DFU for external BLE Sensor

davidpatton — Tue, 02 Nov 2021 13:28:23 GMT

Hi,

The image you sent contains the log output from the DFU, this is one level above where the actual bytes are sent. Although that contains most of the data for an Upload block it is missing some stuff, I am looking for a log at the byte level. Something that shows the actual bytes being sent over the BLE, if I get this I will know how to extract the data I need:

BLE Header (I don't really need this)
SMP Header (this is 8 bytes)
CBOR Data (this is variable length)

If possible a file containing the raw bytes would be AWESOME. Thanks so much for your help, once I get this piece of information I am sure I will be able to complete this project.

Thanks,

Dave

RE: DFU for external BLE Sensor

Vidar Berg — Tue, 02 Nov 2021 12:28:28 GMT

Hi,

I am not familiar with the low level details of the mcumgr protocol or the cbor encoding, to be honest. But you can do DFU using the same image with nRF connect on Android or iOS, then inspect the log to see the cbor requests and responses that are being sent.

Here is the log I got from nRF connect on iOS for reference:

Let me know if this is not the data you are looking for.

Vidar

RE: DFU for external BLE Sensor

davidpatton — Mon, 01 Nov 2021 17:09:20 GMT

Hi,

Thanks to your help I have made significant progress towards uploading a new image via SMP but I need one more piece of information that I am hoping you could help me with. What I need is an example of one Upload block for the DFU over SMP. Note that I don't need the BLE overhead, just the DFU SMP data portion of the Upload Block. What I am looking for is just the raw bytes that are sent for the Upload block. Here is my attempt at creating and sending two Upload Blocks and the responses that I am getting back.

// Data sent for block 0 of the upload

A4 62 70 31 01 64 64 61 74 61 58 C0 3D B8 F3 96 00 00 00 00 00 02 00 00 FC A5 07 00 00 00 00 00 01 1B 02 00 C4 12 53 61 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 63 6C 65 6E 18 C0 63 6F 66 66 00 00

I checked the CBOR through cbor.me it is valid CBOR data and I get the following...

{"p1": 1, "data": h'3DB8F3960000000000020000FCA5070000000000011B0200C412536100000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF', "len": 192, "off": 0}

When I send this I get the following response

BF 62 72 63 00 63 6F 66 66 18 C0 FF

cbor.me tells me this is the CBOR: {"rc": 0, "off": 192}

This seems like a valid response but when I try sending the 2nd block I get something back that is not valid.

// Data sent for block 1 of the upload

A4 62 70 31 01 64 64 61 74 61 58 C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 63 6C 65 6E 18 C0 63 6F 66 66 18 C0

I checked the CBOR through cbor.me it is valid CBOR data and I get the following...
cbor.me: {"p1": 1, "data": h'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF', "len": 192, "off": 192}

// Block #1 response - this is INVALID according to cbor.me
BF 62 72 63 01 FF 6F 66 66 18 C0 FF

Thanks,

Dave

RE: DFU for external BLE Sensor

Vidar Berg — Thu, 28 Oct 2021 08:35:44 GMT

Hi,

It looks like it should be straight forward to integrate tinycbor library we use in our nRF Connect SDK. The SDK is including the following files from the library: https://github.com/zephyrproject-rtos/tinycbor/blob/zephyr/zephyr/CMakeLists.txt which do not seem to have any external dependencies.

RE: DFU for external BLE Sensor

davidpatton — Thu, 28 Oct 2021 04:04:25 GMT

Hi,

Does nordic have a CBOR library that is suitable for use with my nRF SKD5 implementation?

Thanks..

RE: DFU for external BLE Sensor

davidpatton — Wed, 27 Oct 2021 20:57:59 GMT

Thanks!!! You are AWESOME!! Now I can send and receive data and can actually start on the real implementation! I may have more questions but now I have a great starting point...