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]

DavidKaplan said:

I am using ncsv2.0.2 and not ncsv2.2.0

I think it also works for me in 2.0.2, so for the record: I do not think you have to upgrade the version for this feature.¨

I will help you make it work for v2.2.0 as well, though.

DavidKaplan said:

My error 11 is in the smp_list_rsp_proc() function when called by Test.

Error 11 looks like ZCBOR_ERR_WRONG_VALUE.
This is what the patch fixes, I think. Are you sure that the patch is still there after your update?

DavidKaplan said:

The problem is also that I could not reproduce the upload success.

To check if I understand correctly:
So it works the first time, but the upload fails if you already have an image in the secondary slot?

Do you get the debugging error when uploading the first time?

DavidKaplan said:

Since I transfer the image serially from my cellular host to the central, I know the actual image size if that is what I am supposed to use.

That would make sense to me.

Regards,
Sigurd Hellesvik

[DavidKaplan]

I tried some things today with my v2.2.0 sensor and central code with the default bootloader keys.

1) In smp_upload_rsp_proc(), I changed the 'rc' comparison line from

 if(!strncmp(value.value, "rc", 2)){
			printk("Invalid data received (rc key). String '%.2s' is not equal to 'rc'\n", value.value);
			return;
		}

to

        if(memcmp(value.value,"rc", 2)){
			printk("Invalid data received (rc key). String '%.2s' is not equal to 'rc'\n", value.value);
			return;
		}

Evidently the way it was written was not correct as it says !strncmp(), so if it matched 'rc' it would return.

I was previously 'rc' which gave an error, so I just used memcmp.

2) In smp_list_rsp_proc(), I had to increase these array sizes as the retuned values exceed what was allocated.

char version_key[16]; // ?!? len =7
 char version_value[16]; // ?!? len=5 was [5]

3) I verified the zcbor_decode.c changes in C:\ncs\v2.2.0\modules\lib\zcbor\src.

 Do I need to update also the file in C:\ncs\v2.2.0\bootloader\mcuboot\boot\boot_serial\src?

4) I uploaded a app_update.bin sensor file to my host's external flash and streamed it to the Central and on to the sensor. I was connected to the central by the debugger and its print outs showed the following which seemed OK but the image did not update. (DFUConnectFinishedErr:0 means OK).

I upload,list and then test.

07/02/2023 04:05:19[ami_local_pc.c: 152] Rx Op:B Len:21
[ami_local_pc.c:1050] ImageDownloadFinished
07/02/2023 04:05:19[ami_com.c:  89] MsgReply:a Len:10
[ami_smp.c:1265] DFU:318800/319012
[ami_smp.c:1455] SMP UploadOK
[ami_smp.c:1736] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x5112e3513cac5b8cdf9935bda9d8342c7d226e1abdf9c38afbae28e37b1ec
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x158917e21a8a8eb83acf3c74988b1c72d207e7063865f589f4e88581146eeac
      bootable: true
      pending: false
      confirmed: false
      active: false
      permanent: false
07/02/2023 04:05:20[ami_local_pc.c: 152] Rx Op:B Len:9
07/02/2023 04:05:20[ami_com.c:  89] MsgReply:a Len:10
[ami_smp.c:1739] ImageTest

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x5112e3513cac5b8cdf9935bda9d8342c7d226e1abdf9c38afbae28e37b1ec
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x158917e21a8a8eb83acf3c74988b1c72d207e7063865f589f4e88581146eeac
      bootable: true
      pending: true
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1742] ImageReset
07/02/2023 04:05:22[ami_ble.c: 861] Disconnected: D4:FD:9F:BF:4A:27 (random) (reason 8)
[ami_ble.c:2588] DFUConnectFinishedErr:0

Is there a way for more debug info maybe on the sensor ?

I moved the debugger to the central but maybe the debug output cleared when resetting.

Thanks David

[Sigurd Hellesvik]

DavidKaplan said:

I was previously 'rc' which gave an error, so I just used memcmp.

Nice!

DavidKaplan said:

2) In smp_list_rsp_proc(), I had to increase these array sizes as the retuned values exceed what was allocated.

Good to know

DavidKaplan said:

3) I verified the zcbor_decode.c changes in C:\ncs\v2.2.0\modules\lib\zcbor\src.

 Do I need to update also the file in C:\ncs\v2.2.0\bootloader\mcuboot\boot\boot_serial\src?

Only zcbor_decode.c in modules\lib\zcbor\src needs to be changed, as far as I know.

DavidKaplan said:

Is there a way for more debug info maybe on the sensor ?

My MCUboot SMP Sample feat Bluetooth Low Energy sample has logs from MCUboot:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.2.99-ncs1 ***
Change this to see it change.

Is this what you are looking for?

Regards,
Sigurd Hellesvik

[DavidKaplan]

Our peripheral sensor has no uart interfaces, unlike the SDKs, and is in a waterproof container.

I can maybe try to comment out the Central's SMP sensor reset command and see start up from the debugger.

From the SMP test reply it looks like slot#1 is pending.

I use the swap move define.

 

### ?!? 18-Dec-2022 Without this swap is used which limits upgrades 10000 / (150 / 4) ~ 267
CONFIG_BOOT_SWAP_USING_MOVE=y

Can you think of any reason the new image is not swapped.

I can also try to send SMP confirm instead of SMP test.

Thanks David

[Sigurd Hellesvik]

DavidKaplan said:

Our peripheral sensor has no uart interfaces, unlike the SDKs, and is in a waterproof container.

Do you have debugger access to the waterproof sensor?

Your "image list" lists the image as "pending: true".
This should make MCUboot swap the images.
Does it still list "pending:true" after multiple resets of the peripheral sensor?
Are you able to upload a new image from your mobile phone to update the peripheral sensor now?

Regards,
Sigurd Hellesvik

[DavidKaplan]

Yes, I have a bare board which I debug. 

Yes, the phone app updates correctly the image.

The RTT log does not show bootloader information on reset.

This is the sensor RTT log from the DFU connection till reset:

00> 08/02/2023 19:18:35[ami_main.c: 598] NewMin
00> 08/02/2023 19:19:35[ami_main.c: 598] NewMin
00> 08/02/2023 19:20:04[ami_main.c: 142] Connected
00> 08/02/2023 19:20:05[ami_main.c: 197] LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
00> 08/02/2023 19:20:09[ami_main.c: 174] Connection parameters updated.
00>  interval: 40, latency: 0, timeout: 42
00> 08/02/2023 19:20:14[ami_main.c: 174] Connection parameters updated.
00>  interval: 9, latency: 0, timeout: 42
00> 08/02/2023 19:20:35[ami_main.c: 598] NewMin
00> 08/02/2023 19:21:35[ami_main.c: 598] NewMin
00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> [00:00:00.037,292] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00> 00/00/0000 00:00:00[ami_main.c: 628] Startup
00> 00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:51

How can I read the bootloader flags in my code? Would this help?

I copied the default mcuboot.conf file into the child_image folder and added the swap move directive.

I tried in that file to change log minimal to n and log level to 4 but that did not help.

I see threads on bootloader RTT in the forum but mainly for non zephyr builds.

I decided not to use other than the default bootloader keys till the DFU works.

CONFIG_PM=n

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_RSA=n
CONFIG_BOOT_ENCRYPT_EC256=n
CONFIG_BOOT_ENCRYPT_X25519=n

CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n

CONFIG_FLASH=y
CONFIG_FPROTECT=y

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0

### ?!? 18-Dec-2022 Without this swap is used which limits upgrades 10000 / (150 / 4) ~ 267
CONFIG_BOOT_SWAP_USING_MOVE=y

[Sigurd Hellesvik]

I were able to get some unstable RTT logging from MCUboot using the configurations from  Add RTT Logs to mcuboot

(You can just set LOG_MODE in child_image/mcuboot.conf I think)

Regards,
Sigurd Hellesvik

[DavidKaplan]

I calculate now a checksum (on the fly) of all of the data sent in send_upload2() and verified that my streamed image is NOT getting corrupted as its checksum is the same as on my PC hard drive before being uploaded to our host by cellular modem and being streamed to the Nordic nRF52840 Central and on to our sensor.

I tried just SMP uploading and issue the SMP test without the SMP reset. I powered on and off the sensor but that image was not swapped.

I tried to SMP upload and issued the SMP confirm command instead of the test and got an error 10 as shown below when debugging the central. Maybe this will help?

[ami_smp.c: 690] DFU:318000/319026
[ami_smp.c: 690] DFU:318400/319026
[ami_smp.c: 690] DFU:318800/319026
[ami_smp.c: 880] SMP UploadOK
[ami_smp.c:1161] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x28e54c8886d01dddf92457333eede4405517aba9e7aeca3bbdd43f8475975993
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: false
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1170] ImageConfirm
Decoding error, start_decode images->list  (err: 10)

This is my upload function. It finishes correctly. I could not see any problem in the function that is much different than the example code.

#define UPLOAD_CHUNK		400 // (50 worked) This has to be at least 32 bytes, since first it has to send the whole header (which is 32 bytes)
void send_upload2(void)
{
  uint8_t       data[UPLOAD_CHUNK+1]; // One more byte, to store '/0'
  zcbor_state_t zse[2];
  size_t        payload_len;
  int           start_addr   = PM_MCUBOOT_SECONDARY_ADDRESS;
  int           last_addr    = PM_MCUBOOT_SECONDARY_ADDRESS+ami_state->dfu.ImageSize.ulong;
  int           curr_addr    = start_addr;
  int           upload_chunk = UPLOAD_CHUNK;
  int           err;
  bool          update_complete = false;
  uint8_t       wait_timeouts = 0;

  ami_state->DFUErr                 = AMI_SMP_DFU_ERR_OK;
  ami_state->dfu.uAddChecksum.word  = 0;
  ami_state->dfu.uXORChecksum       = 0;
  while (!update_complete){
      struct smp_buffer smp_cmd;
      zcbor_new_encode_state(zse, ARRAY_SIZE(zse), smp_cmd.payload,sizeof(smp_cmd.payload), 0);
      k_sem_take(&upload_sem, K_FOREVER);
      err = 0;
      last_addr    = (PM_MCUBOOT_SECONDARY_ADDRESS+ami_state->dfu.ImageSize.ulong);
      if (ami_state->DFUErr){
        update_complete = true;
        break;
      }
      //-------------------------------------------------------
      // Disconnected?
      //-------------------------------------------------------
      if (!atomic_get(&ble_connected)){
        ami_state->DFUErr = AMI_DFU_ERR_DISCONNECTED;
        update_complete = true;
        break;
      }
      if ((curr_addr+UPLOAD_CHUNK) > last_addr){
	upload_chunk = last_addr - curr_addr;
	update_complete = true;
      }
      //-----------------------------------------------------------------
      // Get the data block from ringbuffer
      //-----------------------------------------------------------------
      ami_state->DFUErr = ami_smp_RetDataBlock(data,upload_chunk);
      if (ami_state->DFUErr){ 
        update_complete = true;
        break;
      }
      progress_print(curr_addr-start_addr, last_addr-start_addr);
      data[upload_chunk] = '\0';
      zse->constant_state->stop_on_error = true;
      zcbor_map_start_encode(zse, 20);
      zcbor_tstr_put_lit(zse, "image");
      zcbor_int64_put(zse, 0);
      zcbor_tstr_put_lit(zse, "data");
      zcbor_bstr_put_lit(zse, data);
      zcbor_tstr_put_lit(zse, "len");
//          zcbor_uint64_put(zse, (uint64_t)ami_state->dfu.ImageSize.ulong);
      zcbor_uint64_put(zse, (uint64_t)0x5B68);
      zcbor_tstr_put_lit(zse, "off");
      zcbor_uint64_put(zse, curr_addr - start_addr);
      zcbor_tstr_put_lit(zse, "sha");
      zcbor_bstr_put_lit(zse, "12345");
      zcbor_tstr_put_lit(zse, "upgrade");
      zcbor_bool_put(zse, false);
      zcbor_map_end_encode(zse, 20);
      //-----------------------------------------------------------------
      // ZCBOR error?
      //-----------------------------------------------------------------
      if (!zcbor_check_error(zse)) {
        d_printf(LINE_INFO,kDbg_Error|kDbg_Host,"Failed to encode SMP test packet, err: %d", zcbor_pop_error(zse));
        ami_state->DFUErr = AMI_SMP_DFU_ERR_UPLOAD_ENCODE;
        break;
      }
      curr_addr+=upload_chunk;
      payload_len = (size_t)(zse->payload - smp_cmd.payload);
      smp_cmd.header.op = 2; /* write request */
      smp_cmd.header.flags = 0;
      smp_cmd.header.len_h8 = (uint8_t)((payload_len >> 8) & 0xFF);
      smp_cmd.header.len_l8 = (uint8_t)((payload_len >> 0) & 0xFF);
      smp_cmd.header.group_h8 = 0;
      smp_cmd.header.group_l8 = 1; /* IMAGE */
      smp_cmd.header.seq = 0;
      smp_cmd.header.id  = 1; /* UPLOAD */
      //-----------------------------------------------------------------
      // ZCBOR error?
      //-----------------------------------------------------------------
      err = bt_dfu_smp_command(&dfu_smp,smp_upload_rsp_proc,sizeof(smp_cmd.header)+payload_len,&smp_cmd); 
      if (err){
          d_printf(LINE_INFO,kDbg_Error|kDbg_Host,"bt_dfu_smp_command failed with %d", err);
          ami_state->DFUErr = AMI_SMP_DFU_ERR_SEND;
          break;
      }
  } // while
  if (!ami_state->DFUErr){
    ami_smp_PrintChecksums();
    d_printf(LINE_INFO,kDbg_General|kDbg_Host,"SMP UploadOK");
  }
  atomic_set(&smp_finished,true);
} // send_upload2

I tried several additions to my child_image mcuboot.conf file, but nothing I did showed any RTT bootloader information. It does say 4 messages dropped.

*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.036,834] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00/00/0000 00:00:00[ami_main.c: 628] Startup
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:51
build time: Feb  9 2023 15:07:18
--- 4 messages dropped ---
[00:00:00.485,168] <inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: 
                                         6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
                                         1f 85 d8 e1                                      |....             
[00:00:00.487,609] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.487,640] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.487,670] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098
[00:00:00.488,098] <inf> bt_[0m
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.036,804] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00/00/0000 00:00:00[ami_main.c: 628] Startup
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:51
build time: Feb  9 2023 15:07:18
--- 4 messages dropped ---
[00:00:00.473,876] <inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: 
                                         6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
                                         1f 85 d8 e1                                      |....             
[00:00:00.476,318] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.476,348] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.476,379] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098
[00:00:00.476,806] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
00/00/0000 00:00:00[ami_ble.c: 506] ActualTxPwr:8
00/00/0000 00:00:00[ami_ble.c: 788] Bluetooth initialized
[00:00:00.477,508] <wrn> bt_hci_core: bt_set_name: Unable to store name
[00:00:00.478,057] <inf> bt_hci_core: bt_dev_show_info: Identity: D4:FD:9F:BF:4A:27 (random)
[00:00:00.478,088] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059
[00:00:00.478,118] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa
[00:00:00.478,363] <wrn> bt_hci_core: bt_set_name: Unable to store name
00/00/0000 00:00:00[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:21 F:0x20
00/00/0000 00:00:00[ami_ble.c: 593] AdvertisingStarted
00/00/0000 00:00:00[ami_main.c: 680] ResetCause:1
[00:00:00.493,591] <err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)
01/01/2004 00:00:01[ami_adc.c: 470] RdLSM6DSLThread
01/01/2004 00:00:01[ami_lsm6dsl.c: 120] RdLSM6DSLThread
01/01/2004 00:00:01[ami_lsm6dsl.c: 153] NewSample
01/01/2004 00:00:04[ami_lsm6dsl.c: 406] RMS x:0 y:2 z:0 ov:0 Temp:1869 Bat:625
01/01/2004 00:00:05[ami_ble.c: 555] UpdateAdv x:0 y:2 z:0 Tmp:19 F:0x20

Any other suggestions?

Have a good week end

Thanks David

[Sigurd Hellesvik]

Since the list command works, I also assume that the upload worked.
Then we can assume that the "confirm" command fails.

DavidKaplan said:

I tried to SMP upload and issued the SMP confirm command instead of the test and got an error 10 as shown below when debugging the central. Maybe this will help?

The error is from the response handler.
From the code, it seems like the "list" handler is used for responses from the "confirm" command.
This makes sense, though, as The response takes the same format as Get state of images response.

You see if your "confirm" command worked if the image is tagged as "pending = true".
If you send a "list" command after doing the "confirm", is the image tagged as "pending" in that case?

Regards,
Sigurd Hellesvik

[DavidKaplan]

Yes, the upload & list commands now return without any reported problem. 

If I understand you wanted to try the upload, list, confirm(fails) & again list sequence?

11/02/2023 19:05:19[ami_com.c:  89] MsgReply:a Len:10
[ami_smp.c: 692] DFU:316800/319026
[ami_smp.c: 692] DFU:317200/319026
[ami_smp.c: 692] DFU:317600/319026
[ami_smp.c: 692] DFU:318000/319026
[ami_smp.c: 692] DFU:318400/319026
[ami_smp.c: 692] DFU:318800/319026
[ami_smp.c: 793] ImageChecksum AF3A0C7A
[ami_smp.c: 919] SMP UploadOK
[ami_smp.c:1200] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x3e5866fbd4c56ae99a04f724b513c9e358f13a576d9e9a63b2e41b46f36d43
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: false
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1203] ImageTest

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x3e5866fbd4c56ae99a04f724b513c9e358f13a576d9e9a63b2e41b46f36d43
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: true
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1209] ImageConfirm
Decoding error, start_decode images->list  (err: 10)
[ami_smp.c:1200] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x3e5866fbd4c56ae99a04f724b513c9e358f13a576d9e9a63b2e41b46f36d43
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: true
      confirmed: false
      active: false
      permanent: false
11/02/2023 19:05:22[ami_ble.c: 861] Disconnected: D4:FD:9F:BF:4A:27 (random) (reason 22)
[ami_ble.c:2639] DFUConnectFinishedErr:105
11/02/2023 19:05:22[ami_ble.c:1545] ret:0 atomic_ev:32768 index:15
11/02/2023 19:05:22[ami_ble.c:1545] ret:0 atomic_ev:1 index:0

When I do a upload, list, test, reset sequence no problems are reported but the image is not updated after reset, but from my phone DFU works.

[ami_smp.c: 690] DFU:318000/319026
[ami_smp.c: 690] DFU:318400/319026
[ami_smp.c: 690] DFU:318800/319026
[ami_smp.c: 791] ImageChecksum AF3A0C7A
[ami_smp.c: 917] SMP UploadOK
[ami_smp.c:1198] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x8711f5297221c184e2f0a9a65d2ad3985be5bba9877fc829834c276a0986263
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: false
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1201] ImageTest

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x8711f5297221c184e2f0a9a65d2ad3985be5bba9877fc829834c276a0986263
      bootable: true
      pending: false
      confirmed: true
      active: true
      permanent: false

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
      bootable: true
      pending: true
      confirmed: false
      active: false
      permanent: false
[ami_smp.c:1204] ImageReset
11/02/2023 21:03:24[ami_ble.c: 861] Disconnected: D4:FD:9F:BF:4A:27 (random) (reason 8)
[ami_ble.c:2639] DFUConnectFinishedErr:0
11/02/2023 21:03:24[ami_ble.c:1545] ret:0 atomic_ev:32768 index:15
11/02/2023 21:03:24[ami_ble.c:1545] ret:0 atomic_ev:1 index:0

Like I wrote I calculated a checksum on the data buffers sent with the bt_dfu_smp_command() function and verified it was correct.

I also used the "nrfjprog --family nRF52 --readcode code.hex" command so I could try to compare part of the code with the app_update.bin or merged.hex.

I see in my sensor bootloader map that it does not have the littlefs mapped.

Should this matter since if the phone app works ours should too?

Central's map:
#define PM_APP_DEV_NAME "NRF_FLASH_DRV_NAME"
#define PM_MCUBOOT_PRIMARY_APP_OFFSET 0xc200
#define PM_MCUBOOT_PRIMARY_APP_ADDRESS 0xc200
#define PM_MCUBOOT_PRIMARY_APP_END_ADDRESS 0x80000
#define PM_MCUBOOT_PRIMARY_APP_SIZE 0x73e00
#define PM_MCUBOOT_PRIMARY_APP_NAME mcuboot_primary_app
#define PM_MCUBOOT_PRIMARY_APP_ID 4
#define PM_mcuboot_primary_app_ID PM_MCUBOOT_PRIMARY_APP_ID
#define PM_mcuboot_primary_app_IS_ENABLED 1
#define PM_4_LABEL MCUBOOT_PRIMARY_APP
#define PM_MCUBOOT_PRIMARY_APP_DEV_NAME "NRF_FLASH_DRV_NAME"
#define PM_MCUBOOT_SECONDARY_OFFSET 0x80000
#define PM_MCUBOOT_SECONDARY_ADDRESS 0x80000
#define PM_MCUBOOT_SECONDARY_END_ADDRESS 0xf4000
#define PM_MCUBOOT_SECONDARY_SIZE 0x74000
#define PM_MCUBOOT_SECONDARY_NAME mcuboot_secondary
#define PM_MCUBOOT_SECONDARY_ID 5
#define PM_mcuboot_secondary_ID PM_MCUBOOT_SECONDARY_ID
#define PM_mcuboot_secondary_IS_ENABLED 1
#define PM_5_LABEL MCUBOOT_SECONDARY
#define PM_MCUBOOT_SECONDARY_DEV_NAME "NRF_FLASH_DRV_NAME"
#define PM_LITTLEFS_STORAGE_OFFSET 0xf4000
#define PM_LITTLEFS_STORAGE_ADDRESS 0xf4000
#define PM_LITTLEFS_STORAGE_END_ADDRESS 0xfa000
#define PM_LITTLEFS_STORAGE_SIZE 0x6000
#define PM_LITTLEFS_STORAGE_NAME littlefs_storage
#define PM_LITTLEFS_STORAGE_ID 6
#define PM_littlefs_storage_ID PM_LITTLEFS_STORAGE_ID
#define PM_littlefs_storage_IS_ENABLED 1

Sensor's map:
#define PM_MCUBOOT_PRIMARY_APP_OFFSET 0xc200
#define PM_MCUBOOT_PRIMARY_APP_ADDRESS 0xc200
#define PM_MCUBOOT_PRIMARY_APP_END_ADDRESS 0x80000
#define PM_MCUBOOT_PRIMARY_APP_SIZE 0x73e00
#define PM_MCUBOOT_PRIMARY_APP_NAME mcuboot_primary_app
#define PM_MCUBOOT_PRIMARY_APP_ID 4
#define PM_mcuboot_primary_app_ID PM_MCUBOOT_PRIMARY_APP_ID
#define PM_mcuboot_primary_app_IS_ENABLED 1
#define PM_4_LABEL MCUBOOT_PRIMARY_APP
#define PM_MCUBOOT_PRIMARY_APP_DEV flash_controller
#define PM_MCUBOOT_PRIMARY_APP_DEFAULT_DRIVER_KCONFIG CONFIG_SOC_FLASH_NRF
#define PM_MCUBOOT_SECONDARY_OFFSET 0x80000
#define PM_MCUBOOT_SECONDARY_ADDRESS 0x80000
#define PM_MCUBOOT_SECONDARY_END_ADDRESS 0xf4000
#define PM_MCUBOOT_SECONDARY_SIZE 0x74000
#define PM_MCUBOOT_SECONDARY_NAME mcuboot_secondary
#define PM_MCUBOOT_SECONDARY_ID 5
#define PM_mcuboot_secondary_ID PM_MCUBOOT_SECONDARY_ID
#define PM_mcuboot_secondary_IS_ENABLED 1

By the way do you know if there were any changes to power management from v2.0.2 to v2.2.0?

It seems that v2.2.0 consumes more current for some reason.

Thanks David