MBR params gets corrupted after updating softdevice+bootloader+application

[mk2]

Hi,

I have an issue with OTA DFU stop working after updating softdevice_bootloader through OTA DFU, and the problem seems to be in the MBR params page.

The scenario is, first I have:

nrf52832

SDK: 15.2

SD: s132 v6.1.0

Then I update it through secure buttonless DFU with new SD, bootloader and application to:

SDK: 16.0

SD: s132 v7.0.1

The application runs fine after the update, but if I try to update the fw again through DFU, it jumps into the bootloader but immediately returns back to application again.

However, if the new SD (v7.0.1), bootloader and application is flashed into the device through JTAG from begginning, I don´t face this issue. I can update the application as many times as I want.

I have also compared the hex files, and if I overwrite the MBR params when it doesn´t work with the MBR params from when it works, the application update runs fine. So it seems like MBR params get corrupted when updating softdevice_bootloader. Do you have any idea why it becomes corrupted and how to avoid this?

I have attached hex files of the MBR segment when it´s working well and not working (the bootloader jumps immediately to back to application).good_mbr_segment.hexbad_mbr_segment.hex

[Vidar Berg]

Hello,

Is the bootloader settings page at 0x7F000 the same after you program the new FW with the programmer as it is after DFU from the previous version? I don't belive what you are seeing is a known issue at least.

Best regards,

Vidar

[mk2]

Hi,

No the bootloader settings page is not the same, it differs also. But the symptom gets cured by just swapping the MBR params page.

I will upload the bootloader settings page hex files too, in case it´s interesting.good_btl_settings_segment.hexbad_btl_settings_segment.hex

[Vidar Berg]

Hi,

The bootloader settings may get reset to the default values if you re-program the param page as the param page is used to backup the settings page. The settings page may explain why subsequent updates get rejected.

It's a bit hard to read the settings directly from the hex files you posted. Would you mind parsing it with nrfutil?

Steps to inspect BT settings with nrfutil:

1. Load current flash content to a hex file with nrfjprog : nrfjprog --readcode flash_content.hex

2. nrfutil settings display flash_content.hex

[mk2]

Ah, that was a convenient tool (the nrfutil settings display).

I am attaching the screenshots of those readings.

It seems like the settings version is 1 instead of 2, and boot validation crc is missing in the instance that is not working.

Not working (after the DFU update of SD):

Working (when programmed with SD v7 from beginning):

[Vidar Berg]

Hello,

I did not encounter any problems when now when did a full upgrade from SDK 15.2.0 to SDK 16.0.0 with the debug bootloader and and buttonless template app just now. Files I used for this test are attached below if you want to compare with your settings.

mk2 said:

It seems like the settings version is 1 instead of 2, and boot validation crc is missing in the instance that is not working.

nrfutil displays the settings as if it followed the Settings version 2 format. CRC boot validation of app is always enabled in 15.2.0 bootloader.

mk2 said:

Not working (after the DFU update of SD):

 Seems like the bootloader settings version should have been updated. Did you not update SD+bootloader?

Attachment:

dfu_15_2_16_0.zip

[mk2]

Vidar Berg said:

nrfutil displays the settings as if it followed the Settings version 2 format. CRC boot validation of app is always enabled in 15.2.0 bootloader.

I´m not really following, how do you mean? Do you mean that it´s not displaying the boot validation CRC even though it exists because it´s parsing Settings version 1 in Settings version 2 format?

Vidar Berg said:

 Seems like the bootloader settings version should have been updated. Did you not update SD+bootloader?

I did update SD+bootlader, otherwise I´m pretty sure the application wouldn´t run right? Specially not after updating application again after swapping the MBR params like I explained before.

I will compare the settings you attached and do some more experiments.

[Vidar Berg]

mk2 said:

I´m not really following, how do you mean? Do you mean that it´s not displaying the boot validation CRC even though it exists because it´s parsing Settings version 1 in Settings version 2 format?

 Yes, correct. nrfutil v6 assumes the setting format corresponds to version 2 instead of checking the actual settings version number.

Here's the difference between version 1 and 2:

 

mk2 said:

I did update SD+bootlader, otherwise I´m pretty sure the application wouldn´t run right?

Yes, the bootloader update is required when you do a major Softdevice update. It's just that I would have expected the settings version number to be set to 2 after having updated to the new bootloader.

[mk2]

I found the root cause. We missed updating the NRF_DFU_SETTINGS_VERSION macro from 1 to 2 in the makefile for the bootloader project (although it was updated to 2 in SES). Fixing that solved the issue.

Thanks for your help! It guided us to the right direction.

[Vidar Berg]

Good catch! I appreciate the update the update. I should have realized what the problem was before when you said that the settings version remained at 1 after the update.