> 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