Workaround for bricked DFU over BLE that can only update application.

RE: Workaround for bricked DFU over BLE that can only update application.

Edvin — Fri, 03 May 2019 10:29:54 GMT

Hello Jesper,

I am glad you found the root of the issue, and I appreciate the feedback.

I will take this to our SDK team, so that they can consider the improvement.

Have a nice weekend 🙂

Best regards,

Edvin

RE: Workaround for bricked DFU over BLE that can only update application.

Jesper W. — Fri, 03 May 2019 07:50:07 GMT

Hi Edvin,

I have identified the problem and solved it.

It turns out that the validation during flash manager initialization caused an assert, where the validation wrongly identified flashmanager data as proper data.

The validation of flash manager metadata is VERY weak in sdk 15.2 .. and maybe you should improve ;-)

static inline bool metadata_is_valid(const flash_manager_metadata_t * p_metadata)
{
return (p_metadata->metadata_len != 0xFF &&
p_metadata->metadata_len >= 8 &&
p_metadata->page_index != 0xFF &&
p_metadata->pages_in_area != 0xFF);
}

My solution was to moved a temporary recovery-application located just below the bootloader (same area as used by flash-manager) to another location and erase the flashpages, before installing/running the application.

So the rule no 1 is to make sure that the flash area used by the flashmanager should initially be erased, because it can not verify it itself as valid flash data.

/Jesper

RE: Workaround for bricked DFU over BLE that can only update application.

Edvin — Thu, 02 May 2019 08:31:40 GMT

Hello 🙂

What SDK does your previous Bootloader and SD come from? And is there something in particular I need to know? Did you change anything in the previous bootloader? Or in this one?

I am asking because I would like to try to reproduce your issue, to see if I can figure out why it isn't starting up the bootloader.

Are you able to debug the bootloader? Or do you have logging enabled? Are you able to see a reason for why the application is not activated?

Just to get things right, you have updated the SD + bootloader, right? And it accepted the new application image? But it failed to start the application (at least it doesn't advertise, or behave like it does when you flash all the things at once, BL, SD, App, BL-settings?)

Do you have some way of enabling logging in the application that you are updating to? My suspicion is that the app is runnning, and it is getting caught in an APP_ERROR_CHECK(), since you don't see the BL advertisements. If you can update your application with the preprocessor define "DEBUG" and logging enabled, it should say whether it was caught in an APP_ERROR_CHECK or not.

Best regards,

Edvin

RE: Workaround for bricked DFU over BLE that can only update application.

Jesper W. — Wed, 01 May 2019 09:13:57 GMT

Hi Andreas,

As a follow up, I'll just confirm that the two upper sector (0x07e000 + 0x07f000) is not needed in order for the BL to enter DFU mode .. only the UICR values need to be correct pointing at BL and 0x07E00.

My next question comes when I try to transfer an application, onto the newly updated SoftDevice (15.2) & BL.
The DFU over BLE runs fine using nrfConnect (v2.6.2), but the application never starts up, even though the application is placed properly at 0x026000 as it should when using softdevice 6.1.0 (SDK 15.2 s132).

The Application DFU ZIP package is generated using nrfutil 4.0.0 and these settings:

nrfutil pkg generate --debug-mode --hw-version 52 --sd-req 0xAF --sd-id 0xAF --application application.hex --application-version 0x00 --key-file privkey.pem Dfu_App.zip

After the Application DFU ZIP update, then uicr and Settings looks like this.

J-Link>mem32 0x10001014 2
10001014 = 00072000 0007E000

J-Link>mem32 0x07f000 75
0007F000 = E410A579 00000001 00000000 00000000
0007F010 = 00000000 00000001 000252F4 BF9F02A1
0007F020 = 00000001 00000000 00000000 00000000
0007F030 = 00000000 00000000 00000000 00000000
0007F040 = 00000000 00000000 00026000 00000000
0007F050 = 00000000 00000000 00000000 FFFFFFFF
0007F060 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F070 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F080 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F090 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0B0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0C0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0D0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0E0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0F0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F100 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F110 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F120 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F130 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F140 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F150 = 00000000 00000000 00000000 FFFFFFFF
0007F160 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F170 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F180 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F190 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1B0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1C0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1D0 = FFFFFFFF

The 0x07E000 (backup) contains the same as sector 0x07F000.

It seem like the DFU task received the application and place it properly, updates the settings (0x7f000 and 0xf7e000), but can not activate the application properly ..
Any suggestions to solve this problem ?

BTW .. I have verified that the whole setup i working fine by flashing the merged hex file of (SD + BL + APP + generated settings).

The UICR and Settings looks like after flashing with the merged hex fil.

J-Link>mem32 0x10001014 2
10001014 = 00072000 0007E000
J-Link>mem32 0x07f000 75
0007F000 = 1C0C3778 00000001 00000000 00000002
0007F010 = 00000000 00000000 000252F4 BF9F02A1
0007F020 = 00000001 00000000 00000000 00000000
0007F030 = 00000000 00000000 00000000 00000000
0007F040 = 00000000 00000000 00000000 00000000
0007F050 = 00000000 00000000 00000000 FFFFFFFF
0007F060 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F070 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F080 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F090 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0B0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0C0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0D0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0E0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F0F0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F100 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F110 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F120 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F130 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F140 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F150 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F160 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F170 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F180 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F190 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1B0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1C0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0007F1D0 = FFFFFFFF
J-Link>

RE: Workaround for bricked DFU over BLE that can only update application.

Jesper W. — Wed, 17 Apr 2019 21:39:59 GMT

Hi Andreas,

I'm using 15.3 at another project and it works fine, but for this project/product I'm not allowed to upgrade yet, because we already have fully working, tested and certified application/bootloader based on 15.2.
So my task is to upgrade our bricked DFU devices to this level.

No .. the 'upgraded' device is not in dfu mode since I can not see it as an advertising device. I tested it on my Win10 laptop with USB dongle and android app using nrfConnect.

-----------------------------------

Ok .. In my next test I'll keep the MBR parameters + Setting data and UICR->NRFFW[1] erased and pointing the UICR->NRFFW[0] at the bootloader address.

Actually I think I have already tried that, but let's try it once again :-)

I will update you when tested.

RE: Workaround for bricked DFU over BLE that can only update application.

AndreasF — Wed, 17 Apr 2019 13:13:26 GMT

Hi.

First, can I ask why you don't just upgrade to 15.3 while you're at it? :-)

[quote user=""]Finally I ends up with a device that contains "exactly" the same as the running device with softdevice 6.1.0 and my new bootloader, but it is not running (going info DFU mode). [/quote]

I'm a bit unsure about what you mean here,

Does it end up in DFU mode?

Could you please explain some more?

___________________________________________

The additional questions you had:

1) Yes, although in later version (I think it is from 15.1, the MBR settings page works as a backup for the bootloader settings page)

2) You should only be concerned about the UICR values.

3) You could do the procedure the bootloader does when it starts the application?

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

Happy Easter!

Best regards,

Andreas