[riot-notifications] [RIOT-OS/RIOT] drivers/cc2538_rf: fix deadlock when receiving too fast. (#16716)

José Alamos notifications at github.com
Mon Aug 9 11:53:55 CEST 2021

The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions.

### Contribution description
This PR fixes a deadlock in `cc2538_rf` caused by frames being received too fast.
The reasons for this deadlock are:
1. While sending with CCA the RX chain should be disabled, which was not the case. When frames were received during CCA, there was a wrong state transition in the `submac` that ended with `submac->tx`  being not released. Therefore, the `submac` would always return `-EBUSY`.
2. The driver logic was always following the internal FSM states, although the Reference Manual (Section 23.11) explicitly says to not do that:

> Although it is possible to read the state of the FSM, do not use this information to control the program flow
in the application software

I was able to trigger cases were the FSM state was not defined but the radio was still fully functional. Therefore, I think we should follow the datasheet here.

Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes

### Testing procedure
It's very hard to reproduce, but here's a way: Take a RIOT BR, a `cc2538_rf` and another node (I used a `nrf52840dk`). When all nodes get prefix, ping from the CC2538 to the other non-BR node (use 1024 kB and short intervals such as 200 ms). Every now and then reset the target node. At some point, the `cc2538_rf` won't be able to send more frames and the TX counter will be increasing non-stop, although no frames get out of the radio. The pktbuf will be full of garbage frames.

With this PR, it's not possible to reproduce this scenario.
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output

### Issues/PRs references
None so far.
Examples: Fixes #1234. See also #5678. Depends on PR #9876.

Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.

You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * drivers/cc2538_rf: disable RX detection during CCA
  * drivers/cc2538_rf: don't poll internal FSM state

-- File Changes --

    M cpu/cc2538/include/cc2538_rf.h (2)
    M cpu/cc2538/radio/cc2538_rf_radio_ops.c (61)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210809/4407be2d/attachment.htm>

More information about the notifications mailing list