[Tinyos-help] sendDone getting lost

Philip Levis pal at cs.stanford.edu
Fri Sep 9 15:32:37 PDT 2005


On Fri, 2005-09-09 at 15:11 -0700, Sumit Rangwala wrote:
> At 9:06am on Sep 9, electrons from Philip Levis conveyed:
> 
> > On Thu, 2005-09-08 at 22:38 -0700, Sumit Rangwala wrote:
> > > Hi 
> > >    I found that under heavy traffic sometime I don't receive 
> > > a sendDone after a SendMsg.send(). As I am using QueuedSend 
> > > the code breaks as the queue eventually gets full. 
> > > 
> > > The only case when this can occur is if a high priority 
> > > interrupt occurs exactly at the same time when the interrupt 
> > > for sendDone is generated.
> > > 
> > > I observed this long ago with mica2 and now I observe the 
> > > same on tmote. I was wondering if this has been solved or if 
> > > there are smart work-arounds for it. 
> > 
> > It sounds like a bug.
> > 
> > Can you be more specific? Terms like "high priority interrupt" are a bit
> > confusing, as the atm128 (mica2) doesn't have interrupt priority levels.
> 
> Currently I am working on Tmote so the controller is msp430
> 
> > Specifically:
> > 
> > 1) What version of TinyOS are you using?
> 
> CVS version checked out during the last week of July 2005. 
> (tinyos 1.1.14)
> 
> > 2) What communication stack are you using (GenericComm vs Promiscuous)?
> 
> Promiscuous 
> 
> > 3) What interrupt sources seem to cause this problem?
> 
> I don't know what causes it. But I verified that a sendDone 
> isn't getting called after send. Again this occurs once in 
> 50,000 send and when the traffic is high enough to saturate 
> the network capacity and there is fair amount of traffic on 
> the uart/usb too. 
> 
> 
> > 
> > I know there have been reports of the CC2420 stack issuing *two*
> > sendDone events (for which there have been fixes committed), but
> > *missing* sendDone events is something else entirely.
> 
> My version of the code includes the fixes for the two 
> sendDone events problem. 
> 

I'm actually rewriting the CC2420 stack for 2.x, and am working on this
problem right now; good to know it exists in the 1.x stack so I didn't
create it. 

I see it happen when two nodes are both trying to send packets as
quickly as possible, and something causes them to both enter the send
state at the same time; for some reason, neither actually sends, to the
SFD pin doesn't go high and they both just hang. However, if a node
successfully transmits a packet (e.g., you reset *either* of them), then
reception causes the SFD pin to go high and operation resumes.

Is this the behavior you see? Two nodes, both hang on transmissions, you
reset either one and both resume?

Phil




More information about the Tinyos-help mailing list