5 Replies Latest reply on Sep 7, 2017 1:59 PM by epr_1639216

BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

BoCo_1857246 Aug 25, 2017 8:23 AM

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?

1. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

himam_31 Sep 5, 2017 2:37 AM (in response to BoCo_1857246)

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

Thanks,
Hima
Like Show 0 Likes(0)

Actions
2. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

epr_1639216 Sep 5, 2017 8:17 AM (in response to BoCo_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).
Like Show 0 Likes(0)

Actions
3. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

epr_1639216 Sep 7, 2017 7:22 AM (in response to epr_1639216)

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

Actions
4. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

BoCo_1857246 Sep 7, 2017 8:46 AM (in response to epr_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.
Like Show 0 Likes(0)

Actions
5. Re: BLE stack issuing permanent CYBLE_EVT_STACK_BUSY_STATUS

epr_1639216 Sep 7, 2017 1:59 PM (in response to BoCo_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.
Like Show 0 Likes(0)

Actions

Go to original post