[Tinyos-devel] Adjacency bug in new (vastly improved) UARTimplementation

[Philip Levis]

On Jun 14, 2007, at 10:35 PM, Roland Tembo Hendel wrote:

> Reposting as I originally posted to tinyos-commits (sorry).
>
>
>
>
>
> On 5-25, Alec Woo made some much needed improvements to the  
> implementations of Atm128UartP.nc HplAtm128UartP.nc.
>
>
>
> I have been using this improved version, but would like to alert  
> the community to a nasty bug that I uncovered in my testing:
>
>
>
> The Atm128 implementation of McuSleepC.nc determines which power  
> mode to enter by checking if UART interrupts are enabled. The new  
> improved UART implementation does not enable interrupts by default.  
> The result of this is that under certain conditions the atm128 will  
> enter idle mode (UARTS not serviced), stranding bytes in the UART  
> FIFOS if the UART is enabled but NOT running interrupts. This  
> caused me a multitude of headaches as I use the UART to instrument  
> a one-wire network.
>
>
>
> The solution is to change the line in McuSleepC.nc from:
>
>
>
> --- FROM:
>
> else if ((UCSR0B | UCSR1B) & (1 << TXCIE | << 1 RXCIE)) {  return  
> AM128_POWER_IDLE; }
>
>
>
> --- TO:
>
> else if ((UCSR0B | UCSR1B) & (1 << TXEN | << 1 RXEN)) {  return  
> AM128_POWER_IDLE; }
>
> ---
>
>
>
> There may be a more granular check than the one that I am proposing  
> and I'm open to suggestions, but at least this implementation  
> works. In the meantime, improved power management can be maintained  
> by disabling the UARTs when they are not in use.

That looks right. What matters is whether they're on, not whether  
they have interrupts enabled.

That being said, this means it's possible to go into a sleep state  
based on the UART being on, but then to stay in this high power state  
for a long time until the next interrupt.

Phil