Multi packets in SDK 7.2.0 bootloader

[Gili Elias]

Hi, We are doing DFU updates through a nrf51422 dongle (data passing from UART to BLE), using our own code, based on the multilink central example.

The DFU peripherals are nrf51822, s110 7.0.0, SDK 7.2.0. The central unit is nrf51422 dongle, s130 3.0.0, SDK 12.2.0.

We are trying to achieve maximum throughput by using multiple packets per connection interval (@ 7.5 ms interval). It works fine when using a single packet and even two packets per interval, but when increasing to 3 or more, packets seem to get lost, even though TX_COMPLETE event is triggered.

Based on the peripheral SD and SDK, are they suppose to support such throughput?

EDIT: I can't seem to find a way to attach the sniffer trace file. The form allows me to select a file, but doesn't seem to do anything with the file I choose.

Try this link.

This is a trace with a 12 packet notifiaction and 4 packets per connection interval (connection interval set at ~18sec). I stopped it brutally at the middle since it was very slow. The 4 sec breaks are the time we wait for a notification on the central side.

[Hung Bui]

Hi Gili,

S110 supports up to 6 packet per connection event.

Which S130 version you are using ? We don't have S130 v3.0 If you are talking about S130 v2.0 then it also support 6 packets per connection event.

I suspect it's the buffer overflow on the DFU bootloader application.

Do you have the issue right when it started or it's in the middle of the process ? Could you capture a sniffer trace ?

Have you enabled packet notification ? You can avoid packet overflow by using packet notification, try to set it at 10 for example, just for testing.

[Gili Elias]

Hi Hung, Thanks for the reply. We used the S130 that came with SDK12.2. You are right, it is 2.0.1. My mistake.

Packet notification was at 100 packets, which didn't work. I've managed to get 4 packets per interval when I set the notification to 4 packets as well, but this slows the throughput (it's takes 2 intervals for 4 writes and a notification).

Does the packet notification indicate that X packets were just received or does it also indicate that they were written to flash?

Is there a way to increase the DFU buffer size?

I'm trying to run a sniffer trace using a PCA10000, but it doesn't seem to work (no data incoming to wireshark). I noticed the sniffer app is pretty old and not maintained. Is it possible it doesn't work with the latest JLink drivers (6.12j)?

[Gili Elias]

I've managed to use the sniffer after reverting back to Jlink driver 5.12. I attached the sniffer trace to the main post.

[Hung Bui]

Hi Gili,

Our test with 11ms connection event, and 6 packets per connection event worked fine.

I suspect there could be a problem with the configuration of the buffer, please check the hci_mem_pool_internal.h you included in your bootloader and check if it looks like 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. */

The packet receipt notification contain the number of byte the target receives. For example first notification in your case it has value = 240 (20x12).

Looking at your sniffer trace I don't really understand what was the problem ? I can see that the central stopped writing data after it sent 7 packets after the last notification. The DFU bootloader expect 12packets before it sends the next one.

So it's the central crashed not the peripheral ?

[Gili Elias]

The hci_mem_pool_internal.h is identical. Is it possible that I get different HVX events in the central? I tried printing the data from p_ble_evt->evt.gattc_evt.params.hvx.data, based on the length in the same member. Mostly I get:

  [0x10 0x03 0x06]

but every few events I get something like these:

  [0x11 0x40 0x1F 0x00 0x00]
  [0x11 0x10 0x27 0x00 0x00]

As for the number of packets, our procedure in the central is as follows (for X packets notification):

1. call sd_ble_gattc_write for each packet.

2. if we get BLE_ERROR_NO_TX_PACKETS, retry every 1ms for up to 1 sec.

3. after sending X packets, wait for notification to arrive (up to 4 sec wait).

4. after notification is received, go back to #1.