Thanks for your reply. Responses also inline.
>
> Erase unit on the ST serial flash is one 64KB sector. Config needs two
> sectors so that it can buffer swap.
>
Please update the docs to mention this :-)
>
> 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.
>
It's the same app, the only change I make (to cause this invalidation)
is to add an extra printf line to my app (and then use tos-deluge to
inject and reboot + reprogram). I've just checked, such updates don't
affect my StorageVolumes.h. For your info, here is my
StorageVolumes.h:
#ifndef __STORAGE_VOLUME_H__
#define __STORAGE_VOLUME_H__
#include "Stm25p.h"
#define VOLUME_DELUGE0 0
#define VOLUME_DELUGE1 1
#define VOLUME_CONFIG 2
static const stm25p_volume_info_t STM25P_VMAP[ 3 ] = {
{ base : 0, size : 1 },
{ base : 1, size : 1 },
{ base : 2, size : 2 },
};
#endif
> > 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.
It definitely seems to be happening here. Should I try the latest CVS
version, or forward you a test case?
Also, is it possible for an app which uses one volume to accidentally
overwrite part of the next volume? (eg, if you pass bad offsets or
lengths to BlockWrite). I think that Deluge *might* be doing this, and
it's somehow related to my program image growing larger between
injects or reprogramming.
>
> > 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.
>
I've just tried the above (putting CONFIG first in volumes-stm25p.xml,
running a make install, and then retesting as described earlier), and
my config volume doesn't get invalidated any more.
I moved CONFIG back to the end and retested, and I get the
invalidation problem again (after every deluge inject, but not the
rest of the time).
Actually, it seems now that my config volume gets invalidated (by
inject and reprogram) even if I don't make a program change and
recompile.
I'm pretty sure the problem is caused by "inject", because I'm using
"reboot and reprogram" for all my reboots, and only get the problem
after an inject (and then reboot & reprogram).
For now I'll keep all my volumes before Deluge's, but please (to the
tinyos devs in general) look into this.
Btw, what is the best way to force Deluge volumes to go to the end of
the flash memory instead of the start? I would like to disrupt Deluge
as little as possible when I add new volumes for my app. Probably
"offset", but what values should I use?
David.
PS: Something else I've observed: If I leave the "TestPrintf" app
running, then tos-deluge has problems communicating injecting into
motes. The updates stall a lot (not just go slowly). Is this by
design? I only do about 10 printf statements so that shouldn't be
hogging the USB port...
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
