[Tinyos-help] Deluge invalidating non-deluge flash volumes?

Razvan Musaloiu-E. razvanm at cs.jhu.edu
Wed Jan 9 14:30:13 PST 2008


Hi!

On Wed, 9 Jan 2008, David wrote:

> 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.

The minimum unit for erasing for stp24p is 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.

I don't know much about the config. :-(

> 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.

If you don't inject but just reboot the mote does the config fails?

--
Razvan ME

> 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 at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>


More information about the Tinyos-help mailing list