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

[AndreasF]

Hi David.

Your nrfutil command seems correct.

Can you create a bootloader settings page, and merge that with the bootloader?

Can you try to build a debug bootloader and post the log output here?

Best regards,

Andreas

[lynxemi]

Hi Andreas,

If I add the settings to the BootLoader, the DFU refuses to execute ... it just disconnects.

If I add a BL with debugging (to be uploaded), the DFU also refuses to execute ... it also just disconnects.

If I remove the settings and use the BL without debugging, it correcly executes (although the outcome is the same as before).

I have tested the BL with debugger by using nrfjprog to program and it works correctly.  However what we're trying to do is have the debugging version of the BL programmed by DFU over BLE, so we can see the logs when it fails and I don't seem to be able to get there.

I seem to be slightly stumped ... yet again.

Further thoughts?
David

[lynxemi]

Hi again Andreas,

Slightly finiky, but I recompiled the 14.2 BL and used a new version, and then managed to upload the BL and SD for 15.2, which failed similarly (same LED flashing), as well as being able to get some log data.

I will look as well to see what to make of it ... in the meantime, I'm not quite sure where things begin and end but this is the gist.

<00> info> app: Inside main
<00> debug> app: In nrf_bootloader_init
<00> debug> app: in weak nrf_dfu_init_user
<00> debug> app: In real nrf_dfu_init
<00> debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false).
<00> debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<00> debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<00> debug> app: Initializing the clock.
<00> debug> app: Enter nrf_dfu_continue
<00> debug> app: Valid SD + BL
<00> debug> app: Enter nrf_dfu_sd_bl_continue
<00> debug> app: Enter nrf_bootloader_dfu_sd_continue
<00> debug> app: SD already copied
<00> debug> app: Verifying BL: Addr: 0x000F3000, Src: 0x00046E7C, Len: 0x00005510
<00> debug> app: Bootloader not verified, copying: Src: 0x00046E7C, Len: 0x00005510
<00> info> app: Inside main

Cheers,
David

[AndreasF]

Hi David.

Could you paste the output you got in CMD when you created the settings page? And also the command you used.

And when you generate the packet, make sure that the "--bootloader-version" has a larger number then the one used in the settings page.

Please also post the command you use to create the packet.

Try the following test procedure:

1. You have created the key "keys/private.pem", use the command:

nrfutil keys display --key pk --format code <path to keys/private.pem>  --out_file dfu_public_key.c and use this key file to sign both bootloaders (the one for 14.2 and the one for 15.2)

2. Create the settings page for the App

nrfutil settings generate --family NRF52840 --application <app_name.hex> --application-version 3 --bootloader-version 1 --bl-settings-version 1 settings.hex

Merge this file with the bootloader for SDK 14.2 (mergehex -m <name_of_bl> settings.hex -o bl_sdk14_with_settings.hex

3.

Generate the packet:

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

4.

Flash the SDK 14 bootlader with the settingspage, and the S140 v5 SoftDevice.

5.

Do DFU from the other board to the board you

Can you try this?

Note: It is public holiday in Norway from 18 - 23 April, so I will be out of office those days.

Best regards,

Andreas

[lynxemi]

Hi Andreas,

I hope you had a wonderful Easter break. 

1. Yes, both bootloaders use the same private key.

2. Not sure why this should be needed, the 14.2 version already has a working BL and SD and is able to DFU the APP

3. I did this ... the only change appears to be the BL version

4. Yes ... I did this

5. Can apply the DFU, but I still get 

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

[Einar Thorsrud]

Hi David,

1. Good.

2. I think there has been a misunderstanding here. BL settings only need to be flashed originally (with the 14.2 bootloader). It should not be part of the DFU image.

3. The BL version ( --bootloader-version) need to increase when you make a new upgrade image (nrfutil pkg generate) compared to when you made the settings page which is flashed to the board (nrfutil settings generate). So if it was 1 when you generated the BL settings, then you should use 2.

4. Good.

5. That's odd. It should be OK to upgrade the SD + BL via DFU from 14.2 to 15.2, as Andreas explained in details in this post. Have you made any changes to the bootloaders compared to what is in the SDK? You should also make sure that you don't change the size of the bootloader, so for instance if you are upgrading from a non-debug bootloader, then you should not upgrade to a debug-bootlaoder.

[lynxemi]

Hi Einar,

2. I *think* we're on the same page?!  However, I'm certain that the original bootloader does not have the settings merged (and it worked). The APP also was able to be loaded by OTA DFU.  I will need to work with this as a reference as this is what is on the target device.  Is there an easy way to tell the BL version from the hex file?

3. This is understood... In the original scenario, there are no settings added to the bootloader. The bootloader seems to work fine, but there was no version associated with it so I am not sure what the BL version is for the original as I'm pretty certain it was never set.  However, version 1 or 2 on the new BL does not appear to work, so ?!?!

5. There are some minor GPIO setup changes in the BL that is in the target devices (14.2).  How are they supposed to be the same size when there is quite a significant restructure from 14.2 to 15.2?  However, the hex file sizes are ~62k (14.2) and ~61k (15.2) for the non-debug bootloaders.

6. I originally tried with both non-debug bootloaders (didn't work) then, replaced with the debug bootloader of 15.2 (the 14.2 version remained non-debug).  The behaviour was identical ... but I was at least able to get debug info as above. I am not sure that this helps ... 

I will try the distribution versions of the BL (debug and not) and see what happens, but I'd appreciate any feedback on the above.

[Einar Thorsrud]

Hi,

2. Yes, the bootloader will make a default settings page if it is empty. This is OK, the only problem is that it will not start the application until you program it via DFU, since it does not know that a valid application is present (that information is in the bootloader setting page).

3. The version field will be 0 if the default settings are used. You can verify this by reading out the bootloader settings page from your device. This does not matter though, as the bootloader will allow you to update to any version which is greater than the current version.

5. That is OK. I was not specific in my previous post. What I ment to say was that the bootloader cannot use more flash pages. That is, it cannot start at a lower address, and it cannot have grown so that it crosses over to the next flash page. In that case it will corrupt the MBR params page, which is the second last page. See memory layout for details. Could this be what is happening here? What is the exact sizes and start address of the old (14.2 based) and new (15.2 based) bootloader you are using?

6. I see.