Buttonless OTA DFU stops after switching to bootloader

[roland.schenk]

Hi,

I'm evaluating the nRF5_SDK_v15.0.0 buttonless example OTA DFU bootloaders on a nRF52840-PDK.

The buttonless examples are working well. So I integrated the buttonless service into my own application.

The change from my appliction to the bootloader is working. Then the bootloader stays in the DFU mode, but the download doesn't start and a timeout error is rised.

I'm using a secure bootloader, wthout bonding and the peer manager is not integrated in my application.

What could be the reason of braeking the connection, while changeing from the application to the bootloader?

Best regards

Roland

[Edvin]

Hello,

You may be aware of this, but the application should reset after entering bootloader mode, and start advertising as DfuTarg, so there will be a disconnect and a reconnect, but that is also the case for the buttonless example, so there is no reason it shouldn't work in your application.

 

Do you use nRF Connect to upload your firmware? Do you get any information from the log there? What happens after the disconnect? Does it return to application, or does it stay in bootloader mode?

 

Best regards,

Edvin

[roland.schenk]

Hello,

I have integrated the peer manager in my application and now I am using the buttonless DFU service with bonding.

I use PC nRF Connect to upload the firmware. The pairing / bonding is working fine. But after switching to the bootloader the connection stops and the bootloader rises a timeout error after some seconds. Then the bootloader is advertising as DfuTarg.

I have added a logfile from nRF Connect and a logfile from the J-Link RTT connected to the targed running the application.

What could be the reason of braeking the connection, after changeing from the application to the bootloader?

nrfconnect_log_my_app.txt

Fullscreen rtt_log_my_app.txt Download

<info> app: ***** Main ******************************************
<info> pwr_mgmt: Init
<info> app: In buttonless_dfu_sdh_state_observer.
<info> app: In buttonless_dfu_sdh_state_observer.
<info> app: BT Address: EC:2A:F0:F0:F0:DB
<debug> app: AddService: uuid 0x10
<debug> app: AddCtic: uuid 0x11 handle 0x400
<debug> app: AddCtic: uuid 0x12 handle 0x400
<debug> app: AddCtic: uuid 0x13 handle 0x400
<debug> app: AddService: uuid 0x20
<debug> app: AddCtic: uuid 0x21 handle 0x400
<debug> app: AddCtic: uuid 0x22 handle 0x400
<debug> app: AddCtic: uuid 0x23 handle 0x400
<info> app: Setting vector table to bootloader: 0x000F1000
<debug> app: nrf_dfu_svci_vector_table_set() -> success
<debug> app: nrf_dfu_set_peer_data_init() -> success
<info> app: Setting vector table to main app: 0x00026000
<debug> app: nrf_dfu_svci_vector_table_unset() -> success
<info> app: start advertising
<info> app: SYS::vHandlePenPresenceUpdate 0
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connected
<info> app: SYS::vHandleBleConnectionUpdate 1
<debug> nrf_ble_gatt: ATT MTU updated to 23 bytes on connection 0x0 (response).
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7 length 0xFB
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<debug> nrf_ble_gatt: max_rx_time: 328
<debug> nrf_ble_gatt: max_tx_time: 328
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7 length 0xFB
<info> app: BLD::PeerEvt 1
<info> app: BLD::PeerEvt 5
<info> app: BLD::PeerEvt 2
<info> app: Connection secured: role: 1, conn_handle: 0x0, procedure: 1.
<info> app: BLD::PeerEvt 8
<info> app: BLD::PeerEvt 8
<info> app: BLD::PeerEvt 14
<debug> app: RW type: 0x1 handle 0x16 uuid 0x11
<debug> app: RW type: 0x1 handle 0x19 uuid 0x12
<debug> app: RW type: 0x1 handle 0x1C uuid 0x13
<debug> app: RW type: 0x1 handle 0x1F uuid 0x21
<debug> app: RW type: 0x1 handle 0x22 uuid 0x22
<debug> app: RW type: 0x1 handle 0x25 uuid 0x23
<info> app: Received indication state 1
<debug> app: BLE_GATTS_EVT_WRITE
<info> app: BLD::PeerEvt 8
<info> app: Writing peer data to the bootloader...
<debug> app: system attribute table len: 8
<debug> app: sd_ble_gatts_sys_attr_get: 0
<info> app: retrieve_peer_data: 0
<info> app: nrf_dfu_set_peer_data: 0
<debug> app: Enter bootloader return code: 0
<debug> app: RW type: 0x2 handle 0x31 uuid 0x4
<debug> app: Peer data was successfully forwarded to the Secure DFU bootloader.
<debug> app: In ble_dfu_buttonless_bootloader_start_prepare
<info> app: In ble_dfu_evt_handler.
<info> app: Device is preparing to enter bootloader mode.
<debug> app: Disconnected peer
<info> app: BLD::PeerEvt 8
<debug> app: Updating Service Changed indication for peers, 0 left

[Edvin]

Hello,

Do you do anything special with the device address? Have you changed it in the buttonless application?

Have you changed the define in sdk_config.h in the bootloader project, called: NRF_DFU_BLE_REQUIRES_BONDS to 1?

 

Best regards,

Edvin

[roland.schenk]

Hello,

In the bootloader  NRF_DFU_BLE_REQUIRES_BONDS and NRF_SDH_BLE_SERVICE_CHANGED are  set to 1.

The device address is set once at he startup of the application:

void BLC_vSetBtAddress(uint32_t u32SerialNumber)
{
    ble_gap_addr_t m_bt_addr = BT_BASE_ADDRESS;
    m_bt_addr.addr_type     = BLE_GAP_ADDR_TYPE_PUBLIC;
    m_bt_addr.addr[0] = u32SerialNumber & 0xFF;
    m_bt_addr.addr[1] = (u32SerialNumber >> 8) & 0xFF;
    ret_code_t err_code = sd_ble_gap_addr_set(&m_bt_addr);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_INFO("BT Address: %02x:%02x:%02x:%02x:%02x:%02x", m_bt_addr.addr[5],m_bt_addr.addr[4], m_bt_addr.addr[3], m_bt_addr.addr[2],m_bt_addr.addr[1], m_bt_addr.addr[0]);
}

<info> app: BT Address: EC:2A:F0:F0:F0:DB

Best regards,

Roland

[Edvin]

Hello Roland,

So I assume that you call BLC_vSetBtAddress with a custom value for u32SerialNumber, not equal to the device address already defined in the FICR, is that correct?

 

Do you do the same operation in the bootloader project?

I suspect that when the device starts up in bootloader mode, the device uses the standard address found in FICR->DEVICEADDR[0] and FICR->DEVICEADDR[1], and hence, the PC is looking for a bootloader with a different address. 

Can you check this by opening nRF Connect (for desktop), and start scanning after you try to perform the DFU. See if there is a device advertising with "DfuTarg" (or any other name if you changed it in the bootloader project), and see if the address corresponds with the address that you set, EC:2A:F0:F0:F0:DB, or another address?

 

Best regards,

Edvin