NRF51 SDK 9.0.0 S110 Buttonless DFU Issue (Segger Embedded Studio)

Hello,

Since the peer manager (or perhaps it was called device manager in the old SDKs) stores the bonding data in flash, make sure that the bootloader has set aside some pages for "application persistent storage". Look in your bootloaders sdk_config.h for any parameters/definitions that could resemble this. 

Also make sure that your application is aware of the bootloader, so that it sets the flash pages used by the device manager beneath the bootloader.

Due to holiday season in Norway we are a bit short staffed from now until the beginning of January. Please expect some delay in answers during this period.

Best regards,

Edvin

Hi Edvin,

Thanks for addressing my question. I have done quite a bit more digging and have some more details.

The project that our application is based on is the nrfreadydesktop2v310 project 'desktop_keyboard' which is a reference design developed by Nordic. In our application the pairing was changed to not require a passkey entry by using BLE_GAP_IO_CAPS_NONE. Beyond that, the DFU handling in our application is very similar to (if not exactly copied from) the desktop_keyboard project.

Using the bootloader provided in the desktop_keyboard example project I observed the following:

1. Upload softdevice and bootloader (with modified clock frequency for the Taiyo Yuden EYSGCNZWY BLE module, and single bank rather than dual bank).
2. Device starts advertising as DfuTarg and I can upload the application using nRF Connect successfully. 
3. Application starts normally and I can pair with it using nRF Connect. 
4. Initiate DFU using nRF Connect, but bootloader does not start the DFU process and instead jumps right to the application. This process repeats indefinitely. 

This is the bootloader_start function in the application (directly copied from desktop_keyboard project):

static void bootloader_start(uint16_t conn_handle)
{
    uint32_t err_code;
    uint16_t sys_serv_attr_len = sizeof(m_peer_data.sys_serv_attr);

    err_code = sd_ble_gatts_sys_attr_get(conn_handle,
                                         m_peer_data.sys_serv_attr,
                                         &sys_serv_attr_len,
                                         BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS);
      
    if (err_code != NRF_SUCCESS)
    {
        // This means the service changed indication cannot be sent in DFU mode, but connection
        // is still possible to establish.
    }

    m_reset_prepare();
    
    err_code = sd_power_gpregret_set(BOOTLOADER_DFU_START);
    APP_ERROR_CHECK(err_code);

    err_code = sd_softdevice_disable();
    APP_ERROR_CHECK(err_code);

    err_code = sd_softdevice_vector_table_base_set(NRF_UICR->BOOTLOADERADDR);
    APP_ERROR_CHECK(err_code);

    NVIC_ClearPendingIRQ(SWI2_IRQn);
    interrupts_disable();
    bootloader_util_app_start(NRF_UICR->BOOTLOADERADDR);
}

Another test I did was using the bootloader and ble_app_hrs_s110_with_dfu_pca10028 example from SDK9. To check if the segger import was the issue, I moved the ble_app_hrs_s110_with_dfu_pca10028 application to Segger. I uploaded the bootloader and application via DFU, and am also able to perform DFU initiated by the application. This is the desired result.

The last test I ran was using the desktop_keyboard reference project with as limited changes as possible since this is likely the closest relation to the custom application. The main changes involved disabling the keyboard matrix and key scanning as well as using BLE_GAP_IO_CAPS_NONE. I can pair with the device and initiate the DFU process. The device then disconnects and starts advertising as DfuTarg. At that point I am able to connect to the DfuTarg device and re-initiate the DFU process which then completes. This isn't the exact behaviour I am looking for, however, it is different than what I am observing with the custom application. 

Once again, any help would be greatly appreciated!

Have you tried to debug the bootloader to find out why it starts the application, and doesn't start in DFU mode? From your bootloader_start() function, there is a function that is called: sd_power_gpregret_set(BOOTLOADER_DFU_START);

Is this register read in your bootloader? Is it searching for the same value that you set in your application (BOOTLOADER_DFU_START), and does this parameter (definition) have the same hexadecimal value in the bootloader and in your application?

I am not in detail familiar with these old bootloaders (the generation before the secure_bootloader from SDK ~12). If you can't find where your bootloader reads the gpregret register, perhaps you can zip the bootloader and upload it here on DevZone?

Best regards,

Edvin

Hi Edvin,

Thanks for the suggestion - I had been debugging the bootloader but through continued debugging with the desktop_keyboard bootloader I was able to see the DFU upload wasn't getting past the wait_for_events() function and more specifically the sd_app_evt_wait() function in bootloader.c. Doing further research into this issue I found an article that discussed the cause of this issue in SDK9 (https://www.programmerall.com/article/8197885958/).

To summarize, I had the watchdog initialized in my application. By adding the watchdog feeding the DFU was not halted which was the cause of the continuous reset while in the bootloader. Now my custom application based on the desktop_keyboard project performs DFU the same was as the desktop_keyboard reference project. The challenge is still that the desktop_keyboard reference project does not perform DFU in the way I would like. As I explained previously, the desktop_keyboard reference initiates the DFU process from the application, then the device disconnects and advertises as DfuTarg. Then I can connect to DfuTarg and re-initiate the DFU process which completes successfully.

The ble_app_hrs_s110_with_dfu_pca10028 example has a more desirable DFU process that doesn't require reconnecting, however, making the watchdog changes to this example bootloader didn't solve it for the custom application. Using the same custom application with the single_bank_ble_s110 bootloader and the watchdog feeding the DFU works the same as the desktop_keyboard example - not like the ble_app_hrs_s110_with_dfu_pca10028 example. When debugging the custom application it makes it to the bootloader_start() function, but halts before getting to bootloader_util_app_start(). When using the bootloader from the ble_app_hrs_s110_with_dfu_pca10028 bootloader (aka single_bank_ble_s110) I did implement a few changes in the application:

• Added a reset_prepare() function (see below)
• Added dfu_app_peer_data_set() call in bootloader_start() function
  

static void reset_prepare(void)
{
    uint32_t err_code;

    if (s_conn_handle != BLE_CONN_HANDLE_INVALID)
    {
        // Disconnect from peer.
        err_code = sd_ble_gap_disconnect(s_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
        APP_ERROR_CHECK(err_code);
    }
    else
    {
        // If not connected, the device will be advertising. Hence stop the advertising.
        advertising_stop();
    }

    err_code = ble_conn_params_stop();
    APP_ERROR_CHECK(err_code);

    nrf_delay_ms(500);
}

static void bootloader_start(uint16_t conn_handle)
{
    uint32_t err_code;
    uint16_t sys_serv_attr_len = sizeof(m_peer_data.sys_serv_attr);

    err_code = sd_ble_gatts_sys_attr_get(conn_handle,
                                         m_peer_data.sys_serv_attr,
                                         &sys_serv_attr_len,
                                         BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS);
      
    if (err_code != NRF_SUCCESS)
    {
        // Any error at this stage means the system service attributes could not be fetched.
        // This means the service changed indication cannot be sent in DFU mode, but connection
        // is still possible to establish.
    }

    m_reset_prepare();
    
    err_code = sd_power_gpregret_set(BOOTLOADER_DFU_START);
    APP_ERROR_CHECK(err_code);

    err_code = sd_softdevice_disable();
    APP_ERROR_CHECK(err_code);

    err_code = sd_softdevice_vector_table_base_set(NRF_UICR->BOOTLOADERADDR);
    APP_ERROR_CHECK(err_code);

    dfu_app_peer_data_set(conn_handle);
    NVIC_ClearPendingIRQ(SWI2_IRQn);
    interrupts_disable();
    
    bootloader_util_app_start(NRF_UICR->BOOTLOADERADDR);
}

The watchdog appears to timeout and the bootloader does start, but since it wasn't entered via the application (and setting GPREGRET = 0xB1), the DFU process doesn't start and a reconnection loop starts.

If you are using a watchdog timer in your application, you must add that in the bootloader as well, if it isn't there already (the later SDKs does this automatically). So what is the reason that the DFU is not starting? Is it because GPREGRET != 0xB1? Have you tried setting it to 0xB1 from your application, then?

I am sorry, but I struggle to see the difference between your bootloader and the one that you refer to as "ble_app_hrs_s110_with_dfu_pca10028 bootloader".

Best regards,

Edvin

If you are using a watchdog timer in your application, you must add that in the bootloader as well, if it isn't there already (the later SDKs does this automatically). So what is the reason that the DFU is not starting? Is it because GPREGRET != 0xB1? Have you tried setting it to 0xB1 from your application, then?

I am sorry, but I struggle to see the difference between your bootloader and the one that you refer to as "ble_app_hrs_s110_with_dfu_pca10028 bootloader".

Best regards,

Edvin