Older DFU application valid issue

RE: Older DFU application valid issue

John — Wed, 26 Oct 2016 12:08:57 GMT

Thanks Vidar! That confirms what I thought was happening.

RE: Older DFU application valid issue

Vidar Berg — Wed, 26 Oct 2016 10:24:19 GMT

Hi John,

you're right, the empty flash check is clearly a mistake, I didn't notice that. You can typecast it into a pointer and then deference it to make it work.

The SD will report NRF_EVT_FLASH_OPERATION_ERROR if it failed to complete a flash operation. In that case the bootloader will reset itself (error handler) instead of trying it again as it is not expected to ever time out during an update. I know there have been made some bugfixes on the pstorage module since SDK 5.2.0, and maybe the problem related to the pstorage module itself and not time out in the softdevice.

RE: Older DFU application valid issue

John — Tue, 25 Oct 2016 15:33:23 GMT

Hi Vidar,

Thanks for your response. Regarding the check for the empty flash mask, that is there but I think there is a problem with it. Doesn't the DFU_BANK_0_REGION_START need to be a pointer? Because there is no way 0x14000 is going to equal 0xFFFFFFFF. I'm still recovering from a nasty cold so forgive me if I got that wrong.

I was thinking the same thing on your second statement.

One last question: Can't the events that the stack sends up when flash operations complete return a result that is not NRF_SUCCESS? I believe I've seen that in the past and in this case it would trigger a reset in the middle of the bootload operation.

RE: Older DFU application valid issue

Vidar Berg — Tue, 25 Oct 2016 14:54:27 GMT

Hello,

bootloader_app_is_valid() checks whether the first word DFU_BANK_0_REGION_START is erased or not. So it shouldn't have started the application if BANK 0 was completely erased at least.

Do you have that check in your bootloader_app_is_valid() function?

// There exists an application in CODE region 1.
if (DFU_BANK_0_REGION_START == EMPTY_FLASH_MASK)
{
    return false;
}

That said, without CRC check you can't be 100% sure if the image was partially erased/stored. A reset/timeout during the swap could have caused the device to get bricked as you described. I think might be safer to update the boot settings before erasing as you suggested:

update_status.status_code = DFU_BANK_0_ERASED;

bootloader_dfu_update_process(update_status);     

// Erase BANK 0.
err_code = pstorage_raw_clear(&m_storage_handle_app, m_image_size);
APP_ERROR_CHECK(err_code);

Worst case is then that it will fall back into DFU mode rather than attempting to boot a non-existent application and cause a hardfault exception.

You could inject the CRC for bank 0 into the application valid.hex you have, use nrfjprog to write it manually after loading the merged .hex file, or initialize the m_boot_settings with the CRC and app valid flag in your bootloader code ( .bank_0 = BANK_VALID_APP and .bank_0_crc = CRC of app.bin) .