cpu/cc2538: mask length byte before checking CRC [backport 2024.10] #21038
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.
Backport of #20998
Contribution description
This is a follow-up for #20956.
I found that the solution applied there wasn’t robust, because when receiving short packets quickly after each other the RX FIFO might be filling up with a new packet while handling the IRQ. Then, the number of bytes in the FIFO will be bigger than the packet length of the first packet. Even though the second packet will be dropped anyway, the length of the first packet can still be correctly obtained from the length byte in the packet.
Namely, from section 23.9.5.1 of the CC2538 User’s Guide it follows that indeed the radio will mask out bit 7 of the length byte:
Then, it continues to fill the RX FIFO with this number of bytes as follows from section 23.9.3:
This means that with this approach, always the correct byte is used for checking the CRC result.
Testing procedure
Flashed this PR on two devices, and tested with long packets that the error from #20955 didn't appear. When testing short packets quickly after each other, in case the old
crc_loc
was not equal to the correctedpkt_len
, thepkt_len
had the expected number of bytes, whilecrc_loc
was usually a couple bytes more than that.Issues/PRs references
This is a more proper fix for #20955.