Hello,
I have an application where an nRF52832 peripheral (S132 v3.1.0) transmits a 5-to-10 MB file to an nRF52832 central (S132 v4.0.5). The peripheral sends the file in segments using a custom notify characteristic (similar to the ble_app_uart examples). With an MTU size of 247 and connection event length extension, I'm able to achieve around 700 kbps transfer.
However, I've noticed that occasionally the file gets corrupted. When this occurs, three consecutive bytes of the file contain garbage data. After extensive testing, I believe the data is being corrupted on L2CAP reassembly by the central.
I changed the file to be a repeating chain of 0x00 through 0xC0 and added some additional wrappers to the packet for diagnostics:
- Byte 0: 0xFE (Start)
- Byte 1-4: File offset (in big endian)
- Byte 5: Number of bytes in this packet
- Byte 6 through N-2: File content
- Byte N-1: 0xFF (End)
I used the NXP USB-KW41Z for sniffing as it is capable of Bluetooth 4.2 (Nordic's sniffer is not). I was able to catch 8 transfers where the BLE_GATTC_EVT_HVX event on the central contained incorrect data. In all instances, the packet where the file was sent was fragmented by the peripheral and the 3 bytes that were corrupted were the last 3 bytes of the first fragment.
Here is one such example. The 244 byte notification was partitioned into two fragments by the peripheral's soft device.
Fragment 1:
FE 00 8A A0 E6 F4 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56
57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66
67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76
77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86
87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96
97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6
Fragment 2:
A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6
B7 B8 B9 BA BB BC BD BE BF C0 00 01 02 03 04 05
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15
16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25
26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45
46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55
56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65
66 67 68 FF
Fragment start packet:
Fragment start (re-transmission):
Fragment end:
The event data I received on the central for the BLE_GATTC_EVT_HVX event:
FE 00 8A A0 E6 F4 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56
57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66
67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76
77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86
87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96
97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 1A 77 00 //Note A4 A5 A6 has been replaced with 1A 77 00
A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6
B7 B8 B9 BA BB BC BD BE BF C0 00 01 02 03 04 05
06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15
16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25
26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35
36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45
46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55
56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65
66 67 68 FF
In all instances I've seen, the first fragment is transmitted twice. There are multiple instances where the notification is fragmented and data is not corrupted. The corrupted bytes appear to only occur when the first fragment is re-transmitted.
So my questions are:
- What causes the Soft Device (S132 v3.1.0) to decide to fragment the notification into two packets?
- Is there a way to prevent fragmentation?
- Is the packet re-assembly a bug in S132 v4.0.5 or some underlying Bluetooth problem?
Edit: Added wireshark capture 11-21-2017__03-43-00 PM.pcapng