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
Over the past week, I've occasionally been getting stack overflow errors from NimBLE. I've been working on Heltec VME290 when seeing this. The error occurs during the initial get config stage of connecting to my Android device. I have struggled to reliably repeat this, as flashing a new build seems to resolve the issue, at least temporarily.
Today on Discord, a user has reported a similar NimBLE stack issue when using the ATAK plugin. In their case, the canary is triggered later in use, not on the initial connection. They were able to reliably reproduce it across several different ESP32 devices. The issue for them affects builds at least as far back as 2.5.3, which was the oldest build they tested.
If I have correctly understood the discussion on Discord, the likely solution is to increase CONFIG_BT_NIMBLE_HOST_TASK_STACK_SIZE. I'm not confident enough myself though to know how much of an increase would be appropriate, or what potential negative impacts this could have.
I found a reference to someone from espressif indicating that the stack size should be increased to 8192 when verbose logging is enabled on NimBLE. Given our closer to MTU sized payloads and frequency of transmission, that figure could be a good starting point.
Category
BLE
Hardware
Not Applicable
Firmware Version
2.5.9.28b469d
Description
Over the past week, I've occasionally been getting stack overflow errors from NimBLE. I've been working on Heltec VME290 when seeing this. The error occurs during the initial get config stage of connecting to my Android device. I have struggled to reliably repeat this, as flashing a new build seems to resolve the issue, at least temporarily.
Today on Discord, a user has reported a similar NimBLE stack issue when using the ATAK plugin. In their case, the canary is triggered later in use, not on the initial connection. They were able to reliably reproduce it across several different ESP32 devices. The issue for them affects builds at least as far back as 2.5.3, which was the oldest build they tested.
If I have correctly understood the discussion on Discord, the likely solution is to increase
CONFIG_BT_NIMBLE_HOST_TASK_STACK_SIZE
. I'm not confident enough myself though to know how much of an increase would be appropriate, or what potential negative impacts this could have.Relevant log output
The text was updated successfully, but these errors were encountered: