[BT] Reset BTProcessLock when immediateBTAction can't take the device semaphore (#2314)
immediateBTAction() sets BTProcessLock=true and stops the scan before an outbound BLE action, and resets it on the success path and the "BLE busy" path — but the branch where semaphoreCreateOrUpdateDevice can't be taken left it true. Under scan contention that wedges the BLE scanner/connect subsystem until a restart (same BTProcessLock-mishandling family as the long-uptime NimBLE scanner hang). Reset it on that branch too. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
7904d49dbe
commit
e7411d2000
1 file changed
+4
@@ -1692,6 +1692,10 @@ void immediateBTAction(void* pvParameters) {
|
|||||||
xSemaphoreGive(semaphoreCreateOrUpdateDevice);
|
xSemaphoreGive(semaphoreCreateOrUpdateDevice);
|
||||||
} else {
|
} else {
|
||||||
THEENGS_LOG_ERROR(F("CreateOrUpdate Semaphore NOT taken" CR));
|
THEENGS_LOG_ERROR(F("CreateOrUpdate Semaphore NOT taken" CR));
|
||||||
|
// Release the process lock we took above; otherwise a transient
|
||||||
|
// semaphore-contention failure here leaves BTProcessLock=true and
|
||||||
|
// wedges the BLE scanner/connect subsystem until a restart.
|
||||||
|
BTProcessLock = false;
|
||||||
}
|
}
|
||||||
|
|
||||||
// If we stopped the scheduled connect for this action, do the scheduled now
|
// If we stopped the scheduled connect for this action, do the scheduled now
|
||||||
|
|||||||
Reference in new issue
Block a user