Hi again. See my new post at the bottom of this mail.
On Jan 18, 2008 5:05 PM, David <[EMAIL PROTECTED]> wrote: > Apologies in advance if I'm doing something dumb again ;-) > > It looks like dissemination is broken. When you run tos-deluge -d or > -dr, nothing happens on the non-basestation motes. > > I've seen this with my own testing, and also with > apps/tests/deluge/Blink/burn-net. > > burn-net works fine up until the final step, where it runs "tos-deluge > -dr 1". There isn't any error message, and a green LED does blink > momentarily on the basestation mote (indicating it got comms over > USB). But the green LED on the 2nd mote doesn't start flickering, and > it never switches over to the 2nd program (blink green LED). > > Can somebody confirm this problem? > I did some more testing with burn-net again this morning, after a 'git pull', rebuild, reinstall, etc. In most of the tests I only used 2 motes, nothing complicated. TEST 1: Ran burn-net (without -s or -ls first), and it worked, but much more "erratic" transfer than previous versions of Deluge. The destination mote got a short burst of green LED, then a delay, then another burst, then a delay. Although it finally did reprogram and reboot into the blue LED. When I connected a 3rd mote (already erased, reprogrammed with latest Blink test, etc) into a USB port (in place of the basestation, I was using 3 motes but only 2 USB ports), the 3rd mote didn't download at all TEST 2: (After erasing all slots, re-running make install on all motes). The dissemination started working (got the first green burst), but then stopped. TEST 3: I performed a more thorough "clear and reset everything procedure" than usual on all the motes (including tos-deluge -s and -ls) on all the motes (see later in this mail for details) and ran burn-net again. The destination mote did not want to download an image. I also checked 'tos-deluge -p 1' on the destination mote this time, it confirmed "No valid image was detected". I'm still trying to narrow down the problem as much as possible, to isolate if it's something I'm doing incorrectly. I'll probably run a 'git bisect' later to see which commit made Deluge dissemination start behaving so badly. Thanks (to weiping and Dimas) for the suggestions to run tos-deluge with -s. It doesn't seem to help much, but I have added it (and -ls) to my process for "resetting all motes to a known good state" Here is my current "reset all motes to a known good state" logic, please reply with any suggestions for improving, or if there is a problem: (All motes are disconnected from USB/unpowered during this process, except for the one currently being reset). # At start, under Blink deluge test folder: make telosb # Then for every mote: make telosb reinstall,$MOTE_ID tos-deluge /dev/ttyUSB0 telosb -s tos-deluge /dev/ttyUSB0 telosb -ls tos-deluge /dev/ttyUSB0 telosb -e 0 tos-deluge /dev/ttyUSB0 telosb -e 1 tos-deluge /dev/ttyUSB0 telosb -e 2 tos-deluge /dev/ttyUSB0 telosb -e 3 A few other things I've noticed which may be bugs: - tos-deluge now accepts any slot number (eg: 100) for the erase (-e) command and says "Image number 100 erased". I only have 4 Deluge slots in the motes. - tos-deluge -p now turns on the green LED for a few seconds, then it turns off again. By the way, is it remotely possible that my problems are caused by building from the git checkout instead of from CVS? One example of a difference to CVS is where I need to comment out Python lines which set VERSION from $Revision. I'm going to check this next (update CVS, rebuild, retest etc) and reply with my results. Regards, David. _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
