Hi. Thanks for your quick reply. I found a few more problems, and have a bit more info on earlier problems. Also I will reply to your comments below.
Problems: * Sending reprogram commands to motes during dissemination stops dissemination eg, if you are busy disseminating an updated slot 1, and then send through a reprogram command, then the motes do a quick "test pattern sweep" (probably a reboot), but don't continue their update. * Still sometimes getting motes which don't want to reprogram Same as my earlier point. They will accept disseminated updates, but they aren't listening to "reset and reprogram" commands. Using the Gesture didn't seem to fix it this time. ie, the motes just stay in the "ready to reboot and reprogram" config (blue LED burning). I'm not sure exactly how to get the motes into this configuration, but it is usually after doing something like: 1) Do a dissemination test 2) Attempt to break dissemination by sending reprogram (network and/or basestation) commands at random times during dissemination 3) Do the above a few times 4) Allow a dissemination to complete successfully. 5) Attempt to send a "reprogram network" command through the basestation. Sometimes doing the above gets the Motes into this weird "ignore network reprogram commands" mode. I think the bug is triggered by the exact timing of when you send the "bad" reprogram commands. Maybe the motes get confused by my testing, and start to think they are always running the latest image version? > > * Sometimes motes don't want to reboot and reprogram after a disseminate. > > > > This happened when I started a dissemination to 2 motes, and then sent > > a few reboot commands (which they ignored) during the update. But > > after the update they still don't want to reboot. > > Does this happen only when the reboot commands are ignored? > I'm not sure. Because with my recent testing (partially bash-script automated) they were responding to reboot commands during "normal" operation. Later, when they go into the "don't want to reboot" mode, they still accept dissemination. I was testing fairly randomly before. It could be that some motes had the same mote ID in some cases (would this affect dissemination?), or that I updated some mote slots without first erasing them or resetting the version number, so later they didn't want to get "older" slot versions (or the "same" ver, even if it something I programmed later), making it look like dissemination was broken. I'll test this more at a later stage. > To investigate cases like this I would recommend to enable the BASESTATION > mode and use tos-deluge and see the state of the Deluge images. Any > incomplete image should be automatically erased upon boot. Thanks, I'll check this. I think that all motes have "BASESTATION" mode enabled by default in tinyos-2.x make rules. I haven't been enabling it when building the test apps. Does this deletion take place for all incomplete slots, or just ones where you attempt to reprogram into? Also, are do motes check images before rebooting (when given a reboot & reprogram command), or do they always reboot, and check the integrity during the boot (followed by a delete if bad or a reprogram). One reason I ask the above is because we are planning to only enable Deluge for short periods of time (eg: a few seconds each day or week), to conserve battery life (ie, we want to use the radio as little as possible). Also implied is that Deluge will be stopped in the middle of downloads and that it should resume those downloads when it gets started again. Since Deluge doesn't (as far as I can tell) have a tinyos API to detect newly-downloaded images, I was planning to use the "reboot and reprogram" (into a specific slot) function after each "Deluge-enabled" period, and assuming that Deluge would ignore that function if there was no valid image in that slot (or if the image is the same as the currently-running program). Would the above logic work? > > Thank-you very much for the feedback! Right now I'm a little busy so I'll > not have time to respond so quickly this time. Thanks for your quick replies so far :-) Get back to me whenever you have time. David. _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
