BLE DFU switching failure

[sebrenauld]

Hey,

We've been having issues with a subset of a batch of devices produced recently, with an unacceptably high failure rate when switching to DFU from firmware (the switch is done via BLE). This has worked until now, and I'm very puzzled as to how this could be happening, or steps to take to remedy. As it is ~10% of a batch of 300 devices, it is kind of a big deal. The bootloader is almost stock nrf, and the few modifications we made are not in this path.

The in-firmware switching code was a standard DFU assignment, it is temporarily like so to make sure the register is actually properly set:

    err_code = sd_power_gpregret_clr(0, 0xffffffff);
    APP_ERROR_CHECK(err_code);
    err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    APP_ERROR_CHECK(err_code);
    uint32_t reg_val = 0x00;
    while (!(reg_val & BOOTLOADER_DFU_START)) {
        sd_power_gpregret_get(0, &reg_val);
    }
    m_dfu.evt_handler(BLE_DFU_EVT_BOOTLOADER_ENTER);
    nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);

Following this, the device properly switches over to bootloader (we can see this), attempts to read the DFU register (seen by its entry into dfu_enter_check), and... hard-faults coming out of it and resets, thus going back into app mode since the register is RAM-backed.

What could be causing this? And, more importantly, is there another way to remedy this?

[Hung Bui]

Hi,

Could you clarify that the defected devices didn't crash in the application but it crashed in the bootloader ? 
Could you get the log from the bootloader when the hardfault happens ? 
Was the issue consistent ? If you reflash the board do you still see the issue ? If it's consistent on some devices, I would suggest to flash the bootloader with debug setting so that you can debug the bootloader and check why it crash. 

Something else you want to test is to not flash the application and let only the softdevice + bootloader run and check if you have the crash. 

[sebrenauld]

Hey!

First off, thank you for the reply :-)

The defected devices did not crash in the application, and crashed in the bootloader upon switching to DFU after setting GPREGRET; they then proceeded back to the app and "restarted".

Hung Bui said:

Could you get the log from the bootloader when the hardfault happens ? 

This is going to require some effort, but should not be impossible. We have a bit of an issue on that one in that the board as it is in production has SWO not available, so we'll have to rely on RTT logging. Not impossible, though.

Hung Bui said:

Was the issue consistent ? If you reflash the board do you still see the issue ? If it's consistent on some devices, I would suggest to flash the bootloader with debug setting so that you can debug the bootloader and check why it crash. 

The issue is consistent; the trackers we have tested exhibited the fault 100% of the time, irrespective of changes to the app side.

Hung Bui said:

Something else you want to test is to not flash the application and let only the softdevice + bootloader run and check if you have the crash. 

This is a good idea; I will see what I can do on that.