Hi Roman, Thanks for discovering and looking into this problem. From the description you gave us, it does look like the radio is already disabled. My guess is that the radio stack is incorrectly trying to use the SPI bus or something else is calling SpiByte.write() when the resource is not correctly acquired. If the resource isn't acquired correctly, the SPI bus will not initialize correctly and you will definitely spin forever in that while-loop.
Is it possible for you to figure out what is calling SpiByte.write() at the time of failure? You could either make the SpiByte interface parameterized just like SpiPacket, and see what client id is being passed in, or you could inspect the stack. -- Jonathan W. Hui [EMAIL PROTECTED] http://www.cs.berkeley.edu/~jwhui/ On 3/12/07, Roman Lim <[EMAIL PROTECTED]> wrote:
Hello, I used the cc2420lpl stack (the one in tinyos-2.x-contrib/rincon) together with the multihop-oscilloscope. My nodes (Tmote sky) run fine for a cupple of minutes, then some nodes stop working. Here are some parameters of my network () : 5 nodes, limited tx-power to 2 8s sampling period (i send one packet for each sample) 250ms RxSleepInterval I found, that the failing nodes keep running in a loop in Msp430spiNoDmaP.nc in SpiByte.write(). the line while (! call Usart.isRxIntrPending() ); is never left. the state variables in various radio-stack components makes me assume, that the radio is not active while the lock-up occurs: csma: state=stopped controlp: state=vreg_stopped transmitp: state=stopped spiImplP resource_busy=false spiImplP requests=0 spiImplP holder=0xff does anybody knows, where to dig? Roman _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
