You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A function is sending data over BLE.
This data is received from an I2C connected peripheral (in this case the uBlox GNSS chip). I only mention this because I see an Open issue to do the clock and I2C & BLE usage.
The ISSUE:
On some occasions (not clear when) the BLE HCI gets stuck in an infinite loop.
The BLE device is still visible and can be connected to however the F4 core is stuck running BLE Poll.
The call stack looks like so:
→ sendPVTData (my function to send data received from I2C peripheral over BLE)
This should cause a similar issue immediately. The F4 core appears to execute the BLE commands sluggishly eg Poll appear to takes ~100 times longer The slow reaction of the F4 seems to cause the core to get stuck in the cycle above?
Set Optimize to Fastest (-O3) with LTO
This issue is almost gone, it appears twice in ~60 hours of testing It only appeared in a cluttered BLE environment with multiple connection requests.
Expected Behaviour
_pendingPkt should decrease to less than _maxPkt ?
This is a guess, I will expand as I dig deeper.
The text was updated successfully, but these errors were encountered:
Background
OS: Mac OS Sonoma 14.5
IDE: Arduino IDE
BOARD SETTING: Discovery
VARIANT SETTING: STM32WB5MM-DK
OPTIMISATION: None
C RUNTIME LIBRARY: Newlib Nano (default)
UPLOAD METHOD: SWD
HARDWARE: STM32WB5MM-DK Discovery board
WIRELESS STACK: stm32wb5x_BLE_HCILayer_fw.bin
VERSION: 1.20.0
EXTRA HARDWARE: uBlox ZED F9P (I2C connection)
PACKAGES:
Issue Description
A function is sending data over BLE.
This data is received from an I2C connected peripheral (in this case the uBlox GNSS chip).
I only mention this because I see an Open issue to do the clock and I2C & BLE usage.
The ISSUE:
On some occasions (not clear when) the BLE HCI gets stuck in an infinite loop.
The BLE device is still visible and can be connected to however the F4 core is stuck running BLE Poll.
The call stack looks like so:
→ sendPVTData (my function to send data received from I2C peripheral over BLE)
→Some BLE characteristic stuff……
→ HCIClass::sendAclPkt
→ While ( _pendingPkt >= _maxPkt )
This while loop is never exited
→ HCIClass::poll
→ HCISharedMemTransportClass::available()
**→ always returns false (
_read_index
=_write_index
)Issue Reproduction
This should cause a similar issue immediately.
The F4 core appears to execute the BLE commands sluggishly eg Poll appear to takes ~100 times longer
The slow reaction of the F4 seems to cause the core to get stuck in the cycle above?
This issue is almost gone, it appears twice in ~60 hours of testing
It only appeared in a cluttered BLE environment with multiple connection requests.
Expected Behaviour
_pendingPkt should decrease to less than _maxPkt ?
This is a guess, I will expand as I dig deeper.
The text was updated successfully, but these errors were encountered: