nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

OmarN — Mon, 05 Aug 2024 14:06:08 GMT

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Wed, 01 Mar 2023 09:25:44 GMT

[quote user="DavidKaplan"]Finally![/quote]

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!

[quote user="DavidKaplan"]Could you point me to a current thread about adding back the key to the bootloader in Zephyr v2.2.0 ?[/quote]

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Wed, 01 Mar 2023 09:17:11 GMT

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Tue, 28 Feb 2023 14:00:01 GMT

[quote user="DavidKaplan"]

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?

[/quote]

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.

[quote user="DavidKaplan"]Should the padded data be zero or 0xFF?[/quote]

Are you generating the file manually?

I recommend that you first try to use build/zephyr/app_update.bin without any changes.

[quote user="DavidKaplan"]So, I can't reproduce a DFU successfully like you, so it is evident that I am doing more than one thing wrong.[/quote]

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Tue, 28 Feb 2023 13:35:46 GMT

OK I see that the secondary image size on my Central nRF52840 build and my nRF9160 & custom sensors are different sizes.

1) nRF52840 central
#define PM_MCUBOOT_SECONDARY_OFFSET 0x86000
#define PM_MCUBOOT_SECONDARY_ADDRESS 0x86000
#define PM_MCUBOOT_SECONDARY_END_ADDRESS 0x100000
#define PM_MCUBOOT_SECONDARY_SIZE 0x7a000
#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

send_upload2()
	int last_addr = (PM_MCUBOOT_SECONDARY_END_ADDRESS-0x6000);  // ?!?
===================================================
2) nRF9160 sensor
#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

======================================================
3) Custom sensor
#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

I just adjusted the central code so it would only send 0x74000 bytes instead of 0x7a000,

but that did not help either. (475136 = 0x74000)

send_upload2()
int last_addr = (PM_MCUBOOT_SECONDARY_END_ADDRESS-0x6000); // ?!?

I got when uploading:

[ 99% ] |================================================= | (474900/475136 bytes)Error in image upload response: 1

Still the questions in the previous post are open.

Thanks David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Tue, 28 Feb 2023 11:36:43 GMT

OK, I flashed my sensor code using the "nrf9160dk_nrf52840" build and then tried to DFU from my Central with the image streamed and the Central got OK from the nRF9160 dk sensor as I received before.

Central log:

02-28 11:23 28/02/2023 09:23:36 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 675] DFU:317200/319026 400
02-28 11:23 28/02/2023 09:23:36 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 675] DFU:317600/319026 400
02-28 11:23 28/02/2023 09:23:36 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 675] DFU:318000/319026 400
02-28 11:23 28/02/2023 09:23:36 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 675] DFU:318400/319026 400
02-28 11:23 28/02/2023 09:23:36 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 675] DFU:318800/319026 226
02-28 11:23 28/02/2023 09:23:37 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 789] ImageChecksum AF3A0C7A
02-28 11:23 28/02/2023 09:23:37 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c: 927] SMP UploadOK
02-28 11:23 28/02/2023 09:23:37 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c:1208] ImageList
02-28 11:23 28/02/2023 09:23:37 |  27/02/2023 23:23:14[.ami_vibe.c:1941] ...[ami_smp.c:1211] ImageTest
02-28 11:23 28/02/2023 09:23:38 |  27/02/2023 23:23:15[.ami_vibe.c:1941] ...[ami_smp.c:1214] ImageReset
02-28 11:23 28/02/2023 09:23:38 |  27/02/2023 23:23:16[.ami_vibe.c:1941] ...[ami_ble.c:2639] DFUConnectFinishedErr:0

nRF9160-DK log where I used the programmer at the start to perform a reset.

[00:01:38.147,705] <ESC>[1;31m<err> mpsl_init: m_assert_handler: MPSL ASSERT: 112, 2195<ESC>[0m<CR><LF>
[00:01:38.155,456] <ESC>[1;31m<err> os: hard_fault: ***** HARD FAULT *****<ESC>[0m<CR><LF>
[00:01:38.162,109] <ESC>[1;31m<err> os: hard_fault:   Fault escalation (see below)<ESC>[0m<CR><LF>
[00:01:38.169,433] <ESC>[1;31m<err> os: hard_fault: ARCH_EXCEPT with reason 3<LF>
<ESC>[0m<CR><LF>
[00:01:38.176,452] <ESC>[1;31m<err> os: esf_dump: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000000<ESC>[0m<CR><LF>
[00:01:38.186,065] <ESC>[1;31m<err> os: esf_dump: r3/a4:  0x20003f54 r12/ip:  0x00000000 r14/lr:  0x0003a413<ESC>[0m<CR><LF>
[00:01:38.195,678] <ESC>[1;31m<err> os: esf_dump:  xpsr:  0x41000018<ESC>[0m<CR><LF>
[00:01:38.201,843] <ESC>[1;31m<err> os: esf_dump: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000<ESC>[0m<CR><LF>
[00:01:38.213,226] <ESC>[1;31m<err> os: esf_dump: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000<ESC>[0m<CR><LF>
[00:01:38.224,609] <ESC>[1;31m<err> os: esf_dump: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000<ESC>[0m<CR><LF>
[00:01:38.235,992] <ESC>[1;31m<err> os: esf_dump: s[12]:  0x00000000  s[13]:  0x00000002  s[14]:  0x00000000  s[15]:  0x00000000<ESC>[0m<CR><LF>
[00:01:38.247,344] <ESC>[1;31m<err> os: esf_dump: fpscr:  0x00000100<ESC>[0m<CR><LF>
[00:01:38.253,479] <ESC>[1;31m<err> os: esf_dump: Faulting instruction address (r15/pc): 0x0002f618<ESC>[0m<CR><LF>
[00:01:38.262,298] <ESC>[1;31m<err> os: z_fatal_error: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0<ESC>[0m<CR><LF>
[00:01:38.271,331] <ESC>[1;31m<err> os: z_fatal_error: Fault during interrupt handling<LF>
<ESC>[0m<CR><LF>
[00:01:38.279,113] <ESC>[1;31m<err> os: z_fatal_error: Current thread: 0x20002ca8 (unknown)<ESC>[0m<CR><LF>
[00:01:38.287,261] <ESC>[1;31m<err> fatal_error: k_sys_fatal_error_handler: Resetting system<ESC>[0m<CR>
[00:00:00.252,288] <ESC>[0m<inf> board_control: vcom0_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.259,155] <ESC>[0m<inf> board_control: vcom2_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.266,052] <ESC>[0m<inf> board_control: led1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.272,796] <ESC>[0m<inf> board_control: led2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.279,541] <ESC>[0m<inf> board_control: led3_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.286,254] <ESC>[0m<inf> board_control: led4_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.292,999] <ESC>[0m<inf> board_control: switch1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.299,987] <ESC>[0m<inf> board_control: switch2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.306,976] <ESC>[0m<inf> board_control: button1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.313,995] <ESC>[0m<inf> board_control: button2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.320,983] <ESC>[0m<inf> board_control: nrf_interface_pins_0_2_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.329,040] <ESC>[0m<inf> board_control: nrf_interface_pins_3_5_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.337,097] <ESC>[0m<inf> board_control: nrf_interface_pins_6_8_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.345,123] <ESC>[0m<inf> board_control: Board configured.<ESC>[0m<CR><LF>
*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.355,041] <ESC>[0m<inf> mcuboot: Starting bootloader<ESC>[0m<CR><LF>
[00:00:00.360,992] <ESC>[0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.370,971] <ESC>[0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.381,072] <ESC>[0m<inf> mcuboot: Boot source: none<ESC>[0m<CR><LF>
[00:00:00.386,474] <ESC>[0m<inf> mcuboot: Swap type: none<ESC>[0m<CR><LF>
[00:00:00.460,571] <ESC>[0m<inf> mcuboot: Bootloader chainload address offset: 0xc000<ESC>[0m<CR><LF>
[00:00:00.468,139] <ESC>[0m<inf> mcuboot: Jumping to the first image slot<ESC>[0m<CR>
ÿ[00:00:00.000,152] <ESC>[0m<inf> board_control: init: vcom0_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.007,568] <ESC>[0m<inf> board_control: init: vcom2_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.015,014] <ESC>[0m<inf> board_control: init: led1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.022,277] <ESC>[0m<inf> board_control: init: led2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.029,541] <ESC>[0m<inf> board_control: init: led3_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.036,804] <ESC>[0m<inf> board_control: init: led4_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.044,067] <ESC>[0m<inf> board_control: init: switch1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.051,605] <ESC>[0m<inf> board_control: init: switch2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.059,143] <ESC>[0m<inf> board_control: init: button1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.066,650] <ESC>[0m<inf> board_control: init: button2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.074,188] <ESC>[0m<inf> board_control: init: nrf_interface_pins_0_2_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.082,763] <ESC>[0m<inf> board_control: init: nrf_interface_pins_3_5_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.091,339] <ESC>[0m<inf> board_control: init: nrf_interface_pins_6_8_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.099,914] <ESC>[0m<inf> board_control: init: Board configured.<ESC>[0m<CR><LF>
*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.110,412] <ESC>[0m<inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_main.c: 631] Startup<CR><LF>
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:0<CR><LF>
00/00/0000 00:00:00[ami_main.c: 448] MainInitErr:4096<CR><LF>
00/00/0000 00:00:00[ami_main.c: 657] VaporBLE#0 26-Feb-2023 v1.0.0 1.0 2.26<CR><LF>
build time: Feb 28 2023 11:08:57<CR><LF>
[00:00:00.245,910] <ESC>[0m<inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: <CR><LF>
                                         6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..<CR><LF>
                                         1f 85 d8 e1                                      |....             <ESC>[0m<CR><LF>
[00:00:00.276,824] <ESC>[0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)<ESC>[0m<CR><LF>
[00:00:00.285,797] <ESC>[0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)<ESC>[0m<CR><LF>
[00:00:00.293,518] <ESC>[0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098<ESC>[0m<CR><LF>
[00:00:00.306,365] <ESC>[0m<inf> bt_hci_core: bt_init: No ID address. App must call settings_load()<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 506] ActualTxPwr:8<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 788] Bluetooth initialized<CR><LF>
[00:00:00.325,286] <ESC>[1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name<ESC>[0m<CR><LF>
[00:00:00.333,099] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: Identity: C0:F1:EE:C6:31:44 (random)<ESC>[0m<CR><LF>
[00:00:00.342,010] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059<ESC>[0m<CR><LF>
[00:00:00.353,057] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa<ESC>[0m<CR><LF>
[00:00:00.362,243] <ESC>[1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x20<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 593] AdvertisingStarted<CR><LF>
00/00/0000 00:00:00[ami_main.c: 676] BootConfirmed<CR><LF>
00/00/0000 00:00:00[ami_main.c: 683] ResetCause:1<CR><LF>
[00:00:00.404,693] <ESC>[1;31m<err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)<ESC>[0m<CR><LF>
[00:00:00.252,288] <ESC>[0m<inf> board_control: vcom0_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.259,155] <ESC>[0m<inf> board_control: vcom2_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.266,082] <ESC>[0m<inf> board_control: led1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.272,796] <ESC>[0m<inf> board_control: led2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.279,541] <ESC>[0m<inf> board_control: led3_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.286,285] <ESC>[0m<inf> board_control: led4_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.293,029] <ESC>[0m<inf> board_control: switch1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.300,048] <ESC>[0m<inf> board_control: switch2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.307,037] <ESC>[0m<inf> board_control: button1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.314,025] <ESC>[0m<inf> board_control: button2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.321,044] <ESC>[0m<inf> board_control: nrf_interface_pins_0_2_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.329,101] <ESC>[0m<inf> board_control: nrf_interface_pins_3_5_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.337,158] <ESC>[0m<inf> board_control: nrf_interface_pins_6_8_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.345,214] <ESC>[0m<inf> board_control: Board configured.<ESC>[0m<CR><LF>
*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.355,102] <ESC>[0m<inf> mcuboot: Starting bootloader<ESC>[0m<CR><LF>
[00:00:00.361,083] <ESC>[0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.371,063] <ESC>[0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.381,164] <ESC>[0m<inf> mcuboot: Boot source: none<ESC>[0m<CR><LF>
[00:00:00.386,566] <ESC>[0m<inf> mcuboot: Swap type: none<ESC>[0m<CR><LF>
[00:00:00.460,662] <ESC>[0m<inf> mcuboot: Bootloader chainload address offset: 0xc000<ESC>[0m<CR><LF>
[00:00:00.468,231] <ESC>[0m<inf> mcuboot: Jumping to the first image slot<ESC>[0m<CR>
ÿ[00:00:00.000,152] <ESC>[0m<inf> board_control: init: vcom0_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.007,568] <ESC>[0m<inf> board_control: init: vcom2_pins_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.014,984] <ESC>[0m<inf> board_control: init: led1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.022,247] <ESC>[0m<inf> board_control: init: led2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.029,510] <ESC>[0m<inf> board_control: init: led3_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.036,773] <ESC>[0m<inf> board_control: init: led4_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.044,067] <ESC>[0m<inf> board_control: init: switch1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.051,574] <ESC>[0m<inf> board_control: init: switch2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.059,112] <ESC>[0m<inf> board_control: init: button1_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.066,650] <ESC>[0m<inf> board_control: init: button2_pin_routing is ENABLED<ESC>[0m<CR><LF>
[00:00:00.074,188] <ESC>[0m<inf> board_control: init: nrf_interface_pins_0_2_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.082,763] <ESC>[0m<inf> board_control: init: nrf_interface_pins_3_5_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.091,339] <ESC>[0m<inf> board_control: init: nrf_interface_pins_6_8_routing is disabled<ESC>[0m<CR><LF>
[00:00:00.099,914] <ESC>[0m<inf> board_control: init: Board configured.<ESC>[0m<CR><LF>
*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.110,412] <ESC>[0m<inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_main.c: 631] Startup<CR><LF>
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:0<CR><LF>
00/00/0000 00:00:00[ami_main.c: 448] MainInitErr:4096<CR><LF>
00/00/0000 00:00:00[ami_main.c: 657] VaporBLE#0 26-Feb-2023 v1.0.0 1.0 2.26<CR><LF>
build time: Feb 28 2023 11:08:57<CR><LF>
[00:00:00.245,971] <ESC>[0m<inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: <CR><LF>
                                         6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..<CR><LF>
                                         1f 85 d8 e1                                      |....             <ESC>[0m<CR><LF>
[00:00:00.276,916] <ESC>[0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)<ESC>[0m<CR><LF>
[00:00:00.285,888] <ESC>[0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)<ESC>[0m<CR><LF>
[00:00:00.293,640] <ESC>[0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098<ESC>[0m<CR><LF>
[00:00:00.306,488] <ESC>[0m<inf> bt_hci_core: bt_init: No ID address. App must call settings_load()<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 506] ActualTxPwr:8<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 788] Bluetooth initialized<CR><LF>
[00:00:00.325,408] <ESC>[1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name<ESC>[0m<CR><LF>
[00:00:00.333,251] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: Identity: C0:F1:EE:C6:31:44 (random)<ESC>[0m<CR><LF>
[00:00:00.342,132] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059<ESC>[0m<CR><LF>
[00:00:00.353,179] <ESC>[0m<inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa<ESC>[0m<CR><LF>
[00:00:00.362,365] <ESC>[1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name<ESC>[0m<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x20<CR><LF>
00/00/0000 00:00:00[ami_ble.c: 593] AdvertisingStarted<CR><LF>
00/00/0000 00:00:00[ami_main.c: 676] BootConfirmed<CR><LF>
00/00/0000 00:00:00[ami_main.c: 683] ResetCause:1<CR><LF>
[00:00:00.404,815] <ESC>[1;31m<err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)<ESC>[0m<CR><LF>
01/01/2004 00:01:00[ami_main.c: 601] NewMin<CR><LF>
01/01/2004 00:02:00[ami_main.c: 601] NewMin<CR><LF>
01/01/2004 00:03:00[ami_main.c: 601] NewMin<CR><LF>
01/01/2004 00:04:00[ami_main.c: 601] NewMin<CR><LF>

It does not look that the bootloader showed anything different between the programmer reset and the SMP reset.

*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.355,041] <ESC>[0m<inf> mcuboot: Starting bootloader<ESC>[0m<CR><LF>
[00:00:00.360,992] <ESC>[0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.370,971] <ESC>[0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.381,072] <ESC>[0m<inf> mcuboot: Boot source: none<ESC>[0m<CR><LF>
[00:00:00.386,474] <ESC>[0m<inf> mcuboot: Swap type: none<ESC>[0m<CR><LF>
[00:00:00.460,571] <ESC>[0m<inf> mcuboot: Bootloader chainload address offset: 0xc000<ESC>[0m<CR><LF>
[00:00:00.468,139] <ESC>[0m<inf> mcuboot: Jumping to the first image slot<ESC>[0m<CR>
======================================================================
*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
[00:00:00.355,102] <ESC>[0m<inf> mcuboot: Starting bootloader<ESC>[0m<CR><LF>
[00:00:00.361,083] <ESC>[0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.371,063] <ESC>[0m<inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<ESC>[0m<CR><LF>
[00:00:00.381,164] <ESC>[0m<inf> mcuboot: Boot source: none<ESC>[0m<CR><LF>
[00:00:00.386,566] <ESC>[0m<inf> mcuboot: Swap type: none<ESC>[0m<CR><LF>
[00:00:00.460,662] <ESC>[0m<inf> mcuboot: Bootloader chainload address offset: 0xc000<ESC>[0m<CR><LF>
[00:00:00.468,231] <ESC>[0m<inf> mcuboot: Jumping to the first image slot<ESC>[0m<CR>

Next, I tried to use my nRF52840-DK as the Central with your code and my nRF9160-DK as the sensor.

After using the JFlash.ex flash program to upload the app_update.bin file to 0x86000 not 0x50000 and

changing the connection UUID to the one I use, the Central connected.

I pressed button#1 and got a list with only one slot the first time and the second time two slots.

(Both times the upload failed).

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?

Should the padded data be zero or 0xFF?

In any case, I got an error at almost the end of the upload from the end unit:

*** 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 ***
Starting Bluetooth Central SMP Client example
I: SoftDevice Controller build revision:
I: 6d 90 41 2a 38 e8 ad 17 |m.A*8...
I: 29 a5 03 38 39 27 d7 85 |)..89'..
I: 1f 85 d8 e1             |....
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098
I: Identity: DF:EE:12:96:B1:89 (random)
I: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059
I: LMP: version 5.3 (0x0c) subver 0x11fa
Bluetooth initialized
Scanning successfully started
Filters matched. Address: C0:F1:EE:C6:31:44 (random) connectable: yes
Image list command send error (err: -6)
Connected: C0:F1:EE:C6:31:44 (random)
MTU exchange pending
E: pairing failed (peer reason 0x3)
Security failed: C0:F1:EE:C6:31:44 (random) level 1 err 4
MTU exchange successful
Current MTU: 498
The discovery procedure succeeded

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

-----------SECONDARY IMAGE-----------
      slot: 1
      version: 0.0.0
      hash: 0x67fb72f73a0fda917c78ad444dbdbc7955e1b12842a66a1222f4ca95a6f0
      bootable: true
      pending: false
      confirmed: false
      active: false
      permanent: false
[  95% ] |===============================================   | (474900/499712 bytes)Error in image upload response: 1

I tried the nRF52840 Central updating my custom sensor and got the same error:

[ 95% ] |=============================================== | (474900/499712 bytes)Error in image upload response: 1

So, I can't reproduce a DFU successfully like you, so it is evident that I am doing more than one thing wrong.

Thanks David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Mon, 27 Feb 2023 08:27:10 GMT

[quote user="DavidKaplan"]What am I missing?[/quote]

To test UART logging from the nRF52840 on the nRF9160, do the following:

Go to zephyr/samples/hello_world.
Build for "nrf9160dk_nrf52840".
Flip the switch on nRF9160DK to nRF52.
Program.
Connect a serial terminal to VCOM1 and see it log "Hello World ..."

I did this, and it printed for me.

[quote user="DavidKaplan"]Could you just post your board files?[/quote]

I just used the default board files for the DKs; see Zephyr arm boards.
For the nRF52840DK, I used nrf52840dk_nrf52840.

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Sun, 26 Feb 2023 05:40:50 GMT

Sorry but for some reason I could not get the nRF9160-Dk 's nrf52840 to output anything on its uart.

According to the documentation, it should output on VCOM1 using uart TX P0.3 & RX P0.5.

# ----------------------------------------
# USE Uart Instead of RTT
# ----------------------------------------
CONFIG_UART_CONSOLE=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_SERIAL=y
# ----------------------------------------
# Enable UART console, for printk()
# ----------------------------------------
CONFIG_CONSOLE_HANDLER=n
CONFIG_CONSOLE=y
CONFIG_PRINTK=y

# ----------------------------------------
# USE RTT  Instead of Uart
# ----------------------------------------
#CONFIG_CONSOLE=y
#CONFIG_RTT_CONSOLE=y
#CONFIG_USE_SEGGER_RTT=y
#CONFIG_LOG_BACKEND_RTT=y

What am I missing?

Could you just post your board files?

Also, on my central zephyr v2.2.0 complains about not using pin ctrl for the uart.

I added the ms88sf2-pinctrl.dtsi file which I included in ms88sf2.dts

&uart1 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart1_default>;
	pinctrl-1 = <&uart1_sleep>;
	pinctrl-names = "default", "sleep";
};

&pinctrl {
	uart1_default: uart1_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 3)>,
				<NRF_PSEL(UART_RTS, 1, 8)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 5)>,
				<NRF_PSEL(UART_CTS, 0, 7)>;
			bias-pull-up;
		};
	};

	uart1_sleep: uart1_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 3)>,
				<NRF_PSEL(UART_RX, 0, 5)>,
				<NRF_PSEL(UART_RTS, 1, 8)>,
				<NRF_PSEL(UART_CTS, 0, 7)>;
			low-power-enable;
		};
	};

};

                 from C:\ncs\v2.2.0\zephyr\drivers\serial\uart_nrfx_uarte.c:11:
C:\ncs\v2.2.0\zephyr\include\zephyr\toolchain\gcc.h:77:36: error: static assertion failed: "/soc/uart@40028000 defined without required pin configuration"
   77 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
      |                                    ^~~~~~~~~~~~~~
c:\ncs\v2.2.0\zephyr\soc\arm\nordic_nrf\common\soc_nrf_common.h:218:9: note: in expansion of macro 'BUILD_ASSERT'
  218 |         BUILD_ASSERT((IS_ENABLED(CONFIG_PINCTRL) &&                     \
      |         ^~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\drivers\serial\uart_nrfx_uarte.c:2080:9: note: in expansion of macro 'NRF_DT_CHECK_PIN_ASSIGNMENTS'
 2080 |         NRF_DT_CHECK_PIN_ASSIGNMENTS(UARTE(idx), 1,                            \
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\drivers\serial\uart_nrfx_uarte.c:2189:1: note: in expansion of macro 'UART_NRF_UARTE_DEVICE'
 2189 | UART_NRF_UARTE_DEVICE(1);
      | ^~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\include\zephyr\toolchain\gcc.h:77:36: error: static assertion failed: "/soc/uart@40028000 has pinctrl states defined although PINCTRL is not enabled"
   77 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
      |                                    ^~~~~~~~~~~~~~
c:\ncs\v2.2.0\zephyr\soc\arm\nordic_nrf\common\soc_nrf_common.h:234:9: note: in expansion of macro 'BUILD_ASSERT'
  234 |         BUILD_ASSERT(IS_ENABLED(CONFIG_PINCTRL) ||                      \
      |         ^~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\drivers\serial\uart_nrfx_uarte.c:2080:9: note: in expansion of macro 'NRF_DT_CHECK_PIN_ASSIGNMENTS'
 2080 |         NRF_DT_CHECK_PIN_ASSIGNMENTS(UARTE(idx), 1,                            \
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\zephyr\drivers\serial\uart_nrfx_uarte.c:2189:1: note: in expansion of macro 'UART_NRF_UARTE_DEVICE'
 2189 | UART_NRF_UARTE_DEVICE(1);
      | ^~~~~~~~~~~~~~~~~~~~~

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Fri, 24 Feb 2023 12:48:58 GMT

[quote user="DavidKaplan"]

I cannot see any bootloader mcuboot information in the nRF9160 RTT log.

So How did you get it?

What am I doing wrong?

[/quote]

Aha, this was a misunderstanding.

Since working with the Development Kit, I used UART for logging.

I have used RTT for logging from the Bootloader before, but I remember it to be unstable.
Whether you want to continue trying to make Bootloader RTT work is up to you.

Have you been able to update the peripheral using the changes I made to the SMP Client?

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Thu, 23 Feb 2023 13:42:49 GMT

I understand the mcuboot configuration as you explained, mcuboot.conf are additions and prj.conf override.

Then you say that you used my project definitions and get mcuboot information on the peripheral without any changes in the RTT log?

I cannot see any bootloader mcuboot information in the nRF9160 RTT log.

So How did you get it?

What am I doing wrong?

Your log:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.000,610] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
FFFFFFFFFFFFFFFFFFFFF

My log:

00> SEGGER J-Link V7.66a - Real time terminal output
00> J-Link OB-K22-NordicSemi compiled Nov  7 2022 16:21:34 V1.0, SN=960005601
00> Process: JLinkGDBServerCL.exe
00> [00:00:00.035,827] <err> LSM6DSL: lsm6dsl_init: Failed to initialize chip
00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> [00:00:00.036,529] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00> 00/00/0000 00:00:00[ami_main.c: 631] Startup

When I upload does the peripheral information seem OK?

00> 22/02/2023 20:31:29[ami_main.c: 175] Connection parameters updated.
00>  interval: 40, latency: 0, timeout: 42
00> ARRAY_SIZE(image_upload_decode): [6]
00> req.off [0]
00> req.size [319026]
00> req.upgrade [0]
00> req.image [0]
00> req.img_data.len [400]
00> req.img_data.value [536969252]
00> req.data_sha.len [5]
00> req.data_sha.value [536969671]

Thanks, and have a good weekend, David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Thu, 23 Feb 2023 13:31:53 GMT

[quote user="DavidKaplan"]Could you please send me your nRF9160-Dk or other board's child mcuboot.conf file and the prg.conf file that you tested?[/quote]

For the SMP Server, I used code supplied by you,

I used my Bluetooth: Central SMP Client DFU sample for the SMP Client. The only change was the UUID to make it connect to your device.
This sample is an edited version of Simon's example.

[quote user="DavidKaplan"]Is the child mcuboot.conf file just additions to the default mcuboot prog.conf file?[/quote]

Yes. child_image/mcuboot.conf is added as extra configurations to the MCUboot default prj.conf.
However, if you use child_image/mcuboot/prj.conf, it will overwrite the MCUboot configuration. I do not recommend using child_image/mcuboot/prj.conf.

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Thu, 23 Feb 2023 07:13:55 GMT

OK, you are of course correct about the last block and upload_chuck being updated.

My Central code reports that the DFU goes well but the nRF9160-DK and my custom end units still do not upgrade.

The image checksum compared to my harddrive is the same.

[ami_smp.c: 676] DFU:317200/319026
[ami_smp.c: 676] DFU:317600/319026
[ami_smp.c: 676] DFU:318000/319026
[ami_smp.c: 676] DFU:318400/319026
[ami_smp.c: 676] DFU:318800/319026
[ami_smp.c: 777] ImageChecksum AF3A0C7A
[ami_smp.c: 911] SMP UploadOK
[ami_smp.c:1192] ImageList

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x76d196d413b84fe1177ba6c33a79744f579a07298a6a282d97ffd7a73d82ee6
      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:1195] ImageTest

-----------PRIMARY IMAGE-----------
      slot: 0
      version: 0.0.0
      hash: 0x76d196d413b84fe1177ba6c33a79744f579a07298a6a282d97ffd7a73d82ee6
      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:1198] ImageReset
22/02/2023 20:49:50[ami_ble.c: 861] Disconnected: C0:F1:EE:C6:31:44 (random) (reason 8)
[ami_ble.c:2639] DFUConnectFinishedErr:0

#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   = 0; // AMI_VIBEBT_PM_MCUBOOT_SECONDARY_ADDRESS; 
		int           last_addr    = 0; // AMI_VIBEBT_PM_MCUBOOT_SECONDARY_ADDRESS+ami_state->dfu.ImageSize.ulong; 
		int           curr_addr    = 0; // AMI_VIBEBT_PM_MCUBOOT_SECONDARY_ADDRESS;
		int           upload_chunk = UPLOAD_CHUNK;
		int           err;
        uint64_t      off = 0;
	    bool          update_complete = false;
        uint8_t       encode_len;

		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);
			//-----------------------------------------------------------------
			// Wait until response is received until sending the next chunk
			//-----------------------------------------------------------------
			// ?!? err = k_sem_take(&upload_sem, K_MSEC(AMI_DFU_MAX_SEND_ACK_MS));		    
			k_sem_take(&upload_sem, K_FOREVER);
			last_addr    = ami_state->dfu.ImageSize.ulong;
            err = 0;
			if (ami_state->DFUErr){
			  d_printf(LINE_INFO,kDbg_Error|kDbg_Host,"SMPErr:%u",ami_state->DFUErr);
			  update_complete = true;
			  break;
			}
			//-------------------------------------------------------
			// Disconnected?
			//-------------------------------------------------------
			if (!atomic_get(&ble_connected)){
			  ami_state->DFUErr = AMI_DFU_ERR_DISCONNECTED;
			  update_complete = true;
			  break;
			}
			//-----------------------------------------------------------------
			// No Error but semiphore times out!
			//-----------------------------------------------------------------
			if (err){
			  ami_state->DFUErr = AMI_SMP_DFU_ERR_LOOP_TIMEOUT;
			  update_complete = true;
			  break;
			}
			//-----------------------------------------------------------------
			// Last block?
			//-----------------------------------------------------------------
			if ((curr_addr+UPLOAD_CHUNK) > last_addr){
				upload_chunk = last_addr - curr_addr;
				update_complete = true;
			}
			progress_print(curr_addr-start_addr,last_addr-start_addr);
			//-----------------------------------------------------------------
			// Get the data block from ringbuffer
			//-----------------------------------------------------------------
			ami_state->DFUErr = ami_smp_RetDataBlock(data,upload_chunk);
			if (ami_state->DFUErr){ 
			  update_complete = true;
			  break;
			}
			//-----------------------------------------------------------------
			// First block add image size
			//-----------------------------------------------------------------
			off = curr_addr - start_addr;
			if (off == 0){
				encode_len = 8;
			} else {
				encode_len = 6;
			}
			data[upload_chunk] = '\0';
			zse->constant_state->stop_on_error = true;
			zcbor_map_start_encode(zse, encode_len);
			zcbor_tstr_put_lit(zse, "image");
			zcbor_int64_put(zse, 0);
			zcbor_tstr_put_lit(zse, "data");
			zcbor_bstr_put_lit(zse, data);
			if(off == 0){
				zcbor_tstr_put_lit(zse, "len");
				zcbor_uint64_put(zse, (uint64_t)last_addr-start_addr);
			}
			zcbor_tstr_put_lit(zse, "off");
			zcbor_uint64_put(zse, off);
			if(off == 0){
				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, encode_len);

			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

Could you please send me your nRF9160-Dk or other board's child mcuboot.conf file and the prg.conf file that you tested?

Is the child mcuboot.conf file just additions to the default mcuboot prog.conf file?

I still can't get the bootloader to output anything in the sensor's RTT log, but I see the additional printks

00> ARRAY_SIZE(image_upload_decode): [6]
00> req.off [0]
00> req.size [319026]
00> req.upgrade [0]
00> req.image [0]
00> req.img_data.len [400]
00> req.img_data.value [536969252]
00> req.data_sha.len [5]
00> req.data_sha.value [536969671]

(Connection lost)
00> SEGGER J-Link V7.66a - Real time terminal output
00> J-Link OB-K22-NordicSemi compiled Nov  7 2022 16:21:34 V1.0, SN=960005601
00> Process: JLinkGDBServerCL.exe
00> [00:00:00.035,827] <err> LSM6DSL: lsm6dsl_init: Failed to initialize chip
00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> [00:00:00.036,529] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00> 00/00/0000 00:00:00[ami_main.c: 631] Startup
00> 00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:0
00> 00/00/0000 00:00:00[ami_main.c: 448] MainInitErr:4096
00> 00/00/0000 00:00:00[ami_main.c: 657] VaporBLE#0 23-Feb-2023 v1.0.0 1.0 2.23
00> build time: Feb 23 2023 08:27:22
00> [00:00:00.141,448] <inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision:
00>                                          6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
00>                                          1f 85 d8 e1                                      |....
00> [00:00:00.145,721] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
00> [00:00:00.146,240] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
00> [00:00:00.146,728] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098
00> [00:00:00.147,827] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
00> 00/00/0000 00:00:00[ami_ble.c: 506] ActualTxPwr:8
00> 00/00/0000 00:00:00[ami_ble.c: 788] Bluetooth initialized
00> [00:00:00.149,383] <wrn> bt_hci_core: bt_set_name: Unable to store name
00> [00:00:00.150,299] <inf> bt_hci_core: bt_dev_show_info: Identity: C0:F1:EE:C6:31:44 (random)
00> [00:00:00.150,817] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059
00> [00:00:00.151,458] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa
00> [00:00:00.152,191] <wrn> bt_hci_core: bt_set_name: Unable to store name
00> 00/00/0000 00:00:00[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x20
00> 00/00/0000 00:00:00[ami_ble.c: 593] AdvertisingStarted
00> 00/00/0000 00:00:00[ami_main.c: 676] BootConfirmed
00> 00/00/0000 00:00:00[ami_main.c: 683] ResetCause:1
00> [00:00:00.169,036] <err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)
00> 01/01/2004 00:00:01[ami_adc.c: 470] RdLSM6DSLThread
00> 01/01/2004 00:00:26[ami_main.c: 143] Connected
00> 01/01/2004 00:00:26[ami_main.c: 198] LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
00> 01/01/2004 00:00:31[ami_main.c: 175] Connection parameters updated.
00>  interval: 40, latency: 0, timeout: 42
00> 01/01/2004 00:00:34[ami_main_serv.c:  58] Received data, handle 0, conn 0x20002860
00> 22/02/2023 20:30:10[ami_main.c: 153] Disconnected reason:19
00> 22/02/2023 20:30:10[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x0
00> 22/02/2023 20:30:10[ami_ble.c: 593] AdvertisingStarted
00> 22/02/2023 20:30:11[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x0
00> 22/02/2023 20:30:35[ami_main.c: 601] NewMin
00> 22/02/2023 20:31:24[ami_main.c: 143] Connected
00> 22/02/2023 20:31:25[ami_main.c: 198] LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
00> 22/02/2023 20:31:29[ami_main.c: 175] Connection parameters updated.
00>  interval: 40, latency: 0, timeout: 42
00> ARRAY_SIZE(image_upload_decode): [6]
00> req.off [0]
00> req.size [319026]
00> req.upgrade [0]
00> req.image [0]
00> req.img_data.len [400]
00> req.img_data.value [536969252]
00> req.data_sha.len [5]
00> req.data_sha.value [536969671]
00> 22/02/2023 20:31:34[ami_main.c: 175] Connection parameters updated.
00>  interval: 9, latency: 0, timeout: 42
00> 22/02/2023 20:31:35[ami_main.c: 601] NewMin
00> 22/02/2023 20:32:35[ami_main.c: 601] NewMin
00> [00:00:00.035,827] <err> LSM6DSL: lsm6dsl_init: Failed to initialize chip
00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> [00:00:00.036,499] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
00> 00/00/0000 00:00:00[ami_main.c: 631] Startup
00> 00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:0
00> 00/00/0000 00:00:00[ami_main.c: 448] MainInitErr:4096
00> 00/00/0000 00:00:00[ami_main.c: 657] VaporBLE#0 23-Feb-2023 v1.0.0 1.0 2.23
00> build time: Feb 23 2023 08:27:22
00> [00:00:00.141,448] <inf> sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision:
00>                                          6d 90 41 2a 38 e8 ad 17  29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
00>                                          1f 85 d8 e1                                      |....
00> [00:00:00.145,721] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
00> [00:00:00.146,240] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
00> [00:00:00.146,728] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098
00> [00:00:00.147,827] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
00> 00/00/0000 00:00:00[ami_ble.c: 506] ActualTxPwr:8
00> 00/00/0000 00:00:00[ami_ble.c: 788] Bluetooth initialized
00> [00:00:00.149,383] <wrn> bt_hci_core: bt_set_name: Unable to store name
00> [00:00:00.150,299] <inf> bt_hci_core: bt_dev_show_info: Identity: C0:F1:EE:C6:31:44 (random)
00> [00:00:00.150,817] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059
00> [00:00:00.151,458] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa
00> [00:00:00.152,191] <wrn> bt_hci_core: bt_set_name: Unable to store name
00> 00/00/0000 00:00:00[ami_ble.c: 555] UpdateAdv x:0 y:0 z:0 Tmp:0 F:0x20
00> 00/00/0000 00:00:00[ami_ble.c: 593] AdvertisingStarted
00> 00/00/0000 00:00:00[ami_main.c: 676] BootConfirmed
00> 00/00/0000 00:00:00[ami_main.c: 683] ResetCause:1
00> [00:00:00.169,036] <err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)
00> 01/01/2004 00:00:01[ami_adc.c: 470] RdLSM6DSLThread

Thanks David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Wed, 22 Feb 2023 14:47:19 GMT

[quote user="DavidKaplan"]So I should use the slot size or the image size in the first packet?[/quote]

From SMP: Image upload:

"“len”: optional length of an image, it only appears in the first packet of request, where “off” is 0"

[quote user="DavidKaplan"]So, I changed this in the SMP Client to use the actual size and not Simon's static number.[/quote]

Yes, I think that is how we want to do it in the end. For now, I just set len to the entire length of the Secondary Slot (PM_MCUBOOT_SECONDARY_END_ADDRESS - PM_MCUBOOT_SECONDARY_ADDRESS), in case there is some footer set at the end of the slot.
Then when we get the full upload to work, we can try decreasing the length.

[quote user="DavidKaplan"]In the last packet show which is not divisible by upload_chunk, should I pad it by 0xFFs or 0x00 or does it matter?[/quote]

I think this is handled by the code already?

		if(curr_addr+UPLOAD_CHUNK > last_addr){
			upload_chunk = last_addr - curr_addr;
			update_complete = true;
		}

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Wed, 22 Feb 2023 14:00:46 GMT

I tried to duplicate your changes in my central code, but it did not help for some reason.

So, I changed this in the SMP Client to use the actual size and not Simon's static number.

In your code you use the constant slot start & end addresses from the pm.

The flash_read() function will return, I think, when there is nothing more to read from the actual image.

The upload_chunk is not changed from UPLOAD_CHUNK during the upload.

The length you write seems to be the size of the slot and not the image size.

I could be wrong here.

In any case doing something similar did not give an error but did not work.

I did not add anything in the sensor code to try to see what is happening in the log yet.

I changed only the central code.

I hope to continue on this tomorrow.

So I should use the slot size or the image size in the first packet?

In the last packet show which is not divisible by upload_chunk, should I pad it by 0xFFs or 0x00 or does it matter?

Thank you, David

if(off == 0){
zcbor_tstr_put_lit(zse, "len");
zcbor_uint64_put(zse, (uint64_t)last_addr-start_addr);

// ?!?

// PM_MCUBOOT_SECONDARY_END_ADDRESS- PM_MCUBOOT_SECONDARY_ADDRESS
}

int last_addr = PM_MCUBOOT_SECONDARY_END_ADDRESS;
int start_addr = PM_MCUBOOT_SECONDARY_ADDRESS;

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Wed, 22 Feb 2023 10:17:39 GMT

[quote user="DavidKaplan"]Almost always I got some messages dropped.[/quote]

This is related to the Zephyr Logging module. If you lof too fast, some of the logs will get dropped. You can fix this by tweaking Logging configurations.

On to the DFU issue:

Since DFU works using mobile but not the SMP Client, I figure it must be the SMP Client with the error.
So I added some logging to the mcumgr receiving end to compare messages received from mobile vs SMP Client:

diff --git a/subsys/mgmt/mcumgr/lib/cmd/img_mgmt/src/img_mgmt.c b/subsys/mgmt/mcumgr/lib/cmd/img_mgmt/src/img_mgmt.c
index 8c7dc330db..c5b7818bb8 100644
--- a/subsys/mgmt/mcumgr/lib/cmd/img_mgmt/src/img_mgmt.c
+++ b/subsys/mgmt/mcumgr/lib/cmd/img_mgmt/src/img_mgmt.c
@@ -371,6 +371,20 @@ img_mgmt_upload(struct mgmt_ctxt *ctxt)
        ok = zcbor_map_decode_bulk(zsd, image_upload_decode,
                ARRAY_SIZE(image_upload_decode), &decoded) == 0;
 
+    static int once = 1;
+    if(once){
+        once = 0;
+        printk("ARRAY_SIZE(image_upload_decode): [%d]\n",ARRAY_SIZE(image_upload_decode));
+        printk("req.off [%d]\n", req.off);
+        printk("req.size [%ld]\n", req.size);
+        printk("req.upgrade [%d]\n", req.upgrade);
+        printk("req.image [%d]\n", req.image);
+        printk("req.img_data.len [%d]\n", req.img_data.len);
+        printk("req.img_data.value [%d]\n", req.img_data.value);
+        printk("req.data_sha.len [%d]\n", req.data_sha.len);
+        printk("req.data_sha.value [%d]\n", req.data_sha.value);
+    }
+
        IMG_MGMT_UPLOAD_ACTION_SET_RC_RSN(&action, NULL);
 
        if (!ok) {

I found that the upload size/len in the smp message is the most significant difference here.

So I changed this in the SMP Client to use the actual size and not Simon's static number.
Now DFU works from the SMP Client to your sample:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.000,610] <inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group
FFFFFFFFFFFFFFFFFFFFF
00/00/0000 00:00:00[ami_main.c: 635] Startup
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:0
00/00/0000 00:00:00[ami_main.c: 448] MainInitErr:4096
[00:00:00.106,719] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
--- 3 messages dropped ---
[00:00:00.106,750] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)

I put the change that I made in git:

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/commit/f593bf073f609d76038f2b668783e5b0f485138e

Can you try this change and see if it also fixes the DFU for you?

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Wed, 22 Feb 2023 04:15:04 GMT

This is to me very good news which means you can reproduce my problem so it is most likely not central related or your fix on your central can be easily copied.

Whenever the DFU works, I will need to change the key and I think a signature.

On my sensor board I don't have any uart interface. With the SWD debugger interface, I do not see any bootloader messages regarding the bootloader but maybe you added a define.

Almost always I got some messages dropped.

*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.036,773] [0m<inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group[0m
00/00/0000 00:00:00[ami_main.c: 628] Startup
00/00/0000 00:00:00[ami_cfg.c: 256] DeviceID:51
00/00/0000 00:00:00[ami_lsm6dsl.c:1905] Sensor x:32724 y:32742 z:11246
00/00/0000 00:00:00[ami_lsm6dsl.c:1931] accel x: ms/2 y: ms/2 z: ms/2
00/00/0000 00:00:00[ami_led.c: 139] LedThread
00/00/0000 00:00:00[ami_lsm6dsl.c: 120] RdLSM6DSLThread
00/00/0000 00:00:00[ami_lsm6dsl.c: 153] NewSample
00/00/0000 00:00:00[ami_adc.c: 470] RdLSM6DSLThread
[00:00:03.496,063] [0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)[0m
[1;31m--- 3 messages dropped ---
[0m[00:00:03.496,093] [0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)[0m
[00:00:03.496,124] [0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098[0m
[00:00:03.496,582] [0m<inf> bt_[0m
8
0m

Thanks David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Mon, 20 Feb 2023 14:13:28 GMT

I will continue here:

I have now run your project with two nRF52840DKs.

The DFU uploads fine, but the MCUboot verification of the project fails with the error:

*** 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=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
E: Image in the secondary slot is not valid!
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.2.99-ncs1 ***

Is this the same error that you get?

Tomorrow, I will try to do some more testing with this.

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Thu, 16 Feb 2023 13:28:43 GMT

Hi David,

That sounds good to me!

Please create a new private ticket to upload your project and tag me with Sigurd Hellesvik in the new ticket.

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Thu, 16 Feb 2023 04:51:10 GMT

This morning I programmed my nRF9160-DK with our sensor code with the hardware specific code commented out. I performed a nRF52840 BLE DFU by SMP which reported that all went well but the unit was not updated. I suggest, if possible, I send the sensor code which runs on the nRF9160-DK and you build two images with different Device Information, one which you flash by the programmer and the other that you program to your Central's flash as you did in the Generic SMP BLE DFU test you performed.

This way we could pinpoint if the problem is in my Central or Sensor code.

Using the nRF Connect phone app you can verify the DFU and see in my code if the problem exists in my peripheral sensor code or not.

My code uses ncs V2.2.0 with a local ms88sf2 board definition which should run on any nRF52840 board.

I can only upload my code in a private session.

Thanks David

static int settings_runtime_load(void)
{
  char sTemp[32];	
  eight_bytes unique_64;
  
#if defined(CONFIG_BT_DIS_SETTINGS)
#ifdef TBD
	settings_runtime_set("bt/dis/model",
			     "Zephyr Model",
			     sizeof("Zephyr Model"));
	settings_runtime_set("bt/dis/manuf",
			     "Zephyr Manufacturer",
			     sizeof("Zephyr Manufacturer"));
#endif				 
#if defined(CONFIG_BT_DIS_SERIAL_NUMBER)
    //-------------------------------------------------------------------------
    // Use nRF52840's DeviceID as serial number
    //-------------------------------------------------------------------------
    unique_64.u32[0] = NRF_FICR->DEVICEID[0];
    unique_64.u32[1] = NRF_FICR->DEVICEID[1];
    sprintf(sTemp,"%08X%08X",unique_64.u32[1],unique_64.u32[0]);
	settings_runtime_set("bt/dis/serial",
			     sTemp,
			     strlen(sTemp));
#endif
#if defined(CONFIG_BT_DIS_SW_REV)
    //-------------------------------------------------------------------------
	// Set the software version
    //-------------------------------------------------------------------------
    sprintf(sTemp,"%u.%u %u.%u",
            AMI_VERSION_MAJOR,AMI_VERSION_MINOR,
            AQUA_DEVEL_VERSION_MAJOR,AQUA_DEVEL_VERSION_MINOR);
	settings_runtime_set("bt/dis/sw",
			     sTemp,
			     strlen(sTemp));
#endif
#if defined(CONFIG_BT_DIS_FW_REV)
    //-------------------------------------------------------------------------
	// Set Date as the Firmware version
    //-------------------------------------------------------------------------
    sprintf(sTemp,"%s",__DATE__);
	settings_runtime_set("bt/dis/fw",
			     sTemp,
			     strlen(sTemp));
#endif
#if defined(CONFIG_BT_DIS_HW_REV)
	settings_runtime_set("bt/dis/hw",
			     CONFIG_BT_DIS_HW_REV_STR,
			     sizeof(CONFIG_BT_DIS_HW_REV_STR));
#endif
#endif
	return 0;
} // settings_runtime_load

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Wed, 15 Feb 2023 06:09:22 GMT

I have a nRF9160-DK which has a nRF52480 chip on it and according to the documentation, one of its uarts is always routed to the board's virtual com port. I wanted to use it as my Central device while writing a PC program that would simulate our host for streaming the image. I could see the messages coming from the DK on my PC but nothing I sent arrived at the Central. I selected the nrf9160dk_nrf52840 Nordic board for this build. I guess something is wrong with my hardware, so I could not write and debug the host simulator.

I also have a nRF52840-DK which it nRF USB does not work (no recognition now on PC but previously had worked) so I could not also use it for the Central.

I can send you the sensor (peripheral) code in a private session in which I remarked the hardware stuff.

As for the current drain when compiled with V2.2.0 I will have to recheck the comparison, since I remember that management wanted to up the default tx power.

Currently I manipulate only the I2C & SPI interfaces. Our LC512 EEPROM is I2C and the LSM6DSL sensor is connected by SPI. I also use the ADC which is used only every 5 to 15 minutes which taking a vibration sample. I use the code below pm_device_action_run() & pm_device_busy_set() & pm_device_busy_clear()

//-----------------------------------------------------------------------------
// ami_boardPMActivate
//  Description
//    Changes the  I2C's or SPI's PM activate state 
//  Parameters
//   which
//   bActivate  -
//  Returns
//    true if OK
//-----------------------------------------------------------------------------
bool ami_boardPMActivate(unsigned char which,bool bActivate)
{
#ifdef CONFIG_PM_DEVICE
  int err = 1;
  enum pm_device_action action = bActivate?PM_DEVICE_ACTION_TURN_ON:PM_DEVICE_ACTION_TURN_OFF;
  switch (which){
    case AMI_BOARD_DEV_SPI1:
      err = pm_device_action_run((const struct device*)spi_dev,action);
      if (err!=-EALREADY && err!=-ENOTSUP){
          d_printf(LINE_INFO,kDbg_Error|kDbg_Display,"SPI state Err:%d",err);
      }
      break;
    case AMI_BOARD_DEV_I2C0:
      err = pm_device_action_run((const struct device*)i2c_dev,action);
      if (err!=-EALREADY && err!=-ENOTSUP){
          d_printf(LINE_INFO,kDbg_Error|kDbg_Display,"I2C state Err:%d",err);
      }
      break;
  } // switch
  return (err==0 || (err==-EALREADY));
#endif       
} // ami_boardPMActivate

//-----------------------------------------------------------------------------
// ami_boardChangeBusyState
//  Description
//    Changes the  I2C's or SPI's PM Busy state 
//  Parameters
//   which
//   bSetBusy  -
//  Returns
//-----------------------------------------------------------------------------
void ami_boardChangeBusyState(unsigned char which,bool bSetBusy)
{
#ifdef CONFIG_PM_DEVICE
  switch (which){
    case AMI_BOARD_DEV_SPI1:
      //-------------------------------------------------------------------
      // Mark a device as busy.
      // Devices marked as busy will not be suspended when the system goes into low-power states. 
      // This can be useful if, for example, the device is in the middle of a transaction.
      //-------------------------------------------------------------------
      if (bSetBusy){
        pm_device_busy_set(spi_dev);
      }else{
            pm_device_busy_clear(spi_dev);
      }
      break;
    case AMI_BOARD_DEV_I2C0:
      //-------------------------------------------------------------------
      // Mark a device as busy.
      // Devices marked as busy will not be suspended when the system goes into low-power states. 
      // This can be useful if, for example, the device is in the middle of a transaction.
      //-------------------------------------------------------------------
      if (bSetBusy){
        pm_device_busy_set(i2c_dev);
      }else{
            pm_device_busy_clear(i2c_dev);
      }
      break;
    case AMI_BOARD_DEV_GPIO0:
      if (bSetBusy){
        pm_device_busy_set(gpio_0_dev);
      }else{
            pm_device_busy_clear(gpio_0_dev);
      }
      break;
    case AMI_BOARD_DEV_GPIO1:
      if (bSetBusy){
        pm_device_busy_set(gpio_1_dev);
      }else{
            pm_device_busy_clear(gpio_1_dev);
      }
      break;
  } // switch
   
#endif
} // ami_boardChangeBusyState

After not really getting anywhere yesterday on the BLE DFU issue, this morning I had some interesting findings. It seems that the DFU upload reports OK but the code is NOT written anywhere, assuming that readcode reads the whole internal code flash.

1) Tool Chain V2.2.0 Update SDK
2) Erase board with programmer
3) Flash LastUpdate ={"14-Feb-2023 v1.0.0"}; merged file with programmer EraseAll Erase&Write
4) nrfjprog --family nRF52 --readcode code1.hex
5) DFU with gateway
	00> [ami_smp.c: 690] DFU:316800/319026
	00> [ami_smp.c: 690] DFU:317200/319026
	00> [ami_smp.c: 690] DFU:317600/319026
	00> [ami_smp.c: 690] DFU:318000/319026
	00> [ami_smp.c: 690] DFU:318400/319026
	00> [ami_smp.c: 690] DFU:318800/319026
	00> [ami_smp.c: 791] ImageChecksum AF3A0C7A
	00> [ami_smp.c: 917] SMP UploadOK
	00> [ami_smp.c:1198] ImageList
	00>
	00> -----------PRIMARY IMAGE-----------
	00>       slot: 0
	00>       version: 0.0.0
	00>       hash: 0xb34a6ec0abb87ccee95d838d9dbe4e5c33fae249c4ce955adc9a5297a8655d
	00>       bootable: true
	00>       pending: false
	00>       confirmed: true
	00>       active: true
	00>       permanent: false
	00>
	00> -----------SECONDARY IMAGE-----------
	00>       slot: 1
	00>       version: 0.0.0
	00>       hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
	00>       bootable: true
	00>       pending: false
	00>       confirmed: false
	00>       active: false
	00>       permanent: false
	00> [ami_smp.c:1201] ImageTest
	00>
	00> -----------PRIMARY IMAGE-----------
	00>       slot: 0
	00>       version: 0.0.0
	00>       hash: 0xb34a6ec0abb87ccee95d838d9dbe4e5c33fae249c4ce955adc9a5297a8655d
	00>       bootable: true
	00>       pending: false
	00>       confirmed: true
	00>       active: true
	00>       permanent: false
	00>
	00> -----------SECONDARY IMAGE-----------
	00>       slot: 1
	00>       version: 0.0.0
	00>       hash: 0x4165b6dabeb5dfab85e276b4e927b2e32358d38f1ef8d698617c5f449a095
	00>       bootable: true
	00>       pending: true
	00>       confirmed: false
	00>       active: false
	00>       permanent: false
	00> [ami_smp.c:1204] ImageReset
	00> 14/02/2023 19:17:31[ami_ble.c: 861] Disconnected: D4:FD:9F:BF:4A:27 (random) (reason 8)
	00> [ami_ble.c:2639] DFUConnectFinishedErr:0
6) nrfjprog --family nRF52 --readcode code2.hex
 code1.hex & code2.hex are exactly the same.
 This means that the SMP upload reported OK but did not write anything.
5) Phone Test only (which works)
 In the sensor code after reset, I confirm the image, so test is like confirm, if the code runs.
  //---------------------------------------------------------------------------
  // DFU upgraded and not confirmed, confirm
  //---------------------------------------------------------------------------
  if (!boot_is_img_confirmed()){
    err = boot_write_img_confirmed();
	  if (err) {
		  d_printf(LINE_INFO,kDbg_Error|kDbg_Display,"BootConfirmErr:%d",err);
    }else{
          d_printf(LINE_INFO,kDbg_Error|kDbg_Display,"BootConfirmed");
    }
  }
4) nrfjprog --family nRF52 --readcode code3.hex
  code3.hex is entirely different from code1.hex and code2.hex which were the same.

Thanks

David

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Mon, 13 Feb 2023 14:50:59 GMT

[quote user="DavidKaplan"]If I understand you wanted to try the upload, list, confirm(fails) & again list sequence?[/quote]

Yes.

[quote user="DavidKaplan"]Like I wrote I calculated a checksum on the data buffers sent with the bt_dfu_smp_command() function and verified it was correct.[/quote]

Thanks, it is nice to know this, for reference.

[quote user="DavidKaplan"]When I do a upload, list, test, reset sequence no problems are reported but the image is not updated after reset[/quote]

When doing "list", we can see that "pending: true". If an image is set as "pending", MCUboot should swap the image into the primary slot on reboot.
It is odd that MCUboot does not do so.

As I do not have your devices, I can not replicate this exactly.
However, it worked on nRF52840DKs for me.
Do you have 2x nRF52840DKs by chance? (Or other nordic developement kits?)
I am thinking that if you can try on the DKs VS you custom board, we can find if it is the hardware or the software which is the issue here.

[quote user="DavidKaplan"]Like I wrote I calculated a checksum on the data buffers sent with the bt_dfu_smp_command() function and verified it was correct.[/quote]

This reinforces my "this should work, why does it not?" thoughts.

[quote user="DavidKaplan"]

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?

[/quote]

Good thinking!

It is likely not app_update.bin itself, as the phone app works.

But maybe it is a difference to which address the application is uploaded to?
In that case, the "test" tag could maybe be in the wrong place for MCUboot to find it?

Can you try to see if there is any difference to the code if you upload it using a mobile and the SMP Client?
To get the image into secondary slot using mobile, upload it and "test only". Then restart twice to make it swap back into the secondary slot.

After reading out the code, can you try to list the mobile-uploaded image using the SMP Client?
Then also try to "confirm" the mobile-uploaded image using the SMP client?
That way we can learn if it is the "upload" or "test" that fails.

[quote user="DavidKaplan"]

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

[/quote]

I might ask you to open a new ticket on this.
But I want to give it a try first.
Do you have numbers on the current draw before and after?

Regards,
Sigurd Hellesvik

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Sun, 12 Feb 2023 07:45:10 GMT

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Fri, 10 Feb 2023 08:52:49 GMT

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

[quote user="DavidKaplan"]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?[/quote]

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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

DavidKaplan — Thu, 09 Feb 2023 13:40:09 GMT

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] [0m<inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group[0m
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
[1;31m--- 4 messages dropped ---
[0m[00:00:00.485,168] [0m<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                                      |....             [0m
[00:00:00.487,609] [0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)[0m
[00:00:00.487,640] [0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)[0m
[00:00:00.487,670] [0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098[0m
[00:00:00.488,098] [0m<inf> bt_[0m
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.036,804] [0m<inf> mcumgr_zephyr_grp: zephyr_basic_mgmt_init: Registering Zephyr basic mgmt group[0m
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
[1;31m--- 4 messages dropped ---
[0m[00:00:00.473,876] [0m<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                                      |....             [0m
[00:00:00.476,318] [0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)[0m
[00:00:00.476,348] [0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)[0m
[00:00:00.476,379] [0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 109.16784 Build 2917677098[0m
[00:00:00.476,806] [0m<inf> bt_hci_core: bt_init: No ID address. App must call settings_load()[0m
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] [1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name[0m
[00:00:00.478,057] [0m<inf> bt_hci_core: bt_dev_show_info: Identity: D4:FD:9F:BF:4A:27 (random)[0m
[00:00:00.478,088] [0m<inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x11fa, manufacturer 0x0059[0m
[00:00:00.478,118] [0m<inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0x11fa[0m
[00:00:00.478,363] [1;33m<wrn> bt_hci_core: bt_set_name: Unable to store name[0m
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] [1;31m<err> bt_gatt: db_hash_store: Failed to save Database Hash (err -2)[0m
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

RE: nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

Sigurd Hellesvik — Thu, 09 Feb 2023 09:28:52 GMT

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