This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU issues on Android 10

Hi,

We are currently testing DFU upgrades on Android. In my current setup I have two different phones, a Sony one running Android 8 and a OnePlus running Android 10.

The bootloader uses bonds and the application uses the buttonless DFU service.

Entering the bootloader and performing a DFU upgrade through the nRFConnect App on the Sony phone works fine. No failures there.

However on the OnePlus there are some issues. The first issue is that when trigger a DFU with the new FW zip file the nRF52832 enters the bootloader, the OnePlus connects again, but at reconnect it receives "GATT_INVALID_HANDLE", like it does not receive the GATT_SERVICE_CHANGED notification or that it receives it too late.

The second issue is that sometime the application cannot enter the bootloader from the buttonless DFU service, these are the logs from the application when I'm writing to the characteristic from the OnePlus:

<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation

Hardware: nRF52832 PCA10040

SDK: v15.0

Softdevice: v6.0.0

Edit: added screenshots from LOG

Parents Reply Children
  • Hi,

    Problem 1: This is the exact same issue. But remember that this needs to work both in the application and in the bootloader. Have you done anything with this issue in the bootloader?

    Problem 2: I see. Then I suggest you debug on the nRF side to see what happens before printing the "bootloader mode failed asynchronously" error message, as there are several issues that can lead to this being printed.

  • Hi,

    Problem 1: This is the exact same issue. But remember that this needs to work both in the application and in the bootloader. Have you done anything with this issue in the bootloader?

    - No I have not modified the bootloader source. I can try to debug it and see if It successfully sends Service Changed Notifications before I do any modifications. In general I dont like to modify SDK files since it becomes hard to keep track of the changes which could be dangerous in the long run, especially if I do the changes myself (perhaps poor solutions).

    Problem 2:

    I will try to debug it further on the nRF side

  • Update regarding problem 1:

    Logs indicate that the Service Changed notifications are working correctly in the bootloader:

    <debug> nrf_dfu_ble: Connected
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST.
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (27, max_rx_time 328).
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_PHY_UPDATE_REQUEST.
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_PHY_UPDATE (RX:2, TX:2, status:0)
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
    <debug> nrf_dfu_ble: max_conn_interval: 12
    <debug> nrf_dfu_ble: min_conn_interval: 12
    <debug> nrf_dfu_ble: slave_latency: 0
    <debug> nrf_dfu_ble: conn_sup_timeout: 600
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_SEC_INFO_REQUEST
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_SEC_UPDATE
    <debug> nrf_dfu_ble: Received BLE_GATTS_EVT_SYS_ATTR_MISSING
    <debug> nrf_dfu_ble: Sending Service Changed indication
    <debug> nrf_dfu_ble: Service changed notification returned err_code: 0
    <debug> nrf_dfu_ble: Finished handling conn sec update
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
    <debug> nrf_dfu_ble: max_conn_interval: 6
    <debug> nrf_dfu_ble: min_conn_interval: 6
    <debug> nrf_dfu_ble: slave_latency: 0
    <debug> nrf_dfu_ble: conn_sup_timeout: 500
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
    <debug> nrf_dfu_ble: max_conn_interval: 12
    <debug> nrf_dfu_ble: min_conn_interval: 12
    <debug> nrf_dfu_ble: slave_latency: 0
    <debug> nrf_dfu_ble: conn_sup_timeout: 600
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
    <debug> nrf_dfu_ble: max_conn_interval: 6
    <debug> nrf_dfu_ble: min_conn_interval: 6
    <debug> nrf_dfu_ble: slave_latency: 0
    <debug> nrf_dfu_ble: conn_sup_timeout: 500
    <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
    <debug> nrf_dfu_ble: max_conn_interval: 12
    <debug> nrf_dfu_ble: min_conn_interval: 12
    <debug> nrf_dfu_ble: slave_latency: 0
    <debug> nrf_dfu_ble: conn_sup_timeout: 600
    

    Edit:
    Another intresting observation. According to Google Play nRF Connect uses:

    - DFU Library 1.9.1 (improved DFU performance with devices based on SDK 15.x and 16)

    Using nRF Connect DFU I received GATT ERROR (0x85)

    Then I tried upgrading using nRF Toolbox which uses DFU Library 1.9.0 which went successfully without any issues.

  • Update on problem 2:

    <info> app: Retriving Peer data returned err_code: 0
    <info> app: Setting peer data for bootloader returned err_code: 8
    <error> app: Request to enter bootloader mode failed asynchroneously.
    

  • Hi,

    So I just finished a longer test session.

    It seems like the GATT Service changed notifications is not working properly in the bootloader.

    If I take these steps:

    1. In the application, write to the DFU characteristic to enter bootloader
    2. Enters bootloader
    3. Reconnect
    4. Still shows the attribute table from the application. Logs indicate that the Indication was sent successfully (returns NRF_SUCCESS inside nrf_dfu_ble.c)
    5. Disconnect and then reconnect. Now displays the DFU service/characteristic (Sometimes requires more than one disconnect/reconnect in order to display the new attribute table).
    6. Start FW upload

    With the above sequence DFU was successful 10 out of 10 tries.

    Automatic DFU from the application fails on either GATT_INVALID_HANDLE or GATT_ERROR which can be explained by the behavior above.

Related