[Tinyos-devel] tmote P3.6 / P3.7 direction

Geoffrey Werner-Allen geoffrey.werner.allen at gmail.com
Wed Jul 2 15:17:13 PDT 2008


Thanks to David for putting this out there.  I just thought that I would add
that I'm past suspicious at this point that this was causing reprogramming
problems, I'm pretty close to certain.  In the years before we caught this
problem we were unable to keep large numbers of MoteLab nodes
(power/programmed off of USB) online for long periods of time and had to
constantly power-cycle them, frustrating as this meant returning to the
device and manual unplugging it.  In the 6-months since I made this
discovery and implemented a simple fix (an erasure binary which manually
sets the port up "properly") we've gone through multiple periods of heavy
use and the lab has been much more stable and I haven't seen a single
programming lock up (we still lose nodes occasionally for other reasons, of
course).

Getting this into the T2 mainline would be great since it would mean that we
wouldn't have to worry about the (admittedly small) chance that an external
experimental binary could be used that would tickle this problem.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner

On Wed, Jul 2, 2008 at 5:49 PM, David Moss <dmm at rincon.com> wrote:

>  This has been sitting on my plate for awhile, and I haven't had time to
> do anything about it.  Thank Geoff Werner-Allen for finding and bringing
> this up long ago.
>
>
>
>
>
>
>
> Summary of the problem: "Essentially on the TMote Sky (and probably
> TelosA), when the serial port is enabled (i.e. the node is plugged in via
> USB) but serial support is not enabled in the binary this creates a port
> conflict between the MSP430 UART1RX port, which is by default configured as
> an output low, and the buffer between it and the FTDI chip, which is trying
> to drive the line high. Not only does this sink ~30mA of extra current into
> the MSP430 (which is how we found it, trying to do current measurements with
> the node plugged in via USB), we're also suspicious that it may cause a port
> latch-up which causes the TMote to fail subsequent reprogramming cycles
> (until power cycled)."
>
>
>
> Proposed solution: "A better/robust approach might be to have MotePlatformC
> check the state of P1.2. If it's low, the mote is running off batteries and
> the default configuration is fine. If it's high, the mote is running off USB
> so P3.6 should be made output-high and P3.7 should be made into an input.
>
>
>
> I think you could effectively argue that this approach would:
>
>    - Have a *very* small impact on code size
>
>    - Not create any incompatibilities for motes running off batteries
>
>    - Make life a lot better for motes running off USB, regardless of the
> use of the serial stack or its configuration"
>
>
>
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080702/a484e4dc/attachment.htm 


More information about the Tinyos-devel mailing list