I have been experiencing some lockups with the radio recently. The
problem seems to occur when RandomCollisionLayerP::SubSend.send() is
called by MessageBufferLayerP, but RandomCollisionLayerP never calls
RF230DriverHwAckP::RadioSend.send(). MessageBufferLayerP ends up waiting
forever for SendDone() to be signaled.
I debugged the code and it seems that the following sequence of events
could be the likely cause
The following sequence of events seems to be trigger
* RandomCollisionLayerP::SubReceive.receive() is signaled by
RF230DriverHwAckP
* After executing the line if( state == STATE_READY ),
RandomCollisionLayerP::RadioSend.send() Interrupts the receive routine
* Since state == STATE_READY ,
RandomCollisionLayerP::RadioSend.send() proceeds and sets, state =
STATE_TX_PENDING_FIRST
* RandomCollisionLayerP::SubReceive.receive() resumes and
overwrites the state ( state = STATE_BARRIER)
* The radio is essentially locked at this moment
Solution:
Protect RandomCollisionLayerP::RadioSend.send() and
RandomCollisionLayerP:: SubReceive.receive() from race conditions
tasklet_async command error_t RadioSend.send(message_t* msg)
{
atomic
{
if( state != STATE_READY || ! call RadioAlarm.isFree() )
{
return EBUSY;
}
state = STATE_TX_PENDING_FIRST;
}
txMsg = msg;
call RadioAlarm.wait(getBackoff(call
Config.getInitialBackoff(msg)));
//post DBG_Snd();
atomic bIsTxRxExec = FALSE;
return SUCCESS;
}
tasklet_async event message_t* SubReceive.receive(message_t* msg)
{
if( delay > 0 )
{
atomic
{
if( state == STATE_READY )
{
call RadioAlarm.wait(delay);
state = STATE_BARRIER;
}
else
{
state |= STATE_BARRIER;
}
}
}
I have noticed extensive use of the norace keyword, while that itself
will not cause problems, it might fail to draw attention to variables
that need more attention
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
