Ok, thanks! I really would like to know how it works in your situation before I commit to the mainline. Miklos
On Wed, Dec 12, 2012 at 11:36 PM, Oldrine Lewis <[email protected]> wrote: > > > Hi Miklos, > > A few other changes I had made to my program structure, seem to almost > eliminiate the possibility of hitting the SPI lock situation. I will have to > rerun the older version, of my software to replicate the previous situation > to test the fix. I have a release scheduled soon and will get to the test the > fix asap. > > Regards, > Lewis > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Miklos Maroti > Sent: Monday, December 10, 2012 2:55 PM > To: Oldrine Lewis > Cc: Eric Decker; [email protected]; Philip Levis; Janos > Sallai > Subject: Re: [Tinyos-help] IRIS SPI lockup > > Hi Lewis, > > Did you have a chance to check if this fixes your race condition? Does > the SPI work reliably now? > > Miklos > > On Thu, Dec 6, 2012 at 12:59 PM, Miklos Maroti <[email protected]> > wrote: >> Excellent. Thanks! Miklos >> >> On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis <[email protected]> wrote: >>> Hi Miklos, >>> Thanks for the updates. I just downloaded the new files. Will test and keep >>> you posted. >>> Thanks, >>> Lewis >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of Miklos >>> Maroti >>> Sent: Wednesday, December 05, 2012 1:35 PM >>> To: Eric Decker >>> Cc: Oldrine Lewis; [email protected]; Philip Levis; Janos >>> Sallai >>> Subject: Re: [Tinyos-help] IRIS SPI lockup >>> >>> Dear Lewis, >>> >>> Thanks for finding this bug. Just to clarify, this happens ONLY if the >>> Resource.immediateRequest is called from a task and then from an >>> interrupt AND they use the SAME client id. Otherwise, the second call >>> will return with fail, no? We have discussed this with Janos Sallai, >>> and he says that the best option would be to initialize the SPI with >>> the ResourceConfigure interface as Eric has also suggested. >>> >>> I have put together a patch that fixes this (includes some typo fixes >>> in tep108): >>> >>> https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c >>> >>> Lewis, can you please try this out if this works for you? (It actually >>> reduces the code too) >>> >>> Best, >>> Miklos >>> >>> On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker <[email protected]> wrote: >>>> >>>> >>>> On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis <[email protected]> wrote: >>>>> >>>>> Atm128SpiP.nc seems to make separate calls ( sequentially) to the >>>>> ResourceArbiter and calls for initializing the SPI. >>>>> >>>>> In case of Resource.request (), startSpi() is called before the call to >>>>> ResourceArbiter.request(), This ensures that the SPI will always be >>>>> initialized before Resource.granted() is signaled. >>>> >>>> >>>> The problem with Atm128P is it doesn't use the configurator call out from >>>> the Arbiter. The whole point behind the configurator call out is to avoid >>>> this timing window when h/w is configured. >>>> >>>> The reason that the Atm128P use of request/granted "works" is because it >>>> cheats. It looks to see if someother entity is using the device and if >>>> not >>>> it starts the SPI. Then it calls ResourceArbiter.request. Which means >>>> that it is touching the resource without really owning it. Not exactly >>>> proper. >>>> >>>> Request/Granted should also use the configuration interface. That is why >>>> it is there. It lets the Arbiter configure the hardware properly >>>> according >>>> to what the driver wants prior to switching the resource state to other >>>> than >>>> RES_CONTROLLED which let's interrupts in. >>>> >>>> >>>> >>>>> Incase of Resource.immediateRequest(), the resource is first locked and >>>>> only if the lock succeeds, is the SPI initialized. This sometime leads to >>>>> an >>>>> uninitialized SPI being used >>>> >>>> >>>> Thinking about this as locking the resource is kind of sideways. It isn't >>>> like we are asking for a semaphore protecting the device and then if we get >>>> proceeding. Rather immediateRequest is responsible for checking to see if >>>> the device (Resource) and be assigned and if so it will call the >>>> configurator that should be wired in. If the device isn't available the >>>> configurator isn't called and immediateResource return FAIL. >>>> >>>> >>>> Agreed. That is because Atm128SpiP does the startSPI after the return >>>> from >>>> the ArbriterResource.immediateRequest. That's broken and is what is >>>> causing your problem. >>>> >>>> ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a callout >>>> to ResourceConfigure.configure. This is done prior to setting the state to >>>> other than RES_CONTROLLED. It is the switch to other than RES_CONTROLLED >>>> that lets interrupts get to the device driver. >>>> >>>> Atm128SpiP when making use of immediateRequest, should also have wired in a >>>> ResourceConfigure wiring which should contain the spiStart. >>>> >>>> In all cases, either after a granted or on return from immediateRequest, >>>> interrupt should be handled correctly. It is assumed that the driver is >>>> prepared. In the case of Atm128SpiP that isn't the case because it hasn't >>>> wired in the correct configurator. Calling startSpi after the call to >>>> immediateRequest introduces a timing window and as you found out you are >>>> catching it. >>>> >>>> >>>> My C$0.02 >>>> >>>> eric >>>> >>>> >>>>> >>>>> >>>>> From: Eric Decker [mailto:[email protected]] >>>>> Sent: Friday, November 30, 2012 11:38 PM >>>>> To: Oldrine Lewis >>>>> Cc: [email protected] >>>>> Subject: Re: [Tinyos-help] IRIS SPI lockup >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 <[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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Eric B. Decker >>>>> Senior (over 50 :-) Researcher >>>>> >>>> >>>> >>>> >>>> -- >>>> Eric B. Decker >>>> Senior (over 50 :-) Researcher >>>> >>>> _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
