Firmware upgrade OTA with BL+APP

[lynxemi]

We have a device with firmware based on 14.2 (with sd-id 0x96) and we're trying to do a DFU over BLE to a firmware base on 15.2 (with sd-id 0xAE).

We can do a firmware update using segger and install the SD, BL and APP (with settings) and have it run correctly.

We can create a package with all the components and using nRF Connect on Android upload the firmware (signed with the correct key). However, this process never runs ... we just land in a situation where LED2 (on the PCA10056) ends up flashing continuously.

Checking the sd-id with a memrd, gives us the correct SD (0xAE), but all the iterations I have tried have ended up in the same place including SD+BL (no APP).

[AndreasF]

Hi.

Can you please explain some more about the update process?

Do you create one packet with SD, BL, and APP? Or do you create two packets, one with SD + BL, and one packet with APP?

Can you please paste the nrfutil command that you used?

Best regards,

Andreas

[lynxemi]

Hi Andreas, thank you for your response.  In answer to your question and further explanation, I will try and elucidate.

I am testing this on the PCA10056.  I am able to flash the DK with SD v 5.0.0-2.alpha and a working Bootloader.

I have tried both with one packet (SD+BL+APP) and two packets (SD + BL) + (APP).  In both cases, after the first packet, the DK no longer advertises or responds. LED2 starts flashing vigorously, even after a hard reset.

The nrfutil command is

nrfutil pkg generate --key-file keys/private.pem --hw-version 52 --sd-req 0x96,0xAE --bootloader bootloader.hex --bootloader-version 1 --softdevice s140_nrf52_6.1.0_softdevice.hex --sd-id 0xAE DFU_package.zip

I have tested by loading the BL + SD (v 6.1.0) via nrfjprog and then using DFU to load the APP package and this works.  I am also able to load the APP via nrfjprog (with settings attached) which also works.

The main case that does not work, is loading the new (SD + BL) OTA with the old SD and BL installed.

I hope I have covered everything ... happy to fill in anything missing.

Cheers,
David

[Einar Thorsrud]

Hi David,

I see. If you see this repeating, then it is not the RTT problem I mentioned. Then it is the same bootloader starting all over again. This is odd as it should work out of the box without any such issues, and copying should always succeed (at least after a few attempts). Have you tested more than one device, or could there be a faulty device? Have you modified the bootloader in any way? If so, what have you done?

[lynxemi]

Hi Einar,

These are being tested with no modification to the SDK.  I did it with fresh installs of all and no changes other than dfu_public_key.c.

I have tested this on 2 x PCA10056 (0.9.0) with the same failure numerous times.  I also have tested it on one of our modules with the same outcome.

David

[lynxemi]

Adding to this ... I have subsequently added a couple of debugging lines to

int32_t nrf_dfu_mbr_copy_bl(uint32_t * p_src, uint32_t len)

...

NRF_LOG_DEBUG("About to send BL copy command"); // DKL

ret_val = sd_mbr_command(&command);

NRF_LOG_DEBUG("Do I get here"); // DKL

and the logs show

<debug> app: Bootloader not verified, copying: Src: 0x00046E7C, Len: 0x0000AF58

<debug> app: About to send BL copy command

<info> app: Inside main

[Einar Thorsrud]

Hi David,

I did not spot this earlier, but this is caused by the fact that you are trying to do to a bootloader upgrade with DFU from S140 from S140 5.0.0-2-alpha. This is an alpha SoftDevice which did not support upgrading the bootloader via DFU, as specified in the release notes under Limitations:

The SV-calls sd_mbr_command_vector_table_base_set() and sd_mbr_command_copy_bl() are not supported
(DRGN-8197). Using these calls leads to undefined behavior.

The specific problem is that the MBR write protects the bootloader flash region using ACL, and I do not believe there are any workarounds for this, other than using a debugger to flash a new SoftDevice.

This is not a problem when upgrading from S140 6.0.0, which was the first production ready (and qualified) SoftDevice for the nRF52840.

Einar

[lynxemi]

Thanks, Einar

I kind of suspected the conclusion was heading in this direction (although I did not notice the limitations in the release notes).  Thanks for finally identifying this as a definitive issue.

Cheers,
David