DFU

RE: DFU

Vidar Berg — Wed, 16 Dec 2020 14:55:45 GMT

I'm not sure I understand the setup, is the received image meant for an external device? In that case, is the image transferred to the other chip by your application or by your bootloader? And is the problem that you can't clear the .bank_1 code after the update is complete?

RE: DFU

Mikael — Wed, 16 Dec 2020 09:46:25 GMT

yes understood the reason of hardfault.

What I don't understand is :

why the function invalidate is not sufficient ?

after loading zip file, bootloader call my app

then we do this :

ret_code_t ret_val = nrf_dfu_settings_init(false);
if (ret_val != NRF_SUCCESS)
{
    //return NRF_ERROR_INTERNAL;
    NRF_LOG_ERROR("Impossible d'init nrf_dfu_settings_init");
}
else
{
    NRF_LOG_DEBUG("s_dfu_settings bank 1 : 0x%02x", s_dfu_settings.bank_1.bank_code);
    if (s_dfu_settings.bank_1.bank_code == NRF_DFU_BANK_VALID_EXT_APP)
    {

else the s_dfu_settings.bank_1.bank_code is never valid.

but if I do this the s_dfu_settings.bank_1.bank_code is ALWAYS valide except if we wrote in MBR param.
just want to understand why i need to erase MBR param.

seems data are written by bootloader to inform data available but then restore at each reboot except if I wrote it back in MBR param

RE: DFU

Vidar Berg — Wed, 16 Dec 2020 09:34:41 GMT

The hardfault happens because the app is not intented to have access the backup page (i.e, MBR param page), see my first post to see which fields the it's permitted to change by default. But, if you want to give you give your app full write access, you can do so by disabling the flash protection in your bootloader as you already suggested.

RE: DFU

Mikael — Wed, 16 Dec 2020 08:14:11 GMT

yes I confirm my feeling.

hardfault arrive in nrf_dfu_settings_write_and_backup() because it try to erase at adress 0x7e000.

question : why?

RE: DFU

Mikael — Wed, 16 Dec 2020 07:57:56 GMT

one more things

in nrf_dfu_types.h i found this:

#elif defined( NRF52832_XXAA )
#define BOOTLOADER_SETTINGS_ADDRESS (0x0007F000UL)

and

#elif defined(NRF52832_XXAA)
#define NRF_MBR_PARAMS_PAGE_ADDRESS (0x0007E000UL)

so area_size = BOOTLOADER_SIZE + NRF_MBR_PARAMS_PAGE_SIZE

BOOTLOADER_SIZE = (NRF_MBR_PARAMS_PAGE_ADDRESS - BOOTLOADER_START_ADDR)

NRF_MBR_PARAMS_PAGE_ADDRESS = 0x7e000

BOOTLOADER_START_ADDR = 0x78000

so BOOTLOADER_SIZE = 0x6000

NRF_MBR_PARAMS_PAGE_SIZE = CODE_PAGE_SIZE

CODE_PAGE_SIZE = 1024 * sizeof( uint32) == 1000

area_size= 0x7000

so evrything should work fine as the MBR settings start at 0x7f000.

so why the nrf_dfu_settings_write_and_backup() function lead to hardfault handler ?

maybe it try to access something that is not in BOOTLOADER settings but in MBR params?

RE: DFU

Mikael — Wed, 16 Dec 2020 07:22:07 GMT

Hi Vidar,

maybe i found out why setting NRF_BL_DFU_ALLOW_UPDATE_FROM_APP is not enough in our case.

actually I look in details the bootloader and found this :

area_size = BOOTLOADER_SIZE + NRF_MBR_PARAMS_PAGE_SIZE;

    if (!NRF_BL_DFU_ALLOW_UPDATE_FROM_APP && !NRF_BL_DFU_ENTER_METHOD_BUTTONLESS && !NRF_DFU_TRANSPORT_BLE)
    {
        area_size += BOOTLOADER_SETTINGS_PAGE_SIZE;
    }

ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR, area_size);

in my case BOOTLOADER_SIZE is

#define BOOTLOADER_SIZE (NRF_MBR_PARAMS_PAGE_ADDRESS - BOOTLOADER_START_ADDR)

What I found is the following :

actually it BOOTLOADER_START_ADDR is 0x00078000 (in debug mode I look at nrf_bootloader_flash_protect() function)

area_size is 0x7000.

and so all the end of flash is then protected and then the bootloader settings as well.

Maybe we have miss something here.

Could you tell us more on this?

Thanks

RE: DFU

Mikael — Tue, 15 Dec 2020 15:20:15 GMT

in that case this part is not done :

nrf_dfu_settings_write_and_backup()

and the log message say this :

nrf_dfu_settings: Copying forbidden parts from backup page.
source, write not needed. Skipping.

and so after a power off/power on the binary is written again, but I don't want this.

Actually, what I want is the same behavior when my debugger is connected (the area can be written and all is fine)

actually the only way I found to have a correct behavior was this : comment the flash protect in the bootloader

//    ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR, area_size);

//    ret_val = nrf_bootloader_flash_protect(0,
//                    nrf_dfu_bank0_start_addr() + ALIGN_TO_PAGE(s_dfu_settings.bank_0.image_size));

RE: DFU

Vidar Berg — Tue, 15 Dec 2020 14:51:28 GMT

Yes, please try again with NRF_DFU_IN_APP set to 1 in the app. This is probably the reason for the hardfault.

RE: DFU

Mikael — Tue, 15 Dec 2020 14:49:30 GMT

yes it my app that call nrf_dfu_settings_write_and_backup() at the end of our slave chip doanloading

RE: DFU

Mikael — Tue, 15 Dec 2020 14:48:42 GMT

I will try this

NRF_BL_DFU_ALLOW_UPDATE_FROM_APP set to 1 in bootloader

and

NRF_DFU_IN_APP set to 1 in our app.

Is that correct?

RE: DFU

Mikael — Tue, 15 Dec 2020 14:45:52 GMT

sorry but I don't understand,

we use nordic bootloader for DFU.

then in our app we check if a new binary exist for our slave chip.

we load it in our chip and it is OK

then we always have hardfault handler on nrf_dfu_settings_write_and_backup()

even with NRF_BL_DFU_ALLOW_UPDATE_FROM_APP set to 1

please elaborate

Thanks

RE: DFU

Vidar Berg — Tue, 15 Dec 2020 14:43:19 GMT

Is it your main application that calls nrf_dfu_settings_write_and_backup(), and not the bootloader? In that case, make sure the app is compiled with the NRF_DFU_IN_APP flag enabled. This will prevent the nrf_dfu_settings module from attempting to erase the flash page protected by the BPROT — Block protection peripheral. And note that BPROT protection is automatically disabled in debug interface mode.

RE: DFU

Vidar Berg — Tue, 15 Dec 2020 12:18:57 GMT

Hello,

Looks like you are handling DFU in the application code? In that case, you may find this post relevant: https://devzone.nordicsemi.com/f/nordic-q-a/69006/custom-dfu-process. Our bootloader enables write protection on the MBR param page at 0x7E000 by defaullt ( With BPROT if 52832 is used), which could explain the hardfault.

RE: DFU

Mikael — Tue, 15 Dec 2020 08:47:11 GMT

static inline void wait_for_flash_ready(void)
{
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {;}
}