Hi, I noticed that the mask used by RF230DriverLayerP::RadioSend.send() to check if a Pll lock has been in successful is defined in RF230DriverLayer.h as RF230_PLL_ON = 9, since BIT0 is the bit used to indicate a lock, why is the TRX_END bit also being checked? I have noticed instances when only the Lock but is set without the TRX_END bit.
Thanks, Lewis -----Original Message----- From: András Bíró [mailto:[email protected]] Sent: Wednesday, October 24, 2012 2:52 PM To: Miklos Maroti Cc: Oldrine Lewis; [email protected] Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever Hi Guys, This is probably irrelevant, but I never had the time to check it: On the rf212 radio with RADIO_DEBUG turned on, I get an assert sometimes: The driver gets a PLL_LOCK interrupt, with CMD_NONE, STATE_RX_ON, but it works after that. This bug is probably LPL related, but who knows. Andris On Wed, Oct 24, 2012 at 8:21 PM, Miklos Maroti <[email protected]> wrote: > Interesting. This seems geniune then. Can you please produce a minimal > version of the test (remove everything that is not needed to reproduce > the bug). Do you see any difference if you do not define > TASKLET_IS_TASK? Miklos > > On Wed, Oct 24, 2012 at 1:17 PM, Oldrine Lewis <[email protected]> wrote: >> Thanks again. I will upload the critical files that deal with TX, RX. >> >> Another observation I forgot to mention in my previous posts - I did not >> notice any lockups when I used hardware acks. I noticed the lockups only >> after using software acks. >> >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Miklos Maroti >> Sent: Wednesday, October 24, 2012 2:11 PM >> To: Oldrine Lewis >> Cc: [email protected] >> Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever >> >> I am just wondering how the user level code is written, maybe the bug >> is there. If you have a public repository, then I will take a look. >> Basically I wanted to see how you receive and resend the message. >> Miklos >> >> On Wed, Oct 24, 2012 at 1:04 PM, Oldrine Lewis <[email protected]> wrote: >>> Hi Miklos, >>> Thanks for the speedy response. My entire project is quite large... is >>> there any specific portion/part I can extract that would be more useful ? >>> >>> The portion of code I initially posted is from RF230DriverLayerP.nc >>> >>> tasklet_async command error_t RadioSend.send(message_t* msg) >>> { >>> uint16_t time; >>> uint8_t length; >>> uint8_t* data; >>> uint8_t header; >>> uint32_t time32; >>> void* timesync; >>> >>> if( cmd != CMD_NONE || state != STATE_RX_ON || ! >>> isSpiAcquired() || radioIrq ) >>> { >>> FormatDbgStr("FAT : >>> cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n",cmd, state,isSpiAcquired(), radioIrq ); >>> return EBUSY; >>> } >>> ... >>> ... >>> ... >>> >>> } >>> >>> >>> >>> >>> >>> Thanks, >>> Lewis >>> >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of Miklos >>> Maroti >>> Sent: Wednesday, October 24, 2012 1:58 PM >>> To: Oldrine Lewis >>> Cc: [email protected] >>> Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever >>> >>> Can you post your code too? Miklos >>> >>> On Wed, Oct 24, 2012 at 12:53 PM, Oldrine Lewis <[email protected]> wrote: >>>> I have four Iris nodes and all are broadcasting (flooding the network) a >>>> message. Each node after receiving a msg waits for a random period and >>>> re-broadcasts the msg. >>>> >>>> I noticed that after a few seconds the radio stack locks up and returns >>>> EBUSY forever. >>>> >>>> I put a few debug statements in RadioSend.send() (file = >>>> RF230DriverLayerP.nc). >>>> >>>> >>>> >>>> >>>> >>>> if( cmd != CMD_NONE || state != STATE_RX_ON || ! isSpiAcquired() || >>>> radioIrq >>>> ) >>>> >>>> { >>>> >>>> FormatDbgStr("FAT : cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n",cmd, >>>> state,isSpiAcquired(), radioIrq ); >>>> >>>> return EBUSY; >>>> >>>> } >>>> >>>> The error log I got looked like this before the send failed. >>>> >>>> >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=5,st=5,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> FAT : cmd=0,st=7,spAq=1,rIrq=0 >>>> >>>> It seems that the state and cmd variable somehow get out of sync. >>>> >>>> Other settings in makefile >>>> >>>> CFLAGS += -DTASKLET_IS_TASK >>>> >>>> >>>> >>>> I am investigating this further and would like to know if anyone has >>>> experienced something similar >>>> >>>> >>>> >>>> Thanks in advance. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
