Don't have an ultimate cause yet, but latest testing reveals this is NOT a v5.2 versus v4.0 issue but rather a debug build vs release build issue.
We don't have any extra logging turned on for our debug builds, so this difference isn't due to e.g. logging load.
But this diff sure hints at some part of the BLE stack getting starved or missing some timing.
We'll investigate further.
1 of 1 people found this helpful
It's really very hard to report stability issues regarding BLE stack.
The thing is the BLE stack output does not help too much.
Do you consider to produce more verbose debug information so at least
your developer can understand what is going on when people hit issues.
Since we didn't hear back from Cypress about any generally known issue with debug builds, we did run some experiments where we disabled all of our code except for the BLE thread. So the most obvious sources of resource starvation were removed. And we still see the issue.
Thanks for the link axel.lin_1746341
I'll see I can connect what we're seeing with that issue.
FYI, I also reported a issue that BLE silently stop working 1 year ago:
No further feedback, so I think the issue is still there.
So an update for this thread.
We were investigating BLE performance for debug builds specifically because our existing app (which worked reliably from android or iOS against wiced SDK versions before 5.2) was struggling to maintain a BLE connection. We were finally able to track this down to some ugly legacy code inside our source that was calling wiced_rtos_delay_milliseconds from inside a timer context ( a no-no with ThreadX). That manifested as a BLE stack failures because level 0 priority threads were being delayed.
So in short - this was not a BLE radio performance issue at all.