From fd3adeaabe1a70202db28f6f246e8cbbb83d2f06 Mon Sep 17 00:00:00 2001 From: Tomasz Bursztyka Date: Mon, 8 Feb 2016 15:13:21 +0100 Subject: [PATCH] cc2520: 7th bit of the packet length should not be interpreted 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 --- drivers/802.15.4/cc2520.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/802.15.4/cc2520.c b/drivers/802.15.4/cc2520.c index 0e528a9dd05..1c695c966c4 100644 --- a/drivers/802.15.4/cc2520.c +++ b/drivers/802.15.4/cc2520.c @@ -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; }