BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
BoCo_1857246
Level 4
Level 4
10 replies posted 5 replies posted 10 questions asked

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?

0 Likes
1 Solution
Anonymous
Not applicable

CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.

View solution in original post

0 Likes
5 Replies
himam_31
Employee
Employee
50 likes received 25 likes received 10 likes received

Can you check if the priority for the BLE interrupts are set to the highest value?

Thanks,

Hima

0 Likes
Anonymous
Not applicable

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).

0 Likes
Anonymous
Not applicable

CyBle_SoftReset() is a function API to reset the BLE radio stack. Try using this to fix it.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes