BLE_GATTS_EVT_HVN_TX_COMPLETE event not fire

[rolandash]

Configuration:  52840 / S140 / V610, SDK 15.2

As approaching production, I am continuously testing S140 on various environments. 

I noticed during testing that there are few chances that BLE_GATTS_EVT_HVN_TX_COMPLETE not fire. I do not have hard evidence on it but seems to be a reasonable deduction.

A simplified test setup can be a bi-directional communication between 2 52840, one as central and one as peripheral. Peripheral keeps sending notifications to central using 

sd_ble_gatts_hvx(), and the central send packet back to peripheral using

sd_ble_gattc_write(). 

So at the peripheral end, just as the regular procedure, sd_ble_gatts_hvx() is called and the next packet will be sent after BLE_GATTS_EVT_HVN_TX_COMPLETE event is raised. Following code snippet briefly shows this process:

                {
                        ...
                        case BLE_GATTS_EVT_HVN_TX_COMPLETE:
                            ....
                            send_next_packet();
                            break;
                        ....
                }
                
                uint32_t send_next_packet () {
                ...
                    err_code = sd_ble_gatts_hvx(....);
                    if (err_code == NRF_SUCCESS) {
                        ....
                    }
                    else {
                        LEDS_ON(BSP_LED_3_MASK);
                        ....
                        
                    }
                }

And I can observed that in some cases this chain of notification sending stalled there. It is not an error returned by sd_ble_gatts_hvx() as I can not see any sign indicated by the error handling block. The physical link is also still remain connected as I can still receive packet from the central in reversed direction.  so I can only conclude that BLE_GATTS_EVT_HVN_TX_COMPLETE event did not fire as expected. The chance is rare, (like in a 10-minutes testing run there maybe 1 time of this problem happening), but it did happen.

So is there any suggestion from Nordic engineer team that why this issue can happen, and how should I handle this situation?

Thank you in advance.

[Vidar Berg]

Hi,

I have not experienced missed events from the Softdevice. Do you have a minimal example that I can use to replicate this here? Also, please try to monitor the .count value for the BLE_GATTS_EVT_HVN_TX_COMPLETE event and verify that it's always '1'. 

[rolandash]

Thank you Vidar Berg

I think the behavior of this issue is quite similar to the problem in this post, except the OP mentioned the problem only exists when using SPI, which is not enabled in my test case. Unfortunately the OP did not feedback if he resolved this issue or not. 

The current project uses lots of library. I do not have a minimal example now. I am trying to make one, and even if it shows no problem, I still need to enable other libraries one by one to have a crosscheck over it. This will be quite time consuming.

And I am not sure why the count for BLE_GATTS_EVT_HVN_TX_COMPLETE should always be '1'? If it is other values it should not prevent triggering the next packet?

[Vidar Berg]

rolandash said:

And I am not sure why the count for BLE_GATTS_EVT_HVN_TX_COMPLETE should always be '1'? If it is other values it should not prevent triggering the next packet?

 Is the packet transfer driven by the BLE_GATTS_EVT_HVN_TX_COMPLETE? I.e., you kick-off transfer of a large buffer by manually sending one packet, and let the remaining packets be transferred by send_next_packet() in BLE_GATTS_EVT_HVN_TX_COMPLETE? Or did I make the wrong assumption?

If the above is true I would expect the packet count to be '1'. And if it's more, you are probably receiving fewer events than expected. 

The issue reported in the other thread may be related as you said. Unfortunately, it does not seem like the found a solution to it.  

[rolandash]

I see. Your assumption is correct. I would not worry about the count though, as the free_hvn_size will be balanced by increasing the value of count upon fire of BLE_GATTS_EVT_HVN_TX_COMPLETE. And recently I have changed to keep pushing into queue until NRF_ERROR_RESOUCE instead of queue size counting. So as long as there is a BLE_GATTS_EVT_HVN_TX_COMPLETE event, the next packet will be triggered.

I try to at least get a direction before I start to strip down the code blindly. One possibility is I use app_scheduler to decouple invokations from interrupt context and move to main context, seems to have the potential causing a missing of event.

[Vidar Berg]

Yes, agree. I don't think it makes sense to strip down the code blindly. But is possible to decouple just the transfer logic and put it into one of the SDK examples such as ble_app_uart? Another thing you could do is to try without the app scheduler and see if it makes any difference.