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!
Hi ms360,
From the SoftDevice version number, it looks like you are trying to upgrade from nRF5 SDK v14.x.0 to v16.0.0, is that correct?
If there are some changes between that are highly desirable for your project, I will not stop you. However, please keep in mind that every bootloader update comes with a risk of the device being bricked.
Regarding updated info, the thread you cited is from late August 2020, dealing with nRF5 SDK v17.0.0, so the information there should actually be as fresh as it gets with the nRF5 SDK. Please remember that the nRF5 SDK hasn't been worked on for more than 4 years now.
I checked v14.2.0 update solution and that of v16.0.0, and the design seems to remain the same between them. You would just need to make sure that the Bootloader start address doesn't change, because there is no way to change that.
There is a change in the bootloader settings format. Bootloaders from nRF5 SDK v15.2.0 and earlier use bootloader settings version 1, while those from v15.3.0 and later only support bootloader settings version 2. You will need to enable backward compatibility for the old settings version.
Another thing to check is to make sure the new application is compatible with the old application's persistent data. You can check this by flashing without erase the SoftDevice, bootloader, and application individually on a device running the old setup, with existing data. A device from the field would be best. A test device running the hex dump from a device from the field should be equally good. An entirely new test device should also work.
Finally, I didn't know updating BL + SD + App all at once was possible. However, if that is too big to do, you can update BL + SD first, then application, as mentioned in the documents linked above.
I hope that helps.
Hieu
Sorry I meant I'd like to upgrade to SD v7.2.0. I'm using SDK 17.1.0
Sorry I meant I'd like to upgrade to SD v7.2.0. I'm using SDK 17.1.0
I can't think of a reason why you would meet SD version check failed like this...
Can you retry with only 0x9D for --sd-req?
So this was unexpected, just specifying 0x9d yielded the same result!
As if it concatenates --sd-req and --sd-id
DFU failed again.
nrfutil pkg generate --hw-version 52 --app-boot-validation VALIDATE_ECDSA_P256_SHA256\
--sd-req 0x009D --bootloader _bootloader/bootloader_chc_v1.01.06.hex --bootloader-version 10106 \
--application _build/chc.hex --application-version 10425\
--key-file private.key --softdevice ../nRF5_SDK_17.1.0_ddde560-mirror/components/softdevice/s132/hex/s132_nrf52_7.2.0_softdevice.hex\
--sd-id 0x101 1.04.25_bl_v1.01.06.zip
|- Image count: 2
|
|- 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'01cbe4315a1a1f0dcda1b5f400de6c9213496ee29b576bf0ad1221c80651cccd1575fe9d2a1b8efe0eee18cfae6f456a75233741f46039419dccd907f906cbbe'
|
|- fw_version: 0x0000277A (10106)
|- hw_version 0x00000034 (52)
|- sd_req: 0x101, 0x9D
|- type: SOFTDEVICE_BOOTLOADER
|- sd_size: 149868
|- bl_size: 23644
|- app_size: 0
|
|- hash_type: SHA256
|- hash (little-endian): b'ed4b49e552fe7d411a49c3e1a0ba7c82254515e2d5eaaa9b46e370dadd0052ec'
|
|- boot_validation_type: ['VALIDATE_GENERATED_CRC', 'VALIDATE_GENERATED_CRC']
|- boot_validation_signature (little-endian): [b'', b'']
|
|- is_debug: False
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.
