Intermittent DFU Activity

I've been able to port the DFU process into a C# app running within a Linux gateway.

I'm using the buttonless without Bonds service to enter DFU mode.

The problem I have is that on many occasions after I have sent the command to enter DFU mode I'm not seeing the bootloader advertise so are unable to access its services and characteristics.

Within the bootloader I can see from our LED indicators that the NRF_DFU_EVT_TRANSPORT_ACTIVATED event has been raised, but using the nRF Connect app on my phone I can confirm there are no adverts from the bootloader DFU so it is not just my gateway that is not picking them up.

My gateway only attempts to upgrade one device at a time and is not performing any other connections / snooping at the time the enter DFU command is sent.

This is not specifically limited to a particular device, I have 10 set up and on my last test 6 upgraded (some required 2 or more attempts to get the adverts to start) and 4 did not connect.

Running the test again can change which devices respond and which do not.

I've never seen this when using the nRF toolbox app so suspect it may be how I'm handling the disconnect after sending the DFU command, but it works more often than not so must be very specific.

Can anyone suggest anything that may explain this behaviour or something I could try to increase the chances of the bootloader starting to advertise its DFU availability?

Thanks for any assistance you can provide

Parents
  • Thank you for clarifying the process.

    I think I have discovered the issue.

    It looks as is a previous download for a few of the devices has failed, and now when they connect the Select indicates this and no Create call is being made (which is the function in the bootloader that sends the NRF_DFU_EVT_DFU_STARTED event.

    On a good restart this means I only see the indicator for the NRF_DFU_EVT_TRANSPORT_ACTIVATED, but the process does continue correctly.

    However, when the CRC does not match the code I ported just exits and hence it sits for 2 minutes then times out.

    When a previous partial download CRC fails should I send an Abort or just send a Create (as if nothing had been started)?

    ie should it be:

        Select - Offset Not Zero but CRC's don't match

        Abort

        Select

        Create

        and so on

    Or just:

    Select - Offset Not Zero but CRC's don't match

        Create

        and so on

    Thanks.

  • Sorry for the confusion, I overlooked the fact that the LED indications are *not* reset after the Bluetooth connection has been terminated (i.e. on the NRF_DFU_EVT_TRANSPORT_DEACTIVATED event).

    Callback in main.c which controls the LED indication states (notice that there is no specific handling of the NRF_DFU_EVT_TRANSPORT_DEACTIVATED event triggered by BLE_GAP_EVT_DISCONNECTED):

    /**
     * @brief Function notifies certain events in DFU process.
     */
    static void dfu_observer(nrf_dfu_evt_type_t evt_type)
    {
        switch (evt_type)
        {
            case NRF_DFU_EVT_DFU_FAILED:
            case NRF_DFU_EVT_DFU_ABORTED:
            case NRF_DFU_EVT_DFU_INITIALIZED:
                bsp_board_init(BSP_INIT_LEDS);
                bsp_board_led_on(BSP_BOARD_LED_0);
                bsp_board_led_on(BSP_BOARD_LED_1);
                bsp_board_led_off(BSP_BOARD_LED_2);
                break;
            case NRF_DFU_EVT_TRANSPORT_ACTIVATED:
                bsp_board_led_off(BSP_BOARD_LED_1);
                bsp_board_led_on(BSP_BOARD_LED_2);
                break;
            case NRF_DFU_EVT_DFU_STARTED:
                break;
            default:
                break;
        }
    }

    When a previous partial download CRC fails should I send an Abort or just send a Create (as if nothing had been started)?

    There are three options:

    1. Start over again by resending the init command.

    2. Send the abort command. This will make the bootloader perform a system reset and exit DFU mode if a valid app is present.

    3. Continue DFU from where you left off previously. The CRC should match for the offset returned by the select command. If not you will have to start over again by re-sending the init command.

    Best regards,

    Vidar

Reply
  • Sorry for the confusion, I overlooked the fact that the LED indications are *not* reset after the Bluetooth connection has been terminated (i.e. on the NRF_DFU_EVT_TRANSPORT_DEACTIVATED event).

    Callback in main.c which controls the LED indication states (notice that there is no specific handling of the NRF_DFU_EVT_TRANSPORT_DEACTIVATED event triggered by BLE_GAP_EVT_DISCONNECTED):

    /**
     * @brief Function notifies certain events in DFU process.
     */
    static void dfu_observer(nrf_dfu_evt_type_t evt_type)
    {
        switch (evt_type)
        {
            case NRF_DFU_EVT_DFU_FAILED:
            case NRF_DFU_EVT_DFU_ABORTED:
            case NRF_DFU_EVT_DFU_INITIALIZED:
                bsp_board_init(BSP_INIT_LEDS);
                bsp_board_led_on(BSP_BOARD_LED_0);
                bsp_board_led_on(BSP_BOARD_LED_1);
                bsp_board_led_off(BSP_BOARD_LED_2);
                break;
            case NRF_DFU_EVT_TRANSPORT_ACTIVATED:
                bsp_board_led_off(BSP_BOARD_LED_1);
                bsp_board_led_on(BSP_BOARD_LED_2);
                break;
            case NRF_DFU_EVT_DFU_STARTED:
                break;
            default:
                break;
        }
    }

    When a previous partial download CRC fails should I send an Abort or just send a Create (as if nothing had been started)?

    There are three options:

    1. Start over again by resending the init command.

    2. Send the abort command. This will make the bootloader perform a system reset and exit DFU mode if a valid app is present.

    3. Continue DFU from where you left off previously. The CRC should match for the offset returned by the select command. If not you will have to start over again by re-sending the init command.

    Best regards,

    Vidar

Children
No Data
Related