Multi packets in SDK 7.2.0 bootloader

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Sun, 26 Mar 2017 11:59:22 GMT

Hi Hung,

We had to implement our own UART handling on the central side in order to have better UART throughput and avoid UART activity during radio events (this caused some collisions appaerntly).

Eventually, after optimization on both sides, we managed to get a throughput of ~10KBps.

Thanks for your help!

RE: Multi packets in SDK 7.2.0 bootloader

Hung Bui — Mon, 20 Mar 2017 15:52:33 GMT

I see, we do have the buffer to store the incoming data, but we write each packet to flash separately. I assume to avoid the CPU being halted for long time (CPU is halted when doing flash writing).

I don't think we have anything better than uart fifo. On nRF51 the CPU have to feed the UART peripheral on byte-byte basis. On nRF52 we have UARTE which has EasyDMA so the UARTE can access the memory directly.

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Sun, 19 Mar 2017 13:42:29 GMT

Hi Hung, We've managed to get things working at 11.25 ms and 6 packets per interval, but we had to change the flash sequence. Instead of writing each packet to flash, we are storing them in a temp buffer and writing all of them in a single request at the end of the interval. Each flash operation (with pstorage) has a lot of overhead, so writing each packet separately was very slow. For now, it seems that what's holding us back is the UART on the central side. Is there a more efficient module other than uart fifo? maybe one that can work with chunks of data instead of byte-byte?

RE: Multi packets in SDK 7.2.0 bootloader

Hung Bui — Mon, 13 Mar 2017 13:36:25 GMT

Hi Gili,

You are correct [0x10 0x03 0x06] tells operation failed when receiving image.

If you have a look at the release note of SDK v7 (known issue section) you can find that we only tested to work with minimum connection interval of 11.25ms. Most likely 7.5ms would be too short to do flash operation.

Could you try to increase the connection interval to 11.25ms and also change the packet notification to let's say 20 packets ? Make sure your central stops transmitting after every 20 packets to wait for the notification.

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Sun, 12 Mar 2017 10:05:46 GMT

Hi Hung,

One more question. What versions of BL/SD/Central are you using?

Basically, our BL is the regular BL code, with minor changes (no changes to the DFU flow though).

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Sun, 12 Mar 2017 07:58:27 GMT

Hi Hung, Here are two sniffer traces: 2 packets per interval - successful with a pretty stable flow 4 packets per interval - fails pretty quick

Both traces are at ~7ms interval with a 100 packets notification. Only difference is 2 or 4 packets per interval.

From what I understand in the bootloader code, the [0x10 0x03 0x06] response packets indicate an error on the memory/flash write operation. Is this correct?

RE: Multi packets in SDK 7.2.0 bootloader

Hung Bui — Thu, 09 Mar 2017 15:12:04 GMT

Hi Gili,

Are you using Keil or use GCC, could you attach your bootloader project ? Have you modified anything in the bootloader ?

What you saw in the hvx.data is normal. It's the acknowledge for DFU command, and the packet receipt notification with the number of byte received.

Could you capture a sniffer trace that actually show the DFU target crash ? The one you attached showing it was the DFU master didn't want to send data.

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Thu, 09 Mar 2017 13:41:27 GMT

It seems like the bootloader is failing on hci_mem_pool_rx_produce, in app_data_process. It returns a NO_MEM error. I assume we're writing too fast to the flash. I there a way to resolve this so we could get a faster throughput?

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Thu, 09 Mar 2017 11:21:43 GMT

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):

call sd_ble_gattc_write for each packet.
if we get BLE_ERROR_NO_TX_PACKETS, retry every 1ms for up to 1 sec.
after sending X packets, wait for notification to arrive (up to 4 sec wait).
after notification is received, go back to #1.

RE: Multi packets in SDK 7.2.0 bootloader

Hung Bui — Wed, 08 Mar 2017 14:23:49 GMT

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 ?

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Wed, 08 Mar 2017 13:12:39 GMT

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

RE: Multi packets in SDK 7.2.0 bootloader

Gili Elias — Wed, 08 Mar 2017 08:44:15 GMT

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)?

RE: Multi packets in SDK 7.2.0 bootloader

Hung Bui — Tue, 07 Mar 2017 12:56:24 GMT

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.