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

[Jonathan Hui]

Responses inline.

On Jan 9, 2008 11:43 PM, David <wizzardx at gmail.com> wrote:
> > 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 :-)

This restriction is chip dependent. But yes, this should be mentioned
either in the tutorial or commented in the code.

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

This is definitely possible. The stm25p implementation doesn't
currently validate the addresses passed in. You can try adding an
address check in Stm25pBlockP.nc in newRequest() to make sure any addr
passed in is valid.

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

Sounds like there's some interaction between volumes where there shouldn't be.

-- 
Jonathan Hui


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