ble/nimble: bump version to 9d4bda2#11273
Conversation
|
I'd like to put this PR on hold until apache/mynewt-nimble#392 is also merged into NimBLE. This way we save one version bump PR... |
793f391 to
f849dfd
Compare
|
apache/mynewt-nimble#392 was merged, so I updated the NimBLE version in this PR once more. The PR is now ready to be tested and merged. |
|
Turns out that NimBLE appears to have new issues since apache/mynewt-nimble#414. When running out |
|
I still have failed assertion with packagelength > 2518 on client. Also when flooding the client does not print to pyterm after 23 packets - but it recovers after resetting the server. Did not debug this further. |
|
Yes, thats exactly the faulty behavior. The problem ist, that somehow the internal send buffers are not processed properly, so that the |
b011a28 to
0fa0fb9
Compare
|
Alright, found the issue: the application code around the send function was flawed. Updated this PR:
This PR should be ready for final review now. |
|
Great, |
0fa0fb9 to
e172c80
Compare
|
you could just try the |
ghost
left a comment
There was a problem hiding this comment.
Tested with my phone too. All tests work as desired and code looks good.
ACK
|
Awesome, thanks a lot! |
Contribution description
The current NimBLE version used has an issue when receiving large data packets via L2CAP COC. This was fixed upstream (apache/mynewt-nimble#378). So this PR updates NimBLE to include those fixe(es).
Testing procedure
Once #11235 is merged, use that test application to verify that sending/receiving large data packets at a high rate is working properly.
Issues/PRs references
fixes apache/mynewt-nimble#373
depends on #11235 (for proper testing)