From 568973f6ec1c0db7c1777fe942d5e1c307c06451 Mon Sep 17 00:00:00 2001 From: George Oikonomou Date: Sat, 16 Jul 2016 17:48:25 +0100 Subject: [PATCH] Don't flush the CC2538 RF RX FIFO unconditionally After reading a frame, `read()` checks the status of the RX FIFO: * If an overflow is detected, the FIFO gets flushed * If there are more frames in the FIFO, the `cc2538_rf_process` will get polled again in order to read out the next frame. #1550 changed `read()`, which now performs the above check for non-poll mode, but it then flushes the FIFO unconditionally. Therefore, if there are two or more frames in the FIFO, they will get flushed before the `cc2538_rf_process` has had a chance to read them out. This results in missed frames. Reproducing this is trivial: Build a CC2538 sniffer and see how it will never show you .15.4 ACK frames. ACK reception completes while `read()` is still streaming the previous captured frame to the host. Upon completion, the FIFO will get flushed and the ACK will get lost. This pull proposes removing the unconditional flush and reverting to the original logic for non-TSCH operation. Pinging @thomas-ha here for input regarding poll mode. This pull sits on top of #1778 --- cpu/cc2538/dev/cc2538-rf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/cpu/cc2538/dev/cc2538-rf.c b/cpu/cc2538/dev/cc2538-rf.c index 6916524d2..1226e764d 100644 --- a/cpu/cc2538/dev/cc2538-rf.c +++ b/cpu/cc2538/dev/cc2538-rf.c @@ -823,8 +823,6 @@ read(void *buf, unsigned short bufsize) } } - CC2538_RF_CSP_ISFLUSHRX(); - return len; } /*---------------------------------------------------------------------------*/