-
1. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS
HimaM_31 Sep 5, 2017 2:37 AM (in response to bobcat_1857246)Can you check if the priority for the BLE interrupts are set to the highest value?
Thanks,
Hima
-
2. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS
e.pratt_1639216 Sep 5, 2017 8:17 AM (in response to bobcat_1857246)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).
-
3. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS
e.pratt_1639216 Sep 7, 2017 7:22 AM (in response to e.pratt_1639216)CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.
-
4. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS
bobcat_1857246 Sep 7, 2017 8:46 AM (in response to e.pratt_1639216)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.
-
5. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS
e.pratt_1639216 Sep 7, 2017 1:59 PM (in response to bobcat_1857246)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.