[Tinyos-devel] Testing FTSP

[Miklos Maroti]

Guy,

I have spent quite a lot of time on this issue way back. I long
suspected that the timestamping is not working on the CC2420 because
of synchronization errors between the RX queue and timestamping queue.
Now looking at the code again I see the following:

In CC2420ReceiveP line 284:

284      if ( m_timestamp_size ) {
285        if ( rxFrameLength > 10 ) {
286          call PacketTimeStamp.set(m_p_rx_buf, m_timestamp_queue[
m_timestamp_head ]);
287          m_timestamp_head = ( m_timestamp_head + 1 ) % TIMESTAMP_QUEUE_SIZE;
288          m_timestamp_size--;
289        }
290      } else {
291        call PacketTimeStamp.clear(m_p_rx_buf);
292      }

why is the else separated from the embedded if? If you receive a short
frame then you completely screw up the timestamping queue! I think the
two ifs should be combined into a single one: if( m_timestamp_size !=
0 && rxFrameLength > 10 ).

By the way, I think the timestamping logic of acknowledgement frames
is broken (if they are not automatically handled by the CC2420, i.e.
software ACK is enabled). First, timestamps for received
acknowledgement frames are entered into the timestamp queue. However,
on line 285 you check for short packets and will not remove that
timestamp from the queue. Why is the "rxFrameLength > 10" check is
there? If to catch ack frames, then the proper bit should be checked
like on line 296 (again, you want to use the same logic to keep
everything in sync). Certainly when you enter timestamps into the
queue you do not check for length!!!

In CC2420TransmitP: event CaptureSFD.captured() line 313:

313      default:
314        if ( !m_receiving ) {
315          sfdHigh = TRUE;
316          call CaptureSFD.captureFallingEdge();
317          call CC2420Receive.sfd( time32 );
318          m_receiving = TRUE;
319          m_prev_time = time;
320          if ( call SFD.get() ) {
321            // wait for the next interrupt before moving on
322            return;
323          }
324        }
325
326        sfdHigh = FALSE;
327        call CaptureSFD.captureRisingEdge();
328        m_receiving = FALSE;
329        if ( time - m_prev_time < 10 ) {
330          call CC2420Receive.sfd_dropped();
331	  if (m_msg)
332	    call PacketTimeStamp.clear(m_msg);
333        }
334        break;

First of all, we have to realize that you can miss SFD interrupts one
way or the other since the CaptureSFD.captureXxxxEdge methods disable
and reset that interrupt line. Of course in the CaptureSFD.captured()
there are the fallthrough checks of "if( call SFD.get() ) break" calls
which catch these, but not all direction change is protected by these.
For example the one on line 327 is not and that could potentially kill
a rising edge SFD interrupt (causing missing packets if I see it
correctly). If you miss a rising edge interrupt then line 314 is
completely wrong! I think that need to be changed to "if (
!m_receiving && sfdHigh == FALSE )". Also, I would protect lines 326
through 334 with an "if( sfdHigh == TRUE )" just to be safe.

I am not saying that these are causing the problem, just that these
are problem areas. But even if the code does not mess up the time
stamps, there is still a race that you cannot circumvent and actually
this could be the cause of all problems. Ok, suppose that you are
receiving three messages: A, B, C. You timestamp A and start to
download it from the RXFIFO. Then the radio chip receives the SFD for
message B and makes a timestamp, an error happens (e.g. CRC) and the
message is dropped. Then the radio chip receives message C correctly
which is again time stamped. After all this A is properly downloaded
from the RXFIFO. Now you have 2 timestamps (for B and C) and 1 message
in the RXFIFO (could be either B or C). How do you decide which
timestamp is correct? I think the timestamp should be set only if
there is a single timestamp in the timestamp queue AND a the RXFIFO is
empty (that is this was the only message timestamped).

Brano, if you have some time, please try to implement these. Probably
the last one would be the most important, but not sure. Maybe we can
catch this bug.

Miklos