Re: [Tinyos-help] IRIS SPI lockup
Hi Guys, I have committed this SPI fix today (and did the same fix for the atmega128rfa1 chip). Best, Miklos On Thu, Dec 13, 2012 at 9:12 AM, Miklos Maroti mmar...@math.u-szeged.hu wrote: 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 ole...@sutron.com 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: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Monday, December 10, 2012 2:55 PM To: Oldrine Lewis Cc: Eric Decker; tinyos-help@millennium.berkeley.edu; 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 mmar...@math.u-szeged.hu wrote: Excellent. Thanks! Miklos On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote: Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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
Re: [Tinyos-help] IRIS SPI lockup
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 ole...@sutron.com 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: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Monday, December 10, 2012 2:55 PM To: Oldrine Lewis Cc: Eric Decker; tinyos-help@millennium.berkeley.edu; 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 mmar...@math.u-szeged.hu wrote: Excellent. Thanks! Miklos On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote: Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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
Re: [Tinyos-help] IRIS SPI lockup
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: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Monday, December 10, 2012 2:55 PM To: Oldrine Lewis Cc: Eric Decker; tinyos-help@millennium.berkeley.edu; 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 mmar...@math.u-szeged.hu wrote: Excellent. Thanks! Miklos On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote: Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com] Sent: Friday
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 mmar...@math.u-szeged.hu wrote: Excellent. Thanks! Miklos On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote: Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com] Sent: Friday, November 30, 2012 11:38 PM To: Oldrine Lewis Cc: tinyos-help@millennium.berkeley.edu 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
Re: [Tinyos-help] IRIS SPI lockup
Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com] Sent: Friday, November 30, 2012 11:38 PM To: Oldrine Lewis Cc: tinyos-help@millennium.berkeley.edu 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 ole...@sutron.com wrote: Recently, I have been experiencing frequent lockups with the IRIS nodes. I discovered that the lockup occurred
Re: [Tinyos-help] IRIS SPI lockup
Excellent. Thanks! Miklos On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote: Hi Miklos, Thanks for the updates. I just downloaded the new files. Will test and keep you posted. Thanks, Lewis -Original Message- From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti Sent: Wednesday, December 05, 2012 1:35 PM To: Eric Decker Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; 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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com] Sent: Friday, November 30, 2012 11:38 PM To: Oldrine Lewis Cc: tinyos-help@millennium.berkeley.edu 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 ole...@sutron.com
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 cire...@gmail.com wrote: On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com] Sent: Friday, November 30, 2012 11:38 PM To: Oldrine Lewis Cc: tinyos-help@millennium.berkeley.edu 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 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
Re: [Tinyos-help] IRIS SPI lockup
On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com 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:cire...@gmail.com]
*Sent:* Friday, November 30, 2012 11:38 PM
*To:* Oldrine Lewis
*Cc:* tinyos-help@millennium.berkeley.edu
*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 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
onwhile ( !( 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
Re: [Tinyos-help] IRIS SPI lockup
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 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
onwhile ( !( 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
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
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 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
onwhile ( !( 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
Re: [Tinyos-help] IRIS SPI lockup
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.
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
From: Eric Decker [mailto:cire...@gmail.com]
Sent: Friday, November 30, 2012 11:38 PM
To: Oldrine Lewis
Cc: tinyos-help@millennium.berkeley.edu
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 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 onwhile ( !( 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
