I thought the ResourceArbiter.immediateRequest symantic was that the
resource in question should be fully initilized following return from the
call. This should follow the same symantic as a ResourceArbiter.Request
and Granted. Prior to interrupts being allowed and the Granted being
signalled the resource is set up. To be consistent,
ResourceArbiter.immediateRequest should follow the same symantic.
If that premise is true. I would assert that the Atm128SpiP
implementation has a bug and should get fixed.
That would mean that the following as submitted is a work around and not an
actual fix.
thoughts?
On Fri, Nov 30, 2012 at 12:58 PM, Oldrine Lewis <ole...@sutron.com> 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
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
