Oldrine, Thanks for tracking it down. I guess this bug might affect components relying on the SPI other than the radio stack. I think your solution should work without breaking anything.
A bit nicer solution would be implementing ResourceConfigure.configure in Atm128SpiP that are called by the arbiter when a request/immediate request went through. That's how it's done on the msp430. There is protection against the potential race conditions in ArbiterP already. I can go ahead and commit your fix if you wish. Janos On Fri, Nov 30, 2012 at 2:58 PM, Oldrine Lewis <[email protected]> wrote: > Recently, I have been experiencing frequent lockups with the IRIS nodes. I > discovered that the lockup occurred in Atm128SpiP.nc, looping infinitely > on while ( !( SPSR & 0x80 ) );**** > > ** ** > > This bug, manifests if a task calls Resource.immediateRequest(), and an > interrupt occurs after the task calls ResourceArbiter.immediateRequest[ id > ]() , but before calling startSpi(). At this moment, the task already has > the handle for the resource and hence the ISR can also access the resource. > **** > > If the interrupt tries to use the SPI, since it has locked the resource it > will go ahead and use the SPI, causing a lockup**** > > **** > > I recommend encapsulating the call to immediateRequest and start SPI in a > critical section. I have commented my observations below **** > > ** ** > > async command error_t Resource.immediateRequest[ uint8_t id ]() **** > > {**** > > atomic **** > > {**** > > error_t result = call ResourceArbiter.immediateRequest[ id > ]();**** > > //what if i get an interrupt here and the interrupt > wants to use the SPI**** > > //the resource is already allocated so it will return > TRUE. But the spi might be turned off**** > > //this will cause the SPI driver to lockup waiting at > while( !( SPSR & 0x80 ) ) ;**** > > if ( result == SUCCESS ) **** > > {**** > > startSpi();**** > > }**** > > return result;**** > > }**** > > }**** > > ** ** > > Please advice **** > > ** ** > > Thanks,**** > > Lewis**** > > ** ** > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
