NRF52832 DFU s132 7.2.0 to s332 7.0.1

[Salmat]

Hi,

I am trying to migrate my device from s132 7.2.0 to s332 7.0.1, for adding ANT.
I have no more access to the SWD.

I know it is not tested :
docs.nordicsemi.com/.../lib_bootloader_dfu_validation.html
"Updating between different SoftDevice families"

As proposed, I commented :
// else if (SD_PRESENT && (SD_ID_GET(MBR_SIZE) != SD_ID_GET(sd_start_addr)))
// {
// NRF_LOG_ERROR("The new SoftDevice is of a different family than the present SoftDevice. Compatibility cannot be guaranteed.");
// result = false;
// }

And changed "is_major_softdevice_update" to respond true.
it is not 7=>7, but I thought it is even worse and it is used to : "Invalidating app because it is incompatible with the SoftDevice"

I have added RTT log to see what is going on.
I have made a pkg having : bootloader, s332, and working app with s332. (for testing : flashing with SWD on a simple kit works, it is running)

Log shows it is taking data from ble, and writhing in flash at 0x26000, about 215kb (seems to be s332 + bootloader ?)
But after I do not understand, it is copying the s332 :
<W> app: Copying 0x26000 to 0x1000, size: 0x2F000 (why 0x1000 ?)

But nothing after. It seems to be blocked.

I do not understand how it is supposed to work ? It is replacing the SD it is using. Or eaven less how bootloader update is done ? (ram execution ? I can not find any ...)
But it should be the same probleme while doing (a major) sdk update ? Or it is using only for BLE, not for flash copy ?

It seem to be possible :
devzone.nordicsemi.com/.../migrate-softdevice-from-s132-to-s332
"The first one update the SoftDevice. If your bootloader depends on the SoftDevice, this update also need to include a new bootloader."
"After that update, the application is invalidated. The bootloader will enter DFU mode waiting for the application update, which will be the second update."

Thank you in advance for any help.

[Salmat]

I have find why it did not work !

nrfjprog --memrd 0x000FF8 --n 4

showed me the MBR pointed at the wrong place for bootloader !
Because of activating LOGs for debug, I changed the start add for the bootloader (to increase it size)

So I disactivated LOGs to have the same add as the pkg for the bootloader, and it works !
I think there is missing test to verify the bootloader has not changed of address ? It could have even if the same SDK, the same App ...

Or maybe it is documented someware ?

I will wait for a Nordic response regarding the bootloader address change.

[Turbo J]

I don't think its spelled out explicitly, but if you look at how the bootloader is supposed to work its very clear that you can't change the address via an update - you need to flash with debugger for that.

[Vidar Berg]

Good to hear you found the problem! Changing the bootloader address is not possible through DFU. it can only be done when programming the device through the debug interface. One thing to note however is that both 0xFF8 and 0xFFC are populated at runtime by the bootloader during the initial boot with the UICR register values at 0x10001014 and 0x10001018.  As a result, it’s possible to reprogram the device with another bootloader at a different start address and end up with the value at 0xFF8 not being updated.