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
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?
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.
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.
