Secure Bootloader example does not work with Android nRF apps

[kcl74]

I'm following the secure bootloader examples for nRF5 SDK 16.0.0 with my nRF52840 DK, with Segger Embedded Studio on Win 10 x64.  Android Phone used is Samsung Galaxy Note 10+ 5G, running Android 11.

1. Open "secure_bootloader_ble_s140_pca10056_debug" project, build, and load to target (includes SoftDevice).  No changes made to project/source.
2. Use nRF Connect or nRF Toolbox to attempt DFU, loading "hrs_application_s140.zip" package provided in the secure_dfu_test_images example directory

On Android, I eventually get a GATT ERROR. In the Debug Terminal, I see:

<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x000F1000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_ble: BLE DFU transport initialized.
<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
<debug> app: Enter main loop
<debug> nrf_dfu_ble: Connected
<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
<debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 517, reply: 247).
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST.
<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (251, max_rx_time 2120).

After the GATT ERROR, the Android is disconnected.  LED1 and LED3 on the DK continue to stay lit.  Confirmed the DK continues to advertise.

In the Debug Terminal window, after GATT ERROR is received, this is printed:

<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

I tried changing MTU size and GAP length in sdk_config.h but that didn't change the behavior with Android.

Doing the same thing with iOS 14.6 iPad Pro, running nRF Toolbox, everything works fine--update completes and HRS utility in nRF Toolbox connects to DK and displays information.

Any idea what the issue might be?  Is it related to the chip not supporting prepared/queued/long writes?  How can that be fixed/addressed?

[Vidar Berg]

Hello,

If you haven't done it already, please try perform a reboot of your phone before you start DFU. This just to rule out any potential issues related to caching (https://github.com/NordicSemiconductor/Android-DFU-Library/issues/74 ).

The debug log from the bootloader is not providing much clues as to why the connection is termintated I'm afraid. A sniffer trace would likely be more helpful in this case. Do you have access to a Bluetooth sniffer you can use (e.g. nRF Sniffer for Bluetooth LE) to get one that shows when DFU fails?

I tried changing MTU size and GAP length in sdk_config.h but that didn't change the behavior with Android.

 I would recommend reverting this, at least for now. Too long event length may cause scheduling of flash operations to fail (if overall throughput is too fast for flash writes to keep up)

Is it related to the chip not supporting prepared/queued/long writes? 

 This could be an explanation, but I don't see why the phone would attempt this. How long does it take for the phone to report the disconnect, instantly, or more like 30 seconds?

[kcl74]

I attempted again today, after a phone reset and everything works with the Android 11 phone.  Ellysis BLE sniff looks good other than a few Out Of Sync packets and some ATT Unknown Packets.

Could you clarify what might be happening in regards to caching?  Is there a software fix for this, i.e. could something be done in the phone app or the firmware to resolve these issues so that a phone restart would not be required?  I am asking in the event we run into this issue when trying to perform DFU when using our own app.  I would like to avoid having a customer call customer support just for us to tell them to restart their phone--instead, if failure occurs, our app would try to proactively attempt to resolve the issue and try again.

Thank you for the prompt response!

[Vidar Berg]

Thanks for the update. The bootloader increments the BLE address by '1' to avoid exactly this issue, so I'm actually a bit surprised it turned out to be a caching issue (Buttonless Secure DFU Service without bonds). Or are you doing buttonless DFU with bonds?

kcl74 said:

I would like to avoid having a customer call customer support just for us to tell them to restart their phone--instead, if failure occurs, our app would try to proactively attempt to resolve the issue and try again.

 This would obviously not be good for the user experience. Even though it shouldn't be needed you may consider enabling the NRF_SDH_BLE_SERVICE_CHANGED characteristic as an extra safety measure to prevent the phone from caching the attribute table. The presence of the Service changed characteristic (when not bonded) makes it so that the GATT client is not allowed to cache services across connections. If you want to read more about this, you may refer to vol.3 , part G, section 2.5.2 of the Bluetooth core specification. It gives a good summary of the different caching rules that the phone has to adhere to.