Hi. I'm using tinyos-2.x, as installed by the Ubuntu tinyos package ver 2.0.2.
My app uses both deluge, and does it's own config updates to flash.
Here is my volumes-stm25p.xml file:
<volume_table>
<volume name="DELUGE0" size="65536"/>
<volume name="DELUGE1" size="65536"/>
<volume name="CONFIG" size="131072"/>
</volume_table>
A few questions on the side as I get to my main point:
1) How can those sizes be so large? According to my specs for tmote
sky, there is only 48k flash, but each of the above slots are 64k.
2) Why do config slots need to be that size? I tried to use a 65536
size for that also (the minimum, as required by the tinyos make files
for stm25p), but mounting always fails. I borrowed 131072 from the
Flash memory tutorial lesson (7), and that works.
Getting back to my main point. In my config section I'm currently
storing an integer which gets read and incremented at each boot output
with printf (and output on my console by the java TestPrintf), and
then written back to flash.
This works fine, except when I make changes to my source code (eg:
adding an extra printf), building, injecting (into slot 1) with
tos-deluge, and booting+reprogramming into the injected image. In this
case, ConfigStorage.valid() returns false for my config volume, and
following the example (tutorial lesson 7), my app also resets my flash
config to default values. This is really bad, my config needs to be
persistent and not ever be reset by Deluge updates.
This shouldn't be happening at all, except when the layout in
volumes-stm25p.xml changes...
So, my next question:
3) Why does the "CONFIG" volume (3) become invalid after deluge
injects an updated image (with a larger program) into the previous
volume (2)?
And finally:
4) Should I (as a work around) try to store all of my non-deluge
volumes before Deluge ones, so that they (in theory) don't become
invalidated by Deluge inject & reprogram?
Thanks in advance for any advice.
David.
PS: I found what looks like a few typos in the docs and source:
In lesson 7:
event void Config.commitDone(error_t err) {
call Leds.led0Off();
call Timer0.startPeriodic(conf.period);
if (err == SUCCESS) {
// Handle failure
}
}
Shouldn't that check be "if (err != SUCCESS)" ?
And, in tos/interfaces/SplitControl.nc, the comment for stop() says
"Start this component and all of its subcomponents. Return values of
SUCCESS will always result in a <code>startDone()</code> event being
signalled."
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
