Can you check if the priority for the BLE interrupts are set to the highest value?
As himam_31 asked, if the BLE interrupt is not handled in a timely fashion due to interrupt priorities, then there could be corruption of the BLE stack occurring; causing the failure you observed above. Stopping and then restarting the BLE stack would fix the issue (assuming it is software-related as we are guessing).
CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.
The BLE interrupt has the highest priority (0). I don't think a softreset is a good solution, as we'll still lose data during the reset and reconnection.
I believe the issue arises because I'm calling CyBle_GattsNotification() from within a timer ISR. When I move the call outside the ISR, everything works smoothly. This will give me a workaround in the short-term, but long term I'd still like to call CyBle_GattsNotification() from the ISR.
True, the reset is not a very clean solution, but if all else fails it will at least get to a known state.
So, you've narrowed the issue down to a timer isr? Well, that's pretty good progress then!
Things that could be causing the issue:
- Disabling interrupts before calling the CyBle_GattsNotification() will have it hang permanently
- Priority issues between the timer isr priority and something within the CyBle_GattsNotification()
Not that you have to listen, but as some advice I would suggest not doing long calls within the ISR as it will prevent other interrupts of lower priority from firing. I would assume that you are calling the CyBle_ProcessEvents() within your main-code loop; Handling the GATTS notification there would be the simplest architecturally for others to follow, requiring only a flag being set in the ISR to trigger it.