Hi Santosh,
What is the exact mote type and interface name you are
accessing when the failure occurs? For example, are you
accessing the At45db interface directly, or using
something else like the BlockStorage interface?
The telosb's flash is a straight-up NOR flash with no RAM
buffers in it, so it doesn't have an implementation for
flush() (or sync) and should always return SUCCESS because
the data is always written directly to non-volatile
memory.
The mica2 and micaz's flash is the same - an AT45DB. It's
a NOR-flash part with RAM buffers on top that allow it to
emulate the behavior of EEPROM, which is single
byte-erases and modifications instead of page-erases.
Without properly flushing its RAM buffers to non-volatile
memory, the data is lost on the next reboot.
Have you verified that after calling "sync" the data
really doesn't get written to non-volatile memory? You
would do this by rebooting the mote and checking to see if
the data can be read back. I've personally never seen a
syncDone() event return FAIL, but if it did it would be
because the AT45DB's RAM buffers do not match the contents
of flash after a flush.
-David
On Tue, 6 Feb 2007 16:14:08 -0600 (CST)
"SANTOSH KUMAR" <[EMAIL PROTECTED]> wrote:
Hi David,
I am facing the same problem as you have mentioned
below. I did a
sync(PageNumber), the syncDone event still fails.
I do a write and then on the writeDone event I call a
sync. The syncDone still
fails.
Could you please let me know what the problem could be?
I am using telosb mote
as well. The same problem does not occur on mica2 motes.
Thanks and Regards,
Santosh
I've never had a problem with garbage being written to
the
end of a page, but I do have another observation on
At45db
sync/flush. I'm using TinyOS 2.x now, but saw the same
sort of behavior in TinyOS 1.x.
When I do a At45dbP.syncAll() or flushAll(), I
intermittently lose data on flash after a reboot. In
other words, data I just got done writing to the chip
didn't make it to non-volatile memory and is permanently
lost. This happens even if I automatically retry the
syncAll() command when syncDone(..) signals FAIL.
When I do a sync(<specific page number>) instead of a
syncAll(), my critical data always gets written to
non-volatile memory correctly. The trick is the
low-level
abstractions (in my case, DirectStorage) needs to keep
track of the last page it wrote to pass in as an
argument
to sync().
Therefore, I rely on sync(<page #>) to ensure my data is
written correctly to non-volatile memory, since
syncAll()
misbehaves intermittently. I notice it usually happens
when writing data across several pages that are all
located in completely different areas of the flash.
-David Moss
On Tue, 6 Feb 2007 14:31:26 -0500
"Jacob Sorber" <[EMAIL PROTECTED]> wrote:
> Okay, that makes sense, but now I have no idea what is
>happening. I am
> writing data in 50 byte chunks to a single page in
flash
>(which I erase
> before writing). After each write I call sync(). The
>first 4 writes seem
> to work as intended (when I read the page, the flash
is
>all 1s after the
> data I have written). After the 5th write, though 6
>bytes of garbage are
> appended (page offsets 250-255). Do you know why
this
>might be happening.
> I have verified that when I call PageEEPROM.write(),
the
>"size" value is, in
> fact, 50.
>
> Thanks,
> Jacob
>
> On 2/6/07, David Gay <[EMAIL PROTECTED]> wrote:
>>
>> On 2/6/07, Jacob Sorber <[EMAIL PROTECTED]>
wrote:
>> > I am seeing some bizarre behavior, and I suspect
that
>>it is due to my
>> not
>> > understanding exactly what these two functions do.
I
>>have not been able
>> to
>> > find any documentation on the subject, so any help
>>would be great.
>>
>> flush starts writing the specified page to flash and
>>signals
>> completion "immediiately" (well, before the write
>>completes). sync
>> does the same thing, but only signals completion when
>>the write is
>> complete.
>>
>> Note that the pages are handled like a cache, so may
be
>>flushed anyway
>> because of subsequent reads or writes. But if you
want
>>to ensure data
>> is written, you do need to call sync or flush.
>>
>> David Gay
>>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
