nrf_dfu_flash_* callbacks don't get called

RE: nrf_dfu_flash_* callbacks don't get called

Hung Bui — Tue, 21 Nov 2017 10:13:30 GMT

You should always check for the return code of the function, make sure it returns NRF_SUCCESS after you call it.

RE: nrf_dfu_flash_* callbacks don't get called

zolotiyeruki — Mon, 20 Nov 2017 22:09:43 GMT

Ok, I modified the code to the following, and now the handler runs:

void setSerialNumber(uint8_t const * const src){
    uint32_t * dest = (uint32_t *)FLASH_SERIAL_ADDR;
    nrf_dfu_flash_erase(dest, 1, serial_flash_callback);
}

So I'm back moving again. Unfortunately, calling nrf_dfu_flash_store() within the handler doesn't result in the handler being called again. Still digging into that one.

RE: nrf_dfu_flash_* callbacks don't get called

Hung Bui — Mon, 20 Nov 2017 13:57:09 GMT

Hi Zolo,

The BLE event and the flash operation callback event are both at "Softdevice API calls and non-time-critical processing" see here.

If you want to wait for the event, you should better wait at the main loop or at those priority level 5-6-7. You can use app scheduler to send the flash task to main context.

RE: nrf_dfu_flash_* callbacks don't get called

zolotiyeruki — Fri, 17 Nov 2017 18:30:42 GMT

The stack goes something like this:

setSerialNumber() 
called by ble_dis_on_evt() (modified ble_dis.c)
called by ble_evt_dispatch() (modified nrf_ble_dfu.c)
called by SoftDevice

So the softdevice generates a BLE event, and the handler for the BLE event attempts to write to flash, and is waiting for the SoftDevice to generate a system event (from the flash erase or write event completing).

How do I know what the relative priorities of the two are?

RE: nrf_dfu_flash_* callbacks don't get called

Hung Bui — Fri, 17 Nov 2017 16:13:19 GMT

Where do you call setSerialNumber() if you call that function from inside an event handler and then wait inside that event for the serial_flash_callback() to be called by same or lower priority level event, you may have to wait forever.