[Tinyos-devel] FW: Friendly plea regarding tinyos-2.x cc2420 stack :)

David Moss dmm at rincon.com
Thu Oct 18 10:49:11 PDT 2007


Fyi.


-----Original Message-----
From: Leo Szumel [mailto:leo at sentilla.com] 
Sent: Thursday, October 18, 2007 10:40 AM
To: David Moss
Subject: Re: Friendly plea regarding tinyos-2.x cc2420 stack :)

David,

Alas, we are using tag "release_tinyos_2_0_2_2". Interestingly, this bug
only popped up when we started using the Stm25pFlash component in
conjunction with the CC2420 (both tested fine independently). I have
verified to my satisfaction that the arbitration is working, and never are
both devices selected simultaneously (scoped out the CSN pins). So the
likely candidate seems to be a bug in the MCU's SPI code, perhaps
incorrectly switching state between the two grants. If you've got any other
ideas, I'd love to hear 'em.

BTW, I have looked at the bus during the hang, and the CC2420 is still
selected (CSN low). By examination of the radio stack, this could only
happen when the SPI resource is granted. It seems impossible (with my
knowledge of 2.0.2.2) that a higher layer could release the grant without,
in this instance, CC2420TrasmitP having first released it. 

Thanks for your super fast reply! 

-Leo

----- Original Message -----
From: "David Moss" <dmm at rincon.com>
To: "Leo Szumel" <leo at sentilla.com>
Sent: Thursday, October 18, 2007 10:00:19 AM (GMT-0800) America/Los_Angeles
Subject: RE: Friendly plea regarding tinyos-2.x cc2420 stack :)

Hi Leo,

Yes, I do know what's going on, and my first guess is you're still using the
CC2420 from TinyOS 2.0.0 or 2.0.1.  Right?  If so, you should try to upgrade
your CC2420 stack to the latest and greatest 2.0.2 release.  Btw, what's in
the CVS baseline right now is 2.1, with interface changes and stuff, so I'd
recommend trying to get the actual 2.0.2 release so you don't break the rest
of your code.  You should be able to just copy in the new CC2420 chip from
2.0.2 and modify your .platform file to include all of the chip's new
directories correctly at compile time.

What's happening here is the CC2420 radio is releasing the SPI bus in the
middle of a SPI bus operation.  This is because the radio duty cycling
component doesn't know when the SPI bus is in use, it just knows when the
radio should be turning off.  And the lower levels of the stack didn't
really care when the SPI bus was in use, so the radio gets turned off, the
SPI resource is released, and the SPI bus driver hangs.  Something like that
anyway.  There was some traffic on this bug a few months ago in tinyos-help
where I explained in detail what was going on.

The current CC2420 stack allows the SPI bus to complete its task before
releasing it, even if the radio gets physically shut off in the middle of a
SPI bus operation. Because the microcontroller is the master, the SPI bus
will complete its task regardless of whether or not the radio is physically
turned on.  The CC2420 driver itself knows that the SPI driver events are
returning garbage because the radio's off, and at that point, the SPI
resource is released and everything's happy.

-David







-----Original Message-----
From: Leo Szumel [mailto:leo at sentilla.com] 
Sent: Thursday, October 18, 2007 9:39 AM
To: dmm at rincon.com
Subject: Friendly plea regarding tinyos-2.x cc2420 stack :)

Hi David,

Remember me from my questions/bug reports regarding the tos-1.x blackbook
implementation? Good news is I was able to build my app by side stepping the
various bugs I was experiencing.

Bad news is I have another question for you! But, it's just a "got any
ideas?" question.

I'm running (more or less) the vanilla tinyos-2.x radio stack and it's
hanging. We are using TelosB hardware, which means the SPI bus is shared by
the external Stm25pFlash chip and the CC2420. I send this plea to you
because I know you have spent a lot of time developing the tos-2.x cc2420
code and I'm hoping you may have hit this before and have some insight. 

Using a debugger I can see that the MCU is stuck in this loop:

Msp430SpiNoDmaP.nc:111

  async command uint8_t SpiByte.write( uint8_t tx ) {
    uint8_t b;
    // we are in spi mode which is configured to have turned off interrupts
    //call Usart.disableRxIntr();
    call Usart.tx( tx );
>>>>while( !call Usart.isRxIntrPending() );
    call Usart.clrRxIntr();
    b = call Usart.rx();
    //call Usart.enableRxIntr();
    return b;
  }

i.e., stuck polling for the readback byte after sending a spi byte.

What is confusing is that the readback byte should *always* be available
since that's core to the SPI protocol. The only way I can imagine this
happening is if the MCU's SPI mode is misconfigured. Currently I'm going to
do more register examination in the debugger and maybe some logic analyzer
traces from the bus.

In the meantime, I'm praying you will say "aha! I remember that" and give me
valuable insight that will save me some time :).

Best,

-Leo







More information about the Tinyos-devel mailing list