BLE system gets stuck in "CyBle_GattsWriteRsp()"

[brmec_2962686]

I have a system where the BLE stack occasionally gets stuck inside of CyBle_GattsWriteRsp(). I've managed to trace the execution until it enters this function and confirmed that it doesn't return until the system watchdog resets after a few hundred milliseconds.

Here's how the project is structured:

• Main loop performs operations such as I2C and CyBle_ProcessEvents().
• SysTick performs short periodic actions every 1ms. (Priority: 2)
• DMA interrupt performs a few milliseconds of buffer processing around every ~10ms. (Priority: 3)
• BLE BLESS interrupt has priority 2.

There are three watchdogs active,

• Main Loop (256ms timeout)
• SysTick (4ms)
• DMA Interrupt (32ms)

All watchdogs trigger the general watchdog interrupt when they expire. My handler prints which timer expired and then loops. The watchdogs trigger a hardware reset if the watchdog interrupt isn't handled three times, I cause this by never exiting the handler once triggered. (nearly same as a direct watchdog triggered reset, but allows me to print out system state)

The BLE minimum connection interval I'm using is 30ms. I verified that CyBle_ProcessEvents() gets called multiple times within the connection interval, even when pending I2C actions and interrupts queue up together. It typically gets called around every 5-10ms at the longest.

I traced through the system and found that CyBle_ProcessEvents() calls the registered BLE event handler passed on stack init. The issue seems to be fairly rare, but occasionally when I process a CYBLE_EVT_GATTS_WRITE_REQ event, program execution enters the CyBle_GattsWriteRsp() call and remains there until the 256ms main loop watchdog resets the system. Note that interrupts are operating correctly since their watchdogs aren't what resets the system.

I can't check error flags returned from the BLE stack since the function never returns. My SysTick interrupt does occasionally call CyBle_GattsWriteAttributeValue() and CyBle_GattsNotification() and I thought that one of these occurring when main is in CyBle_ProcessEvents() could be causing the lockup. I instrumented the system so I could see when these calls occur and it doesn't appear that the lockup is triggered by one of these functions being called from an interrupt during CyBle_GattsWriteRsp().

I think that the lockup is a symptom of a larger issue with how I am handling the BLE stack. Sometimes the device momentarily delays or stops responding to BLE connections even though CyBle_ProcessEvents() is still being called regularly.

If anyone has any ideas to try I would be really grateful, I can't post the actual project here but I'm providing a stripped version of my BLE handler C file.

[Yugandhar · Accepted solution]

Hello,

1. Please keep the Bless interrupt to highest priority i.e., priority to 0 (highest).

2. Don't write big code inside ISR. Instead, set a variable inside ISR and check the variable status and call the function in main loop.

3. Call CyBle_ProcessEvents in regular intervals. If any custom function is there which will consume more time for execution, please call CyBle_ProcessEvents inside it. May be any of your function for I2C write will be taking more time, if then try call CyBle_ProcessEvents inside and see whether the issue fixes.

Thanks,

P Yugandhar.

[brmec_2962686]

Thanks, but I'm already doing much of what you suggest.

I mentioned that I've already instrumented the worst-case runtime of all I2C and interrupts and found that they are not the issue. CyBle_ProcessEvents is called regularly in a smaller period than the minimum connection interval.

The BLESS interrupt shares the highest priority in use except for the watchdog handler which halts and resets the system. (no need for any other interrupt to preempt) The SysTick interrupt shares the same priority level and cannot preempt the BLESS interrupt if it is executing, it can however delay it for about 100us.

All work left in interrupts cannot be extracted to the main loop due to critical timing dependencies (e.g. DMA switching and processing half of a short double buffer) these interrupts occur at the low priority, so they don't interfere with more important tasks such as BLESS. I've also determined that they compete in small enough timeframes to avoid delaying the main loop beyond the BLE minimum connection interval.

I was able to track the execution of the system and directly see that CyBle_ProcessEvents is still being called even while the BLE stack appears to be ignoring requests made by a connected device. I noticed that during these periods, CyBle_ProcessEvents returns very quickly (4us) suggesting that very little work is being performed. It appears that something is upsetting the internal BLE stack.

Is there any way of getting detailed stack state? The basic status macro/function only returns generic info such as idle/connected. Does anyone have suggestions on events that I should add to the BLE event handler? At the moment it's only the bare minimum required for the project.

[Yugandhar]

Hello,

Can you please share the project so that we can reproduce the issue and find out the root cause. ( If not complete project please share a simplified project).

Thanks,

P Yugandhar.

[user_2457466]

I am in a similar situation. Just with CyBle_ProcessEvents(), which seems to crash and never return.

So I will follow this post and hope this gets resolved.

br,

Martin

[Yugandhar]

Hello,

Can you please check the query 7 in the below PSoC 4 Trouble shooting KBA link.

PSoC 4 BLE Troubleshooting Guide – KBA220490

Please let me know if this helps.

Thanks,

P Yugandhar.