What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

Hung Bui — Tue, 19 May 2020 16:05:07 GMT

NRF_DFU_IN_APP is not supposed to be used with the bootloader. You define this when you want to use the bootloader modules, foe example dfu_settings.c in your application.

Doing background DFU requires you to have a deep understanding of how the bootloader and the DFU process works, before you start integrate background DFU into your application. I would suggest to study the bootloader as much as possible.

We do have an example for doing background DFU, please have a look at this thread: https://devzone.nordicsemi.com/f/nordic-q-a/46994/background-dfu-application-source-code

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

attila-v — Mon, 18 May 2020 09:36:46 GMT

hi,

I had a little time to deal with this issue.

Main experience is, that if I set NRF_DFU_IN_APP to 1, the ble-dfu-secure bootloader could not start, it stops at the beginning. There is no such problem with iot-secure bootloader.

so while I need the possibility of the ble-dfu too, is there any other settings in the sdk_config.h, which I must to set for the good working?

regards, Attila

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

Hung Bui — Thu, 16 Apr 2020 13:19:02 GMT

There a similar case here that you may want to have a look: https://devzone.nordicsemi.com/f/nordic-q-a/52594/how-to-update-software-using-the-bootloader

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

attila-v — Thu, 16 Apr 2020 12:30:01 GMT

thank you for your quick answer!

yes, my aim is to do the DFU form application, so I will check and try your suggestion.

regards, Attila

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

Hung Bui — Thu, 16 Apr 2020 10:12:06 GMT

Please be aware that the NRF_MBR_PARAMS_PAGE_ADDRESS (0x7E000) is not the MBR itself. It's the page that stores the MBR settings (and bootloader_setting backup). It's located on top of the bootloader.

My understanding is that you are doing DFU from application, and the bootloader only does the swapping part ?

I don't think you would need to write to the MBR_PARAMS_PAGE in that case. But you need to define NRF_DFU_IN_APP in the bootloader.

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

attila-v — Thu, 16 Apr 2020 06:42:12 GMT

Hi,

you can see my problem here: https://devzone.nordicsemi.com/f/nordic-q-a/59594/what-is-the-right-way-of-the-dfu

OK, it's solved, but I'm confused about MBR. As you can see in the topic, I modified the 'MBR params page / BL settings backup' only, not the real MBR. My question refers to it.

RE: What is the main reason that the MBR (0x7E) page is being to protected mode when the bootloader starts?

Hung Bui — Wed, 15 Apr 2020 13:21:15 GMT

Hi Attila,
It's part of the Secure Boot sequence. You can read about that here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_secure_boot.html?cp=7_1_3_5_0_8

It's is to avoid malfunction/glitch or hacking of the application can cause any damage to the MBR hence brick the device.

Could you give more information why you need to modify the MBR when doing DFU update ?