I'm wondering if this feature is still supported.
I'd like to update some devices from SD 5 to 7.1
I saw an old post and wanted fresh info.
If this is the same, I can
and that's still the solution ?
Thanks!
I notice the ZIP file name is exactly the same. Did the second command run actually create a new file?
It doesn't make sense that the ZIP package specifies both 0x9D and 0x101 as sd-req when you only pass just 0x9D.
Let's try something vastly different, 0x99 for sd-req, and 0x111 for sd-id?
That's coming from a makefile target, so the name is always the same (until version change).
So I did
|- Image #0:
|- Type: sd_bl
|- Image file: sd_bl.bin
|- Init packet file: sd_bl.dat
|
|- op_code: INIT
|- signature_type: ECDSA_P256_SHA256
|- signature (little-endian): b'ffdbd34b5b16c4194e1d38b64f48410ff4f72bef6d7de85b4938ac0a744b49eb2f71cca6f9d5fff3551c288602abfb86b943d4e78bc4f5bc0e309c3a1f7ff887'
|
|- fw_version: 0x0000277A (10106)
|- hw_version 0x00000034 (52)
|- sd_req: 0x99, 0x111
Right, then we are indeed sure that the tool combines sd-id into sd-req. On hindsight, that makes some sense.
I will have to reproduce this issue and investigate. I will keep you updated.
Thank you. This is the last big risk item on this project task. Any help is appreciated.
Hi ms360,
I was pulled into another assignment for a few days but have since returned and resumed looking into this.
I recreated a nRF5 SDK v14.2.0 and v17.1.0 setup, with bootloaders built in debug settings, printing out into UART.
The only difference is that I am using a nRF52840 DK instead of a nRF52 DK.
Currently, I am starting from a simpler case. The device is first flashed with only SDK v14.2.0 bootloader and SD, and I then attempt to update it with just the bootloader and SD from SDK v17.1.0.
With that setup, I have reproduced an issue, though I am not sure it is the same as yours. Refer to the log below:
<debug> app: Received calculate CRC <info> dfu_req_handling: Before OP crc <debug> app: Sending CRC: [0x60, 0x03, 0x01, 0:x000316AC, CRC:0xB6B733F5] <debug> nrf_dfu_flash: Flash write success: addr=0x00053600, pending 1 <debug> app: Received execute object <info> dfu_req_handling: Before OP execute <info> dfu_req_handling: Valid Data Execute <debug> nrf_dfu_settings: Writing settings... <debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000 <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 2 <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, len=0x1B8 bytes), queue usage: 3 <info> dfu_req_handling: Doing postvalidate <error> dfu_req_handling: Hash failure <info> dfu_req_handling: Current bank is bank 0 <info> dfu_req_handling: Running SD version check ============== <warning> dfu_req_handling: SD major version numbers mismatch. Current app will be invalidated.Current: 0. New: 7. <debug> nrf_dfu_settings: Writing settings... <debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000 <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 4 <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, len=0x1B8 bytes), queue usage: 5 <debug> app: Sending Response: [0x4, 0xB] <debug> nrf_dfu_flash: Flash write success: addr=0x00053680, pending 4 <debug> dfu_req_handling: Response sent. <debug> app: Received: BLE_GAP_EVT_CONN_PARAM_UPDATE <debug> app: conn_sup_timeout: 500 max_conn_interval: 6 min_conn_interval: 6 slave_latency 0 <debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 3 <debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 2 <debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 1 <debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0 <debug> nrf_dfu_flash: This operation had a callback, calling back to 0x000F3455. <debug> dfu_req_handling: All flash operations have completed. <debug> dfu_req_handling: Starting reset timer. <debug> dfu_req_handling: Attempting to reset the device. <debug> app: In nrf_dfu_transports_close <debug> app: num transports: 1 <debug> app: Shutting down BLE transport. <debug> app: Disconnecting. <debug> app: BLE transport shut down. <debug> app: After nrf_dfu_transports_init <debug> dfu_req_handling: Reset. <info> app: Inside main <debug> app: In nrf_bootloader_init <debug> app: in weak nrf_dfu_init_user <debug> app: In real nrf_dfu_init <debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false). <debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)... <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend. <debug> app: Initializing the clock. <debug> app: Enter nrf_dfu_continue <error> app: Single: Invalid bank <debug> app: Enter nrf_dfu_app_is_valid <debug> app: Return false in valid app check <debug> app: In nrf_dfu_transports_init <debug> app: num transports: 1 <debug> app: Initializing BLE DFU transport <debug> app: vector table: 0x000F1000 <debug> app: vector table: 0x000F1000 <debug> app: Error code - sd_softdevice_vector_table_base_set: 0x00000000 <debug> app: Enabling SoftDevice. <warning> nrf_sdh_ble: RAM starts at 0x200027E0, can be adjusted to 0x20002128. <warning> nrf_sdh_ble: RAM size can be adjusted to 0x3DED8. <debug> app: SoftDevice enabled. <debug> app: nrf_dfu_settings_adv_name_is_valid FALSE <debug> app: Regular adv name
It seems I have a hash failure for some inexplicable reason ...
There is also a SD version warning that also doesn't make sense. The mismatch major version is expected, and the "current version" print is also incorrect.
Do these look like the issue you are having?
On the nRF Connect app's end, there doesn't seem to be any error.
I will continue to look into this.
