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

[Jesper W.]

Hi 
I have been put into at task with a nrf52832 device (Mesh) that can only update the application.
This is a big problem because we already have multiple device all over the world and now want to update to  SDK 15.2 (softdevice 6.1.0) for use with latest Mesh version, new app and offcourse a new bootloader.
Because of this situation I have created application that embeds 3 part
1) MBR + Softdevice (6.1.0)
2) New bootloader + MBR + Settings
3) A copy program that is placed to just below the new bootloader address and runned after changing the UICR->NRFFW[0] pointing at my copy program and NVIC_SystemReset(). 

The first 2 part are taken from at running device with SDK 1.52 and bootloader, without any application. And it is offcourse verified to be able to update softdevice/Bootloader/application :-) 

I have used the Segger JLink command savebin to get the 2 part, convert from bin to c-array and finally embedded them into my application.

The new bootloader includes debug info, so the default address are changed and my memory map look like this:

UICR->NRFFW[1] (0x10001018) = 0x0007 E000 (Address of MBR parameter storage)
UICR->NRFFW[0] (0x10001014) = 0x0006 A000 & 0x0007 0000 (Address of Bootloader )

Bootloader settings                          0x0007 F000 - 0x0008 0000 (4 kB)
MBR parameter storage                  0x0007 E000 - 0x0007 F000 (4 kB)
Bootloader                                       0x0007 0000 - 0x0007 E000 
RECOVERY_COPY_APP               0x0006 A000 - 0x0007 6FFF
RECOVERY_INFO                          0x0006 9000 - 0x0006 9FFF

RECOVERY_MAIN_APP                0x0002 6000 - 0x0007 1000 

SoftDevice                                       0x0000 1000 - 0x0002 6000 (148 kB)
Master Boot Record (MBR)             0x0000 0000 - 0x0000 1000 (4 kB)

For the moment I can update the device with my recovery application and run RECOVERY_MAIN_APP and RECOVERY_COPY_APP where i change the UICR->NRFFW[0] before each NVIC_SystemReset(). The leftover from RECOVERY_MAIN_APP is also erased, so it is not recognized as an application.  

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). 

Any idea of what I'm doing wrong ? 

Additional questions:
1) Will the device go into DFU mode if the MBR and Settings data is erased with only MBR+SD+BL flashed ?
2) I have noticed that the MBR also contains default data/references to Bootloader address and MBR data as placed in the UICR->NRFFW[1] and UICR->NRFFW[0].
    Should I only be concerned about UICR->NRFFW[..] ?
3) Is there a way to jump directly into another application without doing the UICR->NRFFW[0] / NVIC_SystemReset() ?

Thanks :-) 

  

[AndreasF]

Hi.

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

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). 

 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

[Jesper W.]

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. 

[Jesper W.]

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>

[Edvin]

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

[Jesper W.]

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

[Edvin]

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