How to resolve mixed messages during BLE Indication

[Chengxin Ma]

The task I am working on is sending a list of records from an nRF52832 chip to a central. Before sending the records, the total number of them should be sent, so the central device would know how many records it is expected to process.
The communication is triggered by turning on the indication. On the SoC side, this raises a BLE_GATTS_EVT_WRITE event, under which the number of records is sent using sd_ble_gatts_hvx(). Since this moment on there will be BLE_GATTS_EVT_HVC events, under which the records are sent piece by piece (upon getting a confirmation from the central) until the end.
When a disconnection happens, ideally on the central side it would receive a messages sequence like:

00-50-00-00-00-00; // number of records in hex format; 50(hex) = 80(dec)
A0-B0-C0-D0-E0-F0; // from here on is the testing data
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
3A-3B-3C-3D-3E-3F;
// here comes a disconnection
00-4C-00-00-00-00; // resend the number of records in the hex format; 4C(hex) = 76(dec)
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

However, what I actually got is:
00-50-00-00-00-00;
A0-B0-C0-D0-E0-F0;
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
// here comes a disconnection
00-4C-3C-3D-3E-3F; // unexpected piece of record
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

As we can see, 00-4C-3C-3D-3E-3F is a combination of 3A-3B-3C-3D-3E-3F and 00-4C-00-00-00-00.
I am wondering why these two messages are put together.
The intuitive hypothesis is that there is some kind of sending/receiving buffers that are not cleared after a disconnection.
Does such a hypothesis make sense? If yes how can I solve this problem of mixed messages?
The following screenshots show the message sequence received by the phone. In the second picture, the number of total messages/records is not displayed after the first enablement of indication, and after the second enablement of indication, the message starting with "4A" is missing.
Screenshot_20160912-121046.png Screenshot_20160913-151849.png

[Hung Bui]

@ChengxinMa: No, it maybe not about jumping over. So the situation was :

1. The characteristic value was 3A-3B-3C-3D-3E-3F; when the connection was terminated. When you call sd_ble_gatts_hvx() the stack not only send the indication, but also update the value of the characteristic.

2. You are connected again, the value of the characteristic was still 3A-3B-3C-3D-3E-3F;

3. You called sd_ble_gatts_hvx() to update only the first 2 bytes with 00-4C, and the result is that the value of the characteristic will be 00-4C-3C-3D-3E-3F.

4. 00-4C-3C-3D-3E-3F will be send in the indication as it's the value of the characteristic.

Please try to call sd_ble_gatts_hvx with full 6 bytes when you send the number of records (00-4C-00-00-00-00 for example ) .