Bluetooth Variation by Country? DFU problems by Location

[Paul]

We are experiencing bizarre, bizarre DFU problems.

I have a custom circuit board with a NRF51822-QFAC - when I initiate a DFU with an iPod touch purchased in the United Kingdom, the update succeeds. When I initiate a DFU with an iPod touch purchased in the United States it fails.

Specifically I am initiating a DFU update from the United States through the Noridc NRF Toolbox 2.4 on an iPod touch running iOS 8 and using SDK 9.0 our upload times out after 4 packets (0%) and says "DFU The connection has been lost". When doing the same thing from a device in the United Kingdom the process completes successfully.

We have mailed a second US based iPod Touch to the UK - the developer in the UK experiences DFU failure when using the American device to initiate updates. Sending a second UK based iPod touch device to the US results in DFU success when using the UK iPod touch.

Both iPod touches are using the latest NRF Toolbox app (nRF Toolbox Version 2.4) and latest version of iOS 8.4.1 - (have not upgraded to iOS 9 yet). We can replicate the behavior using iPhone 6 devices as well as Galaxy S4's. (US versions of the three products fail, UK versions succeed).

We have confirmed this behavior across 10 different NRF51822-QFAC (5 in the US, 5 in the UK) - all 5 fail when taking a DFU from a US based iPhone 6 or iPod Touch. All 5 succeed when taking an update from a UK device. Sending failed boards to the UK results in success. US start working in the UK and vice versa.

The firmware on the device is identical. Dumping the firmware using a Segger script and doing a hex compare confirms this. The boards are identical. The only variation we can track down is the device locale type.

Why would the US version of nRF Toolbox 2.4 fail, while the UK version of nRF Toolbox 2.4 works?

As best as we can deduce, calls to hci_mem_pool_rx_extract succeed when coming from UK phones but not US ones. Is UK bluetooth somehow slower or faster? (As insane as that sounds). It follows that this buffer fills up when initiating an update from a US phone but is being cleared in time for UK phones. I know the WiFi spec has variation by location but was not under the impression BLE did.

The issues we are seeing are very similar as the ones described in this thread: devzone.nordicsemi.com/.../ - the solution there of increasing queue size did not solve our problem.

We only encountered this issue when upgrading from SDK 7 to SDK 9. All DFU functionally was previously working both on US and UK phones with SDK 7.

[Hung Bui]

Hi Paul,

This sounds really really strange.

We would need the sniffer trace from the failure trials to understand what happened. If you can also record successful update, it would be nice.

With the sniffer trace, we can find what is the data rate (connection interval and number of packet per connection event) But I don't think they are varied.

I am wondering did you also send the nRF51 board with the ipod/iphone you used or you sent only the central devices and tested them with different nRF51 board.

My suspicion is with the ATT caching issue. How did you test them ? Did you test them with the bootloader only or with your application and buttonless mechanism to jump to bootloader ?

Have you made sure you didn't modify anything in the bootloader in the SDK ?

[Paul]

Changing DFU Number of Packets to 1 makes it work across both platforms. Setting it to 5 breaks on both platforms. Setting it to 2 works on the UK phones but not the US. Perhaps something else at work here but we've traced it to a buffer size issue and can code around it.

Somewhat unsatisfactory solution.

[Hung Bui]

Hi Paul,

But this doesn't explain why when you send the same device from US to UK it failed. I would be surprised if the phone changes the behaviour when changing the location.

I agree that this is most likely the issue with the buffer, please check and make sure you have this:

#define TX_BUF_SIZE       4u    /**< TX buffer size in bytes. */
#define RX_BUF_SIZE       32u   /**< RX buffer size in bytes. */

#define RX_BUF_QUEUE_SIZE 8u    /**< RX buffer element size. */

in your hci_mem_pool_internal.h file in your project.

A sniffer trace of an unsuccessful DFU transaction would tell more about the issue.

We don't have any issue with iOS devices we have in house (dozens of them), number of DFU packets =10. It would be interesting if you can send one of your iOS device to us (Norway) or you can contact our Sale/FAE in your location, we have FAEs in the US. Let me know if you don't have the contact.