michaelh/zephyr
1
0
Fork 0
Code Releases Activity

cc2520: 7th bit of the packet length should not be interpreted

Browse source 
There is no such thing as being out of sync.
1 - RX FIFO is always flushed before receiving anything.
2 - So whatever comes in, if it was rejected the hardware would not set
FIFOP high (we are on high threshold, see page 83).
3 - According to 802.15.4 specs, length cannot be bigger than 127, so
7th bit of the length should never be set. However, and for some reason,
it happens to be set (noise, memory glitch?). According to datasheet
page 75, masking this bit is useful then. The hardware does it for
itself when filtering, and that does not affect the buffer content, so
it's also up to the driver to mask it as well.

Change-Id: I30b878852076c0c9d3a92b490aaf37f826ab4541
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This commit is contained in:
Tomasz Bursztyka 2016-02-08 15:13:21 +01:00
commit fd3adeaabe
1 changed files with 7 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

13
drivers/802.15.4/cc2520.c
View file

@ -577,6 +577,12 @@ static void getrxdata(void *buf, int len)
static void getrxbyte(uint8_t *byte)
{
cc2520_read_fifo_byte(byte);
/* Masking useless 7th bit
* Hardware does it for itself when filtering is on for instance
* See end of page 75 of datasheet.
*/
*byte &= 0x7f;
}
static inline bool strobe(uint8_t regname)
@ -851,12 +857,7 @@ static int cc2520_read(void *buf, unsigned short bufsize)
DBG("%s: Incoming packet length: %d\n", __func__, len);
/* Error cases:
* 1 -> out of sync!
* 2 & 3 -> bogus length
*/
if ((len > CC2520_MAX_PACKET_LEN) ||
(len - FOOTER_LEN > bufsize) ||
if ((len - FOOTER_LEN > bufsize) ||
(len <= FOOTER_LEN)) {
goto error;
}