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
Thanks Hieu! Seems like we have a path forward.
Nonetheless, this presents us with a workaround: you could DFU BL+SD first, and then APP later. Is this acceptable?
I tried this a few weeks ago and got a similar failure. I will follow up with logs when I get a chance. It would be acceptable if this could work.
Another workaround would be to manually decode the .dat file in the package, edit the sd_req field for the BL+SD image, then re-encode it and repackage it.
This would also be acceptable as this would hopefully be a one time thing. Is it just a hex edit? do I need to change a checksum as well? Is it a manual re-encoding, then just a zip?
Here is the log from my BL+SD DFU test
[10:40:00.4790] Normal: Scanner On. [10:40:00.4890] Normal: Device Scanned. [10:40:03.7220] Normal: Connected. [10:40:04.1090] Normal: Discovered Secure DFU Service and Device Information Services. [10:40:04.2300] Normal: Discovered DFU Packet and DFU Control Point Characteristics for Service Secure DFU Service. [10:40:04.4130] Normal: Discovered Manufacturer Name String, Model Number String, Serial Number String, Hardware Revision String, Firmware Revision String, and Software Revision String Characteristics for Service Device Information. [10:40:04.4130] Normal: DFU Packet has no Descriptors. [10:40:04.4680] Normal: Discovered Client Characteristic Configuration Descriptors for Characteristic DFU Control Point [10:40:04.4700] Normal: Manufacturer Name String has no Descriptors. [10:40:04.4710] Normal: Model Number String has no Descriptors. [10:40:04.4720] Normal: Serial Number String has no Descriptors. [10:40:04.4730] Normal: Hardware Revision String has no Descriptors. [10:40:04.4740] Normal: Firmware Revision String has no Descriptors. [10:40:04.5260] Normal: Software Revision String has no Descriptors. [10:40:05.0660] Normal: Appearance changed from Generic to nRF5DFU. [10:40:23.2020] Normal: Found valid Firmware in file:///var/mobile/Containers/Data/Application/8E89727C-516F-413B-8C85-EADC3A302582/Library/Caches/LF_chc_bl_dfu_v1.01.06%20212EF5263-E990-4D5C-A3A7-A296D6CE1519-641-000003719B25824D.zip for Device DFU nRF5 SDK. [10:40:24.3470] Normal: Connecting to XmtF... [10:40:24.3480] Normal: Connected to XmtF [10:40:24.3480] Normal: Discovering services... [10:40:24.3480] Normal: Services discovered [10:40:24.3480] Normal: Starting Secure DFU... [10:40:24.3480] Normal: Connected to XmtF [10:40:24.3480] Normal: Services discovered [10:40:24.3480] Normal: Secure DFU Service found [10:40:24.3480] Normal: Discovering characteristics in DFU Service... [10:40:24.3480] Normal: DFU characteristics discovered [10:40:24.3480] Normal: Enabling notifications for 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.3870] Normal: Notifications enabled for 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.3870] Normal: Secure DFU Control Point notifications enabled [10:40:24.3870] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.4460] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.4470] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600601000100000000000000000000 [10:40:24.4470] Normal: Command object selected (Max size = 256, Offset = 0, CRC = 00000000) received [10:40:24.4470] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.5060] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.5070] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600101 [10:40:24.5070] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.5660] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.5670] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600201 [10:40:24.5670] Normal: Packet Receipt Notif disabled [10:40:24.5670] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5670] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5680] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5680] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5690] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5690] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5690] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5690] Normal: Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50... [10:40:24.5690] Normal: Command object sent (CRC = E524DC06) [10:40:24.5700] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.6850] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.6850] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 6003019800000006dc24e5 [10:40:24.6850] Normal: Checksum (Offset = 152, CRC = E524DC06) received [10:40:24.6850] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.7460] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.8650] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600405 [10:40:24.8650] Error: Error 5: Invalid object [10:40:24.8650] Normal: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50... [10:40:24.9250] Normal: Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50 [10:40:24.9270] Normal: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600c03 [10:40:24.9270] Error: Error 3: Invalid parameter [10:40:24.9270] Normal: Disconnecting... [10:40:24.9270] Normal: Disconnected [10:40:24.9290] Error: DFU Failed with Error: Invalid object [10:40:45.6900] Normal: Disconnected.
Right, after I got your response, I changed priority to verify the workaround by updating only SD + BL to v17.1.0 first. After a little blundering, I got things to work now, in this order:
Basically, the workaround is proven.
However, this also means I cannot reproduce the issue you are having.
Are you able to setup a test device with debug bootloader and see more information from within the bootloader?
I would have to build a debug bootloader from scratch on a v14.2.0 SDK.
The thing is I'm stuck with whatever this deployed version is, so if its not a mostly stock bootloader, I may run into some problems.
I'll reach out to the original engineer and see if I can get some more information.
Here is the v14.2.0 SDK bootloader project, with the nRF52832 Debug target that I have modified to start at 0x71000 (where the v17.1.0 debug-build bootloader starts) and log over UART. Perhaps that would help?
p01_bl-dbg_uart-addr_shifted.zip
As for the application, I think either yours or the ble_app_buttonless_dfu example would work. Perhaps your project would be better for reproduction?
Here is the v14.2.0 SDK bootloader project, with the nRF52832 Debug target that I have modified to start at 0x71000 (where the v17.1.0 debug-build bootloader starts) and log over UART. Perhaps that would help?
p01_bl-dbg_uart-addr_shifted.zip
As for the application, I think either yours or the ble_app_buttonless_dfu example would work. Perhaps your project would be better for reproduction?
My bootloader starts at 0x73000. I don't think this will work.
I'm happy to share my project privately off forum.
Huh, interesting. That is the default address of the bootloader with debug options and RTT logging enabled. Do you think your bootloader maybe already have logging?
In any cases, unless your application has some data between 0x71000 and 0x73000, the bootloader starting at 0x71000 shouldn't really matter.
If necessary, you can also change the start address back to 0x73000. It just means that we can't test with the debug version of the SDK v17.1.0 bootloader.
Here is the same project I edited to start at 0x73000.
As for sending over the application, that works too, as long as it can run on a nRF52840 DK. You can open a private case, with a link to this one, and ask it to be assigned to me.
I am out of office on Monday but will return on Tuesday.
