-
Notifications
You must be signed in to change notification settings - Fork 220
Use locks to prevent race conditions in HCICordioTransport #402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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
|
LGTM! @gbr1 can you test this PR? |
Hi @swnf could you provide your test sketch? Thank you in advance |
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. |
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
lockForRead
andunlockForRead
method 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 ifhandleRxData
is 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).