Fix NRF52 802.15.4 radio bug on CCA busy + add UDP/802154 driver to Nano 33 #2541
Conversation
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
Instead of using the Prorgammable Peripheral Interconnect on the NRF52's ieee802154 radio driver to retry CCA after a timer expires when it fails, use simple software logic instead. PPI invokes tasks in one peripheral (the radio) in response to an event in another (the timer), without requiring an interrupts serviced in software. PPI is probably _better_ but it wasn't working and I couldn't quite figure out why it wasn't. The software logic is just emulating what the PPI is supposed to do. Because this only gets triggered on a CCA failure, it's pretty cumbersome to debug. The best thing to do would be to use PPI as well as shortcuts to simplify the radio logic significantly, as well as likely improve transition time performance. I'll leave that for another adventure.
hudson-ayers
previously approved these changes
Apr 19, 2021
hudson-ayers
approved these changes
Apr 19, 2021
|
bors r+ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Pull Request Overview
This pull request accomplishes two main things:
What was the bug and how did you fix it?
Very simply, if ever in preparation for a transmission, the radio performed a CCA check and it failed (i.e. someone else is already transmitting on that channel), it's supposed to wait a specified period of time then retry. What was happening prior to this PR is there would never be a retry. So, if there was ever a CCA check failure, there could be no more transmission/receptions.
The problem was that while the timer was setup properly, the radio never got reconfigured in response to the timer expiring. I don't actually know the exact reason the strategy coded in the previous coding wasn't working, however, I just went with a more straight forward (though in the long run, worse) approach. At least it works.
Instead of using the Prorgammable Peripheral Interconnect on the NRF52's
ieee802154 radio driver to retry CCA after a timer expires when it
fails, use simple software logic instead. PPI invokes tasks in one
peripheral (the radio) in response to an event in another (the timer),
without requiring an interrupts serviced in software.
The best thing to do would be to use PPI as well as shortcuts to
simplify the radio logic significantly, as well as likely improve
transition time performance. I'll leave that for another adventure.
Why is this PR touching so many files?
Most of the changes are small refactoring in the NRF52-based boards. The NRF52's ieee802154 driver no longer requires a PPI, which had been passed down all the way from the board (it's not clear this was ever a good thing, this was required even for boards that used an nrf52 with no ieee802154 driver). So now, each board that relies on any nrf52 chip has a couple line changes removing the PPI initializing.
Testing Strategy
If anyone has ideas on how to test this reliably, please share. Meanwhile, I tested this by running the
examples/tests/udp/udp_sendapp fromlibtock-cwith a much smaller interval than the default (I used 50 ms) and waiting for a CCA to fail (probably because randomly some other 2.4GHz device was transmitting---maybe those Philips Hues I have are not completely useless after all). Without this change eventually transmissions stop. With the changes, they continue.To help my debugging I added some debug statements in the kernel to identify when a CCA failed, confirming that (a) this was the problem and (b) that my fix addresses the problem. You might consider adding similar debug statements if you want to test---again, it's otherwise pretty hard to tell whether you got a collision.
TODO or Help Wanted
Documentation Updated
Updated the relevant files in/docs, or no updates are required.Formatting
make prepush.