Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

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  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  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  
>> wrote:
>>> Excellent. Thanks! Miklos
>>>
>>> On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis  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  wrote:
>
>
> On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis  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 
> ca

Re: [Tinyos-help] Problem with DEFAULT_LOCAL_GROUP on TinyOS 2.1.2

Hi Eric,
I have submitted the bug report. Using different channels is definitely a 
better way to isolate apps than group ids and I will be using that now. Thanks 
you very much.

Thanks Antonio, for pointing me towards that useful conversation.

From: antonio rosa [antoniorosarodrig...@gmail.com]
Sent: Friday, January 04, 2013 5:40 AM
To: Eric Decker
Cc: Kumar, Vimal (S&T-Student); tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] Problem with DEFAULT_LOCAL_GROUP on TinyOS 2.1.2

Hi,
first sorry for this misunderstanding,
I wanted to say that this phenomenon in the BaseStation is due to the Snoop 
Component, but if the applications nodes does not use the Snoop Component, it 
must be a filter Group ID. Once years ago, we had the same conversation with 
this topic: 
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg39173.html

Regards, Antonio Rosa.

2013/1/4 Eric Decker mailto:cire...@gmail.com>>


On Fri, Jan 4, 2013 at 12:30 AM, antonio rosa 
mailto:antoniorosarodrig...@gmail.com>> wrote:
Hi, about BaseStation, it uses Snoop Component and for that,  it snoop all 
packets, about the node ids, it shouldn't do it.

Snoop actually is intended to see all packets (its like a packet sniffer).

Are you saying that it shouldn't accept packets that don't match Group?


2013/1/3 Kumar, Vimal (S&T-Student) 
mailto:vk...@mail.mst.edu>>
Hi,

I was testing DEFAULT_LOCAL_GROUP on TinyOS 2.1.2 for which I wrote a simple 
application with two motes bouncing a message back and forth. The motes 
received each other's message when they had the same group ID but even when 
they had different group IDs. I set the group IDs in the make file using the 
DEFAULT_LOCAL_GROUP directive. I can see that the group IDs are set correctly 
in the transmitted packet but the receiving node does not discard messages with 
different group IDs. Same thing happens with the BaseStation, which also does 
not make any distinction between group IDs. Is this a known issue or am I doing 
something wrong here?

Thanks
-vimal

___
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



--
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] backoff in CC2420x stack!

[Janos Sallai]

Wasif,

In CC2420XDriverConfig.nc, you need to
modify CC2420XDriverConfig.requiresRssiCca(message_t* msg) such that it
always returns false. This will turn off the CCA for all messages.

Please note that even if CCA is disabled the collision avoidance layer will
do the initial backoff. To turn the collision avoidance layer off
completely, change the stacking of the layers in CC2420XRadioC.nc, such
that MessageBufferLayer and UniqueLayer are wired directly to
SoftwareAckLayer, removing CollisionAvoidanceLayer from the stack
completely.

Janos


On Fri, Jan 4, 2013 at 5:00 AM, wasif masood  wrote:

>
> Hi All,
>
> I am wondering is there any interface to turn off CCA for CC2420x Stack?
>
> From the wiring, I notice that the RandomCollisionConfiginterface is where
> the CCA is configured but could not find any specific way to turn it off as
> we have in CC2420 stack, i.e. the RadioBackoff interface!
>
> --
> Wasif Masood
>
> ___
> 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] Problem with DEFAULT_LOCAL_GROUP on TinyOS 2.1.2

[antonio rosa]

Hi,
first sorry for this misunderstanding,
I wanted to say that this phenomenon in the BaseStation is due to the Snoop
Component, but if the applications nodes does not use the Snoop Component,
it must be a filter Group ID. Once years ago, we had the same conversation
with this topic:
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg39173.html

Regards, Antonio Rosa.

2013/1/4 Eric Decker 

>
>
> On Fri, Jan 4, 2013 at 12:30 AM, antonio rosa <
> antoniorosarodrig...@gmail.com> wrote:
>
>> Hi, about BaseStation, it uses Snoop Component and for that,  it snoop
>> all packets, about the node ids, it shouldn't do it.
>>
>
> Snoop actually is intended to see all packets (its like a packet sniffer).
>
>
> Are you saying that it shouldn't accept packets that don't match Group?
>
>
>>
>> 2013/1/3 Kumar, Vimal (S&T-Student) 
>>
>>> Hi,
>>>
>>> I was testing DEFAULT_LOCAL_GROUP on TinyOS 2.1.2 for which I wrote a
>>> simple application with two motes bouncing a message back and forth. The
>>> motes received each other's message when they had the same group ID but
>>> even when they had different group IDs. I set the group IDs in the make
>>> file using the DEFAULT_LOCAL_GROUP directive. I can see that the group IDs
>>> are set correctly in the transmitted packet but the receiving node does not
>>> discard messages with different group IDs. Same thing happens with the
>>> BaseStation, which also does not make any distinction between group IDs. Is
>>> this a known issue or am I doing something wrong here?
>>>
>>> Thanks
>>> -vimal
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> 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

[Tinyos-help] backoff in CC2420x stack!

[wasif masood]

Hi All,

I am wondering is there any interface to turn off CCA for CC2420x Stack?

>From the wiring, I notice that the RandomCollisionConfiginterface is where
the CCA is configured but could not find any specific way to turn it off as
we have in CC2420 stack, i.e. the RadioBackoff interface!

-- 
Wasif Masood
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Problem with DEFAULT_LOCAL_GROUP on TinyOS 2.1.2

[Eric Decker]

On Fri, Jan 4, 2013 at 12:30 AM, antonio rosa <
antoniorosarodrig...@gmail.com> wrote:

> Hi, about BaseStation, it uses Snoop Component and for that,  it snoop all
> packets, about the node ids, it shouldn't do it.
>

Snoop actually is intended to see all packets (its like a packet sniffer).


Are you saying that it shouldn't accept packets that don't match Group?


>
> 2013/1/3 Kumar, Vimal (S&T-Student) 
>
>> Hi,
>>
>> I was testing DEFAULT_LOCAL_GROUP on TinyOS 2.1.2 for which I wrote a
>> simple application with two motes bouncing a message back and forth. The
>> motes received each other's message when they had the same group ID but
>> even when they had different group IDs. I set the group IDs in the make
>> file using the DEFAULT_LOCAL_GROUP directive. I can see that the group IDs
>> are set correctly in the transmitted packet but the receiving node does not
>> discard messages with different group IDs. Same thing happens with the
>> BaseStation, which also does not make any distinction between group IDs. Is
>> this a known issue or am I doing something wrong here?
>>
>> Thanks
>> -vimal
>>
>> ___
>> 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
>



-- 
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] Problem with DEFAULT_LOCAL_GROUP on TinyOS 2.1.2

[antonio rosa]

Hi, about BaseStation, it uses Snoop Component and for that,  it snoop all
packets, about the node ids, it shouldn't do it.

2013/1/3 Kumar, Vimal (S&T-Student) 

> Hi,
>
> I was testing DEFAULT_LOCAL_GROUP on TinyOS 2.1.2 for which I wrote a
> simple application with two motes bouncing a message back and forth. The
> motes received each other's message when they had the same group ID but
> even when they had different group IDs. I set the group IDs in the make
> file using the DEFAULT_LOCAL_GROUP directive. I can see that the group IDs
> are set correctly in the transmitted packet but the receiving node does not
> discard messages with different group IDs. Same thing happens with the
> BaseStation, which also does not make any distinction between group IDs. Is
> this a known issue or am I doing something wrong here?
>
> Thanks
> -vimal
>
> ___
> 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