Indications are not retransmitted causing issues when packets are lost

Flole

We have enabled indications and are then sending data using blc_gatt_pushHandleValueIndicate(). Sometimes the indications do not arrive, which causes the following calls to fail with error 193/0xC1 (GATT_ERR_PREVIOUS_INDICATE_DATA_HAS_NOT_CONFIRMED). They are probably lost in the air. There seems to be no retransmission and no way to manually retransmit the packet. As far as I understand, the packet should be retransmitted if it's not acknowledged by the client.

Do you have any idea why this is happening and how I can recover from a situation where a packet is lost during transmission?

Flole

It looks like the cause might be an inaccurate external 32k oscillator. I am doing blc_pm_select_external_32k_crystal() as first thing in main(), is there anything else I need to do in order to calibrate the external oscillator? The datasheet mentions a "Programmable on chip load cap".

Additionally, when I select the external 32k oscillator after a reset caused by the programmer the CPU stalls in blt_sdk_main_loop(). I need to power-cycle after programming and then it at least runs but it causes the packet loss.

Flole

This is still an issue: When selecting the external crystal it does not work properly and the timing is off. Is there any way to perform the calibration of the external crystal and control the on chip load cap?

TL_SW

The platform uses pm_check_32k_clk_stable to confirm whether external 32k crystal is stable.

Flole

What happens if it is not stable? Does it stall in that case?

The functions does not check the frequency deviation or perform calibration though, right? So if the on chip load caps are causing a high frequency deviation that would not be detected?

TL_SW

If it is not stable, BLE will not go to sleep.  This function checks the frequency, but only roughly.

Flole

How do I perform calibration of the 32k pad oscillator? And would it theoretically be possible to write a custom version of the "cpu_sleep_wakeup" and "pm_tim_recover" function to use a crystal that has a high but constant frequency deviation? Or do other things rely on the timing to be exactly 32.768kHz? I believe that maybe during production wrong oscillators were fitted.

TL_SW

Now it is impossible to write a custom version of the "cpu_sleep_wakeup" and "pm_tim_recover" function，this involves a lot of register actions.

Flole

I am still seeing issues with packet loss and connection drops even though I am using the internal oscillator for now. Is there any way to further debug tthis?

TL_SW

If you have capture or print log, Please commit, we will help to debug.