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
Thanks Hieu.
I'm running into "SD version check failed", I had to use nrf connect to get the verbose failure.
nrfutil pkg generate --hw-version 52 --app-boot-validation VALIDATE_ECDSA_P256_SHA256\
--sd-req "0x101","0x9D" --bootloader /Users/mike/p/_bootloader/bootloader_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 _binaries/chc_1.04.25_bl_v1.01.06.zip
Zip created at _binaries/chc_1.04.25_bl_v1.01.06.zip
Checking the SD version, I see 0x9d via nrfjprog.
mike@slavebox HC % nrfjprog --familly NRF52 --memrd 0x0000300C
0x0000300C: FFFF009D |....|
Checking the DFU package, I can see sd_req is right for the bootloader update
DFU Package: <_binaries/chc_1.04.25_bl_v1.01.06_2.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'fb3b9dab932a7c76ea11a660ca17c1eafad08fdb7f2474076853d656475167482f8e4eebb1618f8b496f72ea3177a27b05d18bb9d2ce41c084ae0c82a711ae4a'
|
|- 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
|
|- Image #1:
|- Type: application
|- Image file: chc.bin
|- Init packet file: chc.dat
|
|- op_code: INIT
|- signature_type: ECDSA_P256_SHA256
|- signature (little-endian): b'ed33c98ebce6b0c01e37173447eafcc8005c7cc46ae505ebe0815dd569200df76b8548968f2e8a6449157f901d28f711c5546eb7e38eda1cb2e7db3d735b5c5a'
|
|- fw_version: 0x000028B9 (10425)
|- hw_version 0x00000034 (52)
|- sd_req: 0x101
|- type: APPLICATION
|- sd_size: 0
|- bl_size: 0
|- app_size: 149528
|
|- hash_type: SHA256
|- hash (little-endian): b'b79dc4399b343a02ceed91ab51acf1e233ff2ec2295a3265f4d4b532e5e46810'
|
|- boot_validation_type: ['VALIDATE_ECDSA_P256_SHA256']
|- boot_validation_signature (little-endian): [b'fafa31fa1ffab0bd23b14bdd8a08a9bbc5b9ac4eb2b8ec10a4d70daacd8f164ebb44029b9f7bfb9d376709a352a5ac2e1e06eac7d78d949f7f3393dccb7fd208']
|
|- is_debug: False
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
