- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a BLE project that communicates with a MAC OS using the BLE MIDI protocol. I have had this working for several years on the Broadcom (now Cypress) CYW20737S, but I'm porting it to the PROC CYBLE-012011-00. I stress this, to show that I trust the client implementation in the MAC OS.
The PROC device is configured to transmit every half second for testing. On the PROC device, after 5 or 10 minutes of operation, the AppCallBack() is called with event CYBLE_EVT_STACK_BUSY_STATUS, and eventParam 0x01, but the stack then never makes a corresponding CYBLE_EVT_STACK_BUSY_STATUS with eventParam 0.
Once in this busy state, my calls to CyBle_GattsNotification() (every half second) return CYBLE_ERROR_INVALID_OPERATION.
The only way I can find to get out of this state, is from the MAC to disconnect and reconnect the BLE.
Again, I stress that on the CYW20737S implementation it will run forever with no issues, so I trust the MAC client.
What would make the BLE stack permanently become busy, and how can I fix it?
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you check if the priority for the BLE interrupts are set to the highest value?
Thanks,
Hima
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As hima 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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.