On Mar 14, 2007, at 7:16 PM, Jonathan Hui wrote:
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.
Good observation -- David observed the same behavior on the micaZ
version of the stack, which also uses a direct (non-DMA) SPI bus, and
introduced a temporary hack to the atmega128 SPI stack to prevent it.
This came up in the core WG call today. Having additional information
will help us figure out the bug: getting all of the last little nits
out is one of the reasons why the stack was "experimental" in the 2.0
release.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
