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 corrected pkt_len, the pkt_len had the expected number of bytes, while crc_loc was usually a couple bytes more than that.

Issues/PRs references

This is a more proper fix for #20955.