> Subject: Re: [Tinyos-help] Deluge Post-Dissemination Reboot Problem
> From: clia...@cs.jhu.edu
> I am assuming you are using MSP430. Have you tried the latest version from
> the official TinyOS SVN repository? Do example Deluge apps in
> tinyos-2.x/apps/tests/deluge (such as the burn script in
> tinyos-2.x/apps/tests/deluge/Blink) work for you?
Thanks for this suggestion, but it isn't working for me - in fact it is worse...
Last time I checked these scripts, they do exactly the same thing that I am
doing anyway. Unless preparation is not building the code, installing it on the
nodes, then ensuring each node has a fallback image in slot 0 -- and
programming the network is not building the application, writing it into the
basestation's slot 1, then issuing a disseminate-and-reboot command?
I just obtained the SVN copy from Google code, rebuilt tosboot, installed
Basestation on the PC node, put the code also into slot 0 and finally installed
GoldenImage on all other nodes - with the code also flashed into slot 0. I
assume this means all the code involved is updated to the latest version.
This setup allows me to upload code into slot 1 of the basestation, but issuing
the dissemination or 'disseminate and reboot' command results in zero network
traffic and no flashing LEDs. (The command is accepted by the base, and the
green LED lights momentarily. The code is written correctly to the basestation,
since a ping shows this.)
Trying to reset the nodes to their golden images using the reset gesture failed
on some nodes due to the voltage detection problem on these nodes, so I
modified both tosboot and the NetProg programs to remove the detection code
(forcing the return of TRUE in the okToProgram functions etc). I Rebuilt
tosboot and repeated all the steps again: same result, except the reset
gestures now work.
So I guess I'm back to square one, or possibly square minus one ;-)
I'm tempted to switch back to my CVS checkout, since that seemed to work. But I
still don't understand why the nodes will not reset properly after a
disseminate-and-reprogram command. Presumably if this was fixed, some problem
was found. Anybody know what? Could it have been a failure to reset the WDT in
certain circumstances or perhaps more than one method to get a software reset?
If somebody can give me a hint where in the code the actual reprogramming
occurs in this scenario, I can investigate further. Is it in tosboot, or is it
part of Deluge? I can then try to trace the problem and possibly force the node
to reboot with different code. I see some code that interacts with flash before
calling netprog_reboot(), but I'm unsure if this is the end of the problem.
Some other forums suggest the WDT reset can result in infinite resets if the
WDT is not disabled immediately on reboot. The suggestions for a replacement
seem to be either writing an incorrect flash password or disabling interrupts
followed by a program branch to zero.
Any ideas or suggestions?
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
