nRF5 SDK 14.2.0 - Secure Bootloader DFU always fail after adding new variable to a characteristic

RE: nRF5 SDK 14.2.0 - Secure Bootloader DFU always fail after adding new variable to a characteristic

Hieu — Thu, 16 Feb 2023 21:26:36 GMT

Hi fabocode,

The code you share is your company's custom implementation to add BLE characteristic. ble_char_config_t is not a nRF5 SDK v14.2.0 type. My guess is there would be a helper function/library that read that array and add the characteristic.

My next guess is that the size of ble_char_config_t changed and somehow mess up the DFU service. Did you check if ble_ge_cookware_data_t increases after your change?

One possible cause of DFU issues after a change to the service table is exactly what is written in the "VERY IMPORTANT NOTE" comment in your code. However, your change should not cause this...
To rule out this possibility, please repeat the test with a phone having forgotten the device, and a device that has been fully erased, then programmed with the new application

I have another idea, but for now please help me with my above question and suggestion first.

[quote user="fabocode"]as an update, I see now that if I forget the device from the iphone I have running nrf connect, and restarting the bluetooth in the phone, the error I keep seeing in the logs from nrf connect is what I attached to this post "Error 14: Peer removed pairing information"[/quote]

If you forget the device on the phone, you also need to clear the bond information on the device. The central (phone) will not be able to pair to the peripheral if the peripheral still remembers the old bond.

On a tangential note, a way to address the problem in "VERY IMPORTANT NOTE" is to use the Service Changed characteristic. Does your application configure NRF_SDH_BLE_SERVICE_CHANGED=1?

RE: nRF5 SDK 14.2.0 - Secure Bootloader DFU always fail after adding new variable to a characteristic

fabocode — Wed, 15 Feb 2023 22:11:06 GMT

Hi Hieu

I would like to add more details about the problem I have.

I have a struct which is part of one of the characteristics is currently running in the microcontroller.

typedef struct __attribute__ ((__packed__)) {
    software_revision_t  version;   // Device firmware version
    uint16_t  product_id;           // Device Product ID
    uint8_t   battery_v;            // Battery voltage in 0.01 V increments
    uint16_t  temp_degF;            // Sensor reading in 0.1 F increments
    int8_t    cjt_degC;             // Cold-Junction Temperature (thermocouple ADC temp offset)
    uint8_t   status;               // Indicates error state with thermocouple or connection
    accel_event_data_t motion;      // Indicates motion & gesture detection
    uint8_t   wakeup_status;        // Indicates if device has woke up from deep sleep <------ This is the variable I added to the struct
} ge_cookware_data_t;


typedef struct __attribute__ ((__packed__)) {
    uint32_t    timestamp;      // time in nrf ticks (generally called milliseconds, but actually 1/1024 second)
    uint8_t     counter;        // increments by 1 every time data contents change (rolls over when reaches 0xff)
    uint8_t     packet_id;      // Advertising packet version (adv_packet_id_t)
    ge_cookware_data_t ge_cookware;
} ge_adv_packet_t;

typedef ge_adv_packet_t   ble_ge_cookware_data_t;

And here's the struct created for the service/characteristic definition

/**** Service ****/
static const ble_char_config_t k_ble_cw_char_config[] = {
    /*                  characteristic UUID, READ,    WRITE,      NOTIFY,        INDICATE, REQUEST_ID, SEND_AS_EVENT,                               SIZE,                   MAX_SIZE, WRITE_TYPE,              HANDLE_STATE VARIABLE */
  /* 1st */  {        COOKWARE_UUID_CHAR_HANDLE_DATA, READ, NO_WRITE, AUTO_NOTIFY,     NO_INDICATE,         NO,            NO,     sizeof(ble_cw_cookware_data_t),                          0,      SHORT,    COOKWARE_VARIABLE_COOKWARE_DATA },
  /* 2nd */  {        COOKWARE_UUID_CHAR_HANDLE_HWID, READ, NO_WRITE,   NO_NOTIFY,     NO_INDICATE,         NO,            NO,     sizeof(ble_cw_cookware_hwid_t),                          0,      SHORT,          COOKWARE_VARIABLE_INVALID },
  /* 3rd */  {             COOKWARE_UUID_CHAR_EVENTS, READ, NO_WRITE,   NO_NOTIFY, DEMAND_INDICATE,        YES,            NO,             sizeof(ble_cw_event_t), BLE_GATT_MAX_PACKET_LENGTH,      SHORT,          COOKWARE_VARIABLE_INVALID },
  /* 4th */  {     COOKWARE_UUID_CHAR_GE_HANDLE_DATA, READ, NO_WRITE, AUTO_NOTIFY,     NO_INDICATE,         NO,            NO,     sizeof(ble_ge_cookware_data_t) /* here's the struct used by the characteristic */,                          0,      SHORT, COOKWARE_VARIABLE_GE_COOKWARE_DATA }, 
  /* 5th */  {           COOKWARE_UUID_CHAR_COMMANDS, READ,    WRITE,   NO_NOTIFY,     NO_INDICATE,        YES,            NO, sizeof(ble_cookware_instruction_t), BLE_GATT_MAX_PACKET_LENGTH,      SHORT,          COOKWARE_VARIABLE_INVALID },
};

That's what I mean when I say "I added a variable". And I am currently testing to replicate as much scenarios as possible to recover the FW from DFU to a downgraded version. I can see that the problem resides in the firmware running in the device itself, not the build being downloaded, but I am not understanding what's the real issue that's making fail all the attempts to do DFU, even to versions which share the same property (the new variable in the struct).

as an update, I see now that if I forget the device from the iphone I have running nrf connect, and restarting the bluetooth in the phone, the error I keep seeing in the logs from nrf connect is what I attached to this post "Error 14: Peer removed pairing information".

RE: nRF5 SDK 14.2.0 - Secure Bootloader DFU always fail after adding new variable to a characteristic

Hieu — Mon, 13 Feb 2023 13:49:52 GMT

Hi fabocode,

Could you please clarify in detailed what you did by "adding a variable?"

Are you changing the maximum size of a Characteristic Value? Or are you adding a new Characteristic?

I also feel there are some conflicts in the information you are providing.

[quote userid="84523" url="~/f/nordic-q-a/96574/nrf5-sdk-14-2-0---secure-bootloader-dfu-always-fail-after-adding-new-variable-to-a-characteristic"]- Remove the variable previously added to recover the state of where the device was, even removing the variable from the code, I still I am unable to do DFU's
- Trying to flash the microcontroller directly, deleting all memory in the microcontroller before flashing it again with new code (which does not have the variable I was looking to add at first) and try DFU again, DFU is still failing. [/quote]

Do you mean you remove it from the image you are downloading?
In this case, is the image on the device still having your modification?

The issue is most likely due to the firmware running the download, so the thing on the device, not the image being downloaded at all. Changing the image being download doesn't help.

[quote userid="84523" url="~/f/nordic-q-a/96574/nrf5-sdk-14-2-0---secure-bootloader-dfu-always-fail-after-adding-new-variable-to-a-characteristic"]- By flashing manually to a version without the variable I wanted to add in the 1st place, I was able to get the DFU working. So far this is the only way to make it go back to an stable version that is able to work with DFU. [/quote]

And thus this observation makes sense.

Hieu