Responses inline.
On Jan 9, 2008 7:05 AM, David <[EMAIL PROTECTED]> wrote:
> 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.
Erase unit on the ST serial flash is one 64KB sector. Config needs two
sectors so that it can buffer swap.
> 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.
Are you using the *same* volume table for both programs? They need to
be the same for this to work. You can verify they are the same by
looking at the StorageVolumes.h file in the build dir.
> 3) Why does the "CONFIG" volume (3) become invalid after deluge
> injects an updated image (with a larger program) into the previous
> volume (2)?
It shouldn't.
> 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?
You shouldn't need to.
--
Jonathan Hui
>
> 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
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
