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

[sidekick]

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.

[Vidar Berg]

Hi,

A1: Instructions on how to determine the chip revision can be found in the compatibility matrix. Note that the 3rd revision is recommended for new designs, and is the IC that it's currently in production.

The known issues are general for this release, but the last 3 are relevant for DFU.

• 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 preferred connection parameters are set to 15 ms and 30 ms in the bootloader. So this is not a problem unless the central ignores this request.

• 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.

When using MCP version later than 3.8 you won't have to follow the instructions in the doc, only click the dfu button in MCP, and it will do all the steps automatically

• Bootloader binaries (.bin files) generated with the GCC makefile should not be used. Instead, generate the bootloader bin files using nrfutils, found on GitHub.

Use the output .hex if you're using GCC. The binary includes the UICR section, 0x10001000 in memory map, which leads to lot of byte padding (0x3c000 -> 0x10001000 = ~250MB).

A2: S110 v.8.0.0 has better support for buttonless DFU. To be more specific, SDs prior to this release lacked an option for only restoring the attributes for the system services (service changed characteristic) , which caused problems when doing DFU with paired devices. Relevant thread if you want more details here.

A3. It's generally recommended to use the same softdevice as specified in the release notes for the given SDK. Otherwise you would have to manually port the SDK to support a different softdevice. The SDKs are contiously being improved with new features and bugfixes.

[Vidar Berg]

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