Hi!
On Mon, 21 Jan 2008, David wrote:
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.
I committed a fix this.
- tos-deluge -p now turns on the green LED for a few seconds, then it
turns off again.
When the green LED turns off the lock is released by FlashVolumeManager.
I'll take it out as soon as we're done with testing.
--
Razvan ME
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
