[Tinyos Core WG] SPI discussion

[David Moss]

Phil -

I see what you're saying now.

The microcontroller is the SPI master and will drive the transaction. The
implementation of the driver clearly shows the Receive interrupt flag being
polled from the microcontroller to determine if more data was received from
the device - but that's valid only when the SPI is enabled.  Although the
CC2420 is not explicitly powering down the SPI, you must be correct in the
assumption that the SPI must be getting powered down, because that interrupt
flag no longer toggled.  And this would occur from the CC2420SpiImplP
component prematurely calling its Spi.release().

I agree we should do some tests to verify we can do away with some of
unnecessary CC2420 SPI-specific logic.  Currently, I think the main culprit
is the fact that the Spi is automatically released from each component
(TransmitP, ReceiveP) when their StdControl.stop()'s get called.  Further
logic is necessary verify the device is still powered after getting results
from the SPI, to know whether or not those results are valid.

-David



-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Saturday, May 12, 2007 8:40 AM
To: David Moss
Subject: Re: [Tinyos Core WG] SPI discussion

On May 11, 2007, at 11:53 PM, David Moss wrote:

> Currently, ReceiveP doesn't know *in advance* that the chip is  
> going to be
> powered down.  So, it receives an interrupt to start reading from  
> the SPI
> bus and begins to read while the chip, at some other level, is  
> about to shut
> down.  From what I remember, the actual SPI bus driver at the  
> lowest level
> sits in a while loop polling some register that's awaiting data:
>
> Msp430SpiNoDmaP.nc:
> [100]     while( !call Usart.isRxIntrPending() );
>
>
> HplMsp430Usart0P.nc:
>   async command bool Usart.isRxIntrPending(){
>     if (IFG1 & URXIFG0){
>       return TRUE;
>     }
>     return FALSE;
>   }
>
> If the data never comes, then Usart.isRxIntrPending() doesn't get  
> flipped,
> and the node locks up.

I think I'm still confused.

As far as I understand it, if you are in the midst of an SPI transfer  
and turn off the SPI *peripheral*, the transfer should still occur:  
it's clocked from the MCU. The data transferred, however, will be  
corrupted. On the send side, the peripheral clearly won't get it and  
on the receive side it will be garbage.  The failure occurs because  
the SPI bus itself is turned off; when this occurs, it no longer  
issues interrupts.

Am I incorrect on this?

So what I was asking was this: would one way to solve this be to take  
the task spin logic out of the SPI driver and instead check after SPI  
operations if the chip has been turned off? So rather than delay  
turning off the chip to when all operations completes, just let the  
operations complete and if the chip is turned off when they do,  
discard the result? This would be similar to how the cancel logic works.

Phil