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

DFU-OTA over BLE compatibility query: S110 and SDK version

In past, I was able to perform DFU-OTA over BLE transport for a custom board that has nRF51822QFAA (256kB main flash memory) SOC. I tested this functionality with Nordic's Android APP, nRF Toolbox and nRF MCP. Since then, I've been working with a different MCU for a different application and today I'm revisiting this topic. During the last few months, our custom board has gone through significant changes and hence I'll be once again trying to implement DFU-OTA over BLE for the same old nrf51822QFAA SOC on our new custom board. I noticed that there is a newer version of SDK (v10.0.0) and a newer version of Softdevice (s110, v8.0.0) available and as in general, staying at latest software is better, hence I'm wondering what are things that I should take into consideration while trying to migrate my application from SDK v6.1.0 with SD V7.0.1 to SDK v10.0.0 with softdevice v8.0.0 ?

According to the migration notes (s110_nrf51_8.0.0_releasenotes),

This SoftDevice version is not Production tested on all IC revisions, and is not compatible with nRF51 IC/revision 1.

Q1 : How to find the IC version of my nRF51 IC?

According to the SDK Release notes, v 10.0.0, there are some known issues with DFU-OTA which are:

- Device Manager is not supported in multi-role S130 operation.
    - Device Manager works in peripheral or central only operation on 
      S130. This must be decided at compile time.
- The DFU over BLE example has been tested to work with a minimum 
  connection interval of 11.25 ms. The application cannot handle 
  connection intervals lower than 11.25 ms and may undergo a system 
  reset in the middle of a firmware update.
  Workaround: If you face unexpected disconnects during the firmware
              update process, consider increasing the connection 
              interval used by the master.
- The old manual procedure for testing buttonless DFU, as specified in
  the documentation, can lead to the DFU process hanging or returning 
  an error when used with Master Control Panel 3.8 and newer.
- Bootloader binaries (.bin files) generated with the GCC makefile 
  should not be used. Instead, generate the bootloader bin files using 
  nrfutils, found on GitHub.

According to the same SDK Release notes: The supported Softdevices for SDK v10.0.0 are:

- S110 v8.0.0
- S120 v2.1.0
- S130 v1.0.0
- S210 v5.0.0
- S310 v3.0.0

Q2: The MCP App version that I've installed on my Android Phone is v4.0.4, and my custom board does not have a button (So basically I need to test buttonless DFU), So does this mean, I should NOT migrate to softdevice s110, v8.0.0 ?

Q3: Since SDK V10.0.0 is not supported with SoftDevice v7.1.0 (see above for the list of supported Softdevices), hence I cannot use SDK V10.0.0 with SD s110, v7.1.0 ?

Please confirm.

  • s110 v.8.0.0 is production tested on 2nd rev IC, but SDK v.10.0.0 is not. One reason for that is that the new SDK does not necessary provide workarounds for PANs present on older silicon, but it's probably going to work just fine if you make sure to turn on CPU block in your application and not use DCDC, see s110 v.8.0.0 release notes for more details.

    Note that on the SDKs we don't run the same level of testing, as we deliver the source code, and it's example code that the customers can modify and use as they see fit. The final testing of the application code must be done by the customer as part of their product development and testing procedures.

    PAN document for nRF51 : infocenter.nordicsemi.com/.../nRF51822-pan_v3.0.pdf

  • I ported my application to:

    nrf51822QFAA IC revision: 2

    Softdevice: s110, v8.0.0

    SDK: v10.0.0

    Above compatibility matrix seem to work okay. however I need to test lot more. I'm not using DC/DC converter and didn't quite get as to how to turn on CPU block in my application? Can you please explain a little more about turning ON the CPU block and how to achieve that ?

  • <snip from S110, v8.0.0 release notes>

    The default behaviour is now that the application can use the CPU while the radio is active. In previous versions of the S110, the CPU execution was blocked by the SoftDevice during radio activity. Note that this new default setting is incompatible with running this SoftDevice on nRF51 series IC revision 2 (devices affected by PAN #44 "CCM may exceed real time requirements" and PAN #45 "AAR may exceed real time requirements" described in the nRF51822-PAN). If you plan to run S110 v8.x on devices affected by these PANs, you will need to enable mutual exclusion between the radio and the application by means of the sd_ble_opt_set() SV call and the BLE_COMMON_OPT_RADIO_CPU_MUTEX option (DRGN-4511).

    <snip from S110, v8.0.0 release notes>

  • From this and this discussion, it seems that I need to enable Mutual exclusion between CPU and RF as I'm using IC revision 2 with Softdevice v8.0.0. Please confirm if the ordering is correct.

    static void enable_cpu_rf_mutex(void)
    {
        uint32_t opt_id;
        uint32_t err_code;
        ble_opt_t ble_cpu_block;
        memset(&ble_cpu_block, 0, sizeof(ble_opt_t));
        ble_cpu_block.common_opt.radio_cpu_mutex.enable = 1;
        opt_id = BLE_COMMON_OPT_RADIO_CPU_MUTEX;
        err_code = sd_ble_opt_set(opt_id, &ble_cpu_block);
        APP_ERROR_CHECK(err_code);
    }
    
    int main(void)
    {
        enable_cpu_rf_mutex();
        ble_stack_init();
        gap_params_init();
        advertising_init();
        services_init();
        conn_params_init();
        ble_advertising_start(BLE_ADV_MODE_FAST);
        while (1) {}
    }
    
Related