Any way to reset hvx Tx buffer not losing connection?

[Fanis]

I need to transfer a lot data via BLE from periperal nrf52832 to central just like here. The answer looks like what i exactly need. Major priority is to maintain seamless data stream without losing packets and without twin packets on the central's input sequence (the conditions are that connection is lost at random intervals). So i need to keep track of every sent packet via notification. Problem is in my specific case i fill up Tx buffer until i get BLE_ERROR_NO_TX_BUFFERS, then wait for BLE_EVT_TX_COMPLETE and have to do some heavy math (takes around 1-2ms) before i generate new packet and push it cyclically to hvx buffer again. What i get is situation during connection session the second BLE_EVT_TX_COMPLETE (caused by successive transfer of the next notification from hvx buffer) is called earlier than i can refill hvx buffer with new packet. So central receives multiple twin packets in stream. I just wonder is there any way to "reset" Tx buffer exactly at the beginning of BLE_EVT_TX_COMPLETE or limit notifications per connection to 1 while initialization procedure?

[RK]

it's rather hard to work out what your problem is from this description. It sounds to me however like you are filling one large buffer, then sending bits of it in multiple HVX packets. However you are then rewriting the buffer when the first TX complete notification comes in and not after the last one arrives.

If you queue up an HV packet for transmission and it points to a chunk of memory, you can't use, change or update that memory until the TX notification for that packet has been returned to you. Between the sending and the TX received, the softdevice stack really owns the memory.

Sounds like you need two buffers to write your data into. One for the transmission going out, one for the next transmission you're calculating.

If that's not what you're doing then perhaps you can write a better explanation.

And if you only want to send out one HVX notification, then send out only one HVX notification. But you'll only get to send 20+ bytes at a time if you do that.

[Fanis]

I just rearanged code flow with moving out time consuming action from BLE callbacks and it works better.