Use locks to prevent race conditions in HCICordioTransport#402
Merged
facchinm merged 1 commit intoarduino-libraries:masterfrom Jul 1, 2025
Merged
Use locks to prevent race conditions in HCICordioTransport#402facchinm merged 1 commit intoarduino-libraries:masterfrom
facchinm merged 1 commit intoarduino-libraries:masterfrom
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #402 +/- ##
==========================================
- Coverage 15.30% 15.25% -0.05%
==========================================
Files 28 29 +1
Lines 3666 3678 +12
==========================================
Hits 561 561
- Misses 3105 3117 +12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Memory usage change @ b14172f
Click for full report table
Click for full report CSV |
Contributor
|
LGTM! @gbr1 can you test this PR? |
|
Hi @swnf could you provide your test sketch? Thank you in advance |
Contributor
Author
|
Hi @gbr1, I'm afraid I don't have any test sketch for this PR. I've tested this PR in a really large and complicated PlatformIO project and the issue only occurred randomly after multiple hours of data transmission. It's probably best if you just test any of the peripheral example sketches and make sure it is still working. I'm not aware of a way to trigger the issue. |
|
@facchinm I tested on Science Kit R3 (RP2040 and ESP32) and some examples of Nano BLE Sense R2. |
fabik111
reviewed
Oct 7, 2025
| return; | ||
| } | ||
| { | ||
| mbed::CriticalSectionLock critical_section; |
Contributor
There was a problem hiding this comment.
Hello, this line causes crashes on Opta if using BLE with Ethernet. On Opta and Portenta H7 the HCICordioTransportClass::handleRxData is called in an ISR context, so the critical section is not needed.
Fix at #412
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sometimes my BLE connections to my nrf52840 randomly stopped working. I've noticed that with
BLE.debug(Serial)the HCI transport returned truncated packets in these situations. I suspect that this issue might be caused by concurrent access to the rx buffer in the cordio HCI transport. The Arduino core seems to use critical section locks while interacting with the ring buffers.This MR introduces a
lockForReadandunlockForReadmethod on the HCITransport to aquire a critical section lock. A Mutex might make more sense, but requires additional build flags and might not be available ifhandleRxDatais called from an interrupt handler.I've considered the following alternatives to the new methods:
read(). This naive approach works, but is very inefficient.readBytes()method similar to Arduino's stream method which handles the lock/unlock. This approach is more difficult to implement because you don't know beforehand how large a packet is. You will still need multiple calls toreadBytes()(including unnecessary lock/unlock calls).