Jeremy from UCLA/USC found a but in the receive side of the UART_PACKET
module.  Instead of allocating a buffer, it was only allocating a buffer
pointer.  This was causing catastrophic failure when messages arrived up
from the UART.

There is a new release version on the web.  The only file that was changed
was UART_PACKET.c.  Line 44 was changed as described below.


http://tinyos.millennium.berkeley.edu/release/tos-latest.tar.gz 

Jason

-----Original Message-----
From:   Jeremy Elson [mailto:[EMAIL PROTECTED]] 
Sent:   Wednesday, February 14, 2001 1:52 AM
To:     [EMAIL PROTECTED]
Cc:     [EMAIL PROTECTED]
Subject:        [TOS] major bug in TOS4.3 UART_PACKET.c


hi,

deepak and i found a bug in TOS4.3's UART_PACKET.c this evening which, i
think, will prevent a mote from ever receiving packets from the UART.  (we
must be the first to use this capability?)
UART_PACKET.c line 44 is:
TOS_MsgPtr buffer;
but should be
TOS_Msg buffer;
"buffer" is the buffer into which bytes are written as they come in from the
UART, until 30 are collected (actually, until sizeof(TOS_Msg) are
collected).  Unfortunately, TOS_MsgPtr only allocates 2 bytes (or whatever
the pointer size on the atmel is), so the remaining 28 bytes of the packet
merrily overwrite variables nearby in the frame.
This bug manifested itself when writing to the UART failed to trigger any
action.  To make a (very) long story short, we found that "count" (the local
variable that keeps track of how many bytes have been received so far) was
getting corrupted.  Since it was never reaching 30, the upcall was never
being triggered.
We discovered that "count" was reliably getting clobbered on the 3rd byte of
the message when we'd send bytes to the UART one at a time.  Suddenly it
dawned on us that the packet itself must be overwriting its counter (which
was surely close-by in the frame!).  Checking the declarations verified this
when we found that only a 2-byte pointer to a buffer was being allocated
instead of a 30-byte buffer.
With this bug fixed, the mote-transceiver is now very close to being done.
We have a TinyOS program that relays packets both from UART->RFM and
RFM->UART.  All that's left is to write the glue layer that attaches my
packet-fragmentation code (written earlier for the Radiometrix driver) to
the serial port, using kfusd, the user-space device driver framework I've
mentioned on previous goatrock calls.  I'd do it tonight but I need sleep
:-)
Regards,
Deepak & Jeremy

Reply via email to