Attachments (2) Download All
Nordic Case Info
  • Case ID: 210149
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

  • 0 in reply to Edvin

    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
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    <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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to roland.schenk

    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

  • 0 in reply to Edvin

    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

  • 0 in reply to roland.schenk

    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

  • 0 in reply to Edvin

    Hello Edvin,

    Yes, the address i used, was didfferent form the standard address, and the bootloader was advertising as "DfuTarg" on the standard device address from FICR->DEVICEADDR[0] and FICR->DEVICEADDR[1].

    An other problem was, that I had set m_bt_addr.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC;.

    Now it's working fine, but i had to change the address to the standard address and the address type to BLE_GAP_ADDR_TYPE_RANDOM_STATIC (like in the nordic buttonless example).

    Which changes are needed in the bootloder to use a custom address with address type BLE_GAP_ADDR_TYPE_PUBLIC?

    Thanks a lot for your help!

    Best regards,

    Roland

Reply
  • 0 in reply to Edvin

    Hello Edvin,

    Yes, the address i used, was didfferent form the standard address, and the bootloader was advertising as "DfuTarg" on the standard device address from FICR->DEVICEADDR[0] and FICR->DEVICEADDR[1].

    An other problem was, that I had set m_bt_addr.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC;.

    Now it's working fine, but i had to change the address to the standard address and the address type to BLE_GAP_ADDR_TYPE_RANDOM_STATIC (like in the nordic buttonless example).

    Which changes are needed in the bootloder to use a custom address with address type BLE_GAP_ADDR_TYPE_PUBLIC?

    Thanks a lot for your help!

    Best regards,

    Roland

Children
  • +1 in reply to roland.schenk

    Hello Roland,

     

    Try to modify the gap_params_init() function in nrf_dfu_ble.c in the bootloader project:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static uint32_t gap_params_init(void)
    {
    uint32_t err_code;
    ble_gap_conn_sec_mode_t sec_mode;
    uint8_t const * device_name;
    uint32_t name_len;
    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
    #if (!NRF_DFU_BLE_REQUIRES_BONDS)
    err_code = gap_address_change();
    VERIFY_SUCCESS(err_code);
    if ((m_flags & DFU_BLE_FLAG_USE_ADV_NAME) != 0)
    {
    NRF_LOG_DEBUG("Setting adv name: %s, length: %d", m_adv_name.name, m_adv_name.len);
    device_name = m_adv_name.name;
    name_len = m_adv_name.len;
    }
    else
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    Best regards,

    Edvin

Terms of service