I've gone down the BlockStorage + TinyOS 1.x path - part
of that was creating the FlashViewer app to figure out
why
BlockStorage was doing what it does - and found the same
issues you're experiencing. I remember quite clearly
mounting to one location and physically writing to the
completely wrong spot on flash. I don't have an exact
answer to the mounting mishap you're experiencing.
BlockStorage doesn't let you directly access the flash
-
there are behavioral issues with it all over the place
that shouldn't exist. After about 2 months of trying to
play ball with BlockStorage, I ended up rolling my own
libraries to access flash (FlashBridge) and built a
files
system on top of it (Blackbook).
The library I built is called "FlashBridge" and is
located
in the tinyos-1.x CVS under
contrib/rincon/tos/lib/FlashBridge. There are several
types of media associated with that library - you'll
find
them in the FlashBridge/media directory. On a tmote,
you
can use FlashBridge to access the external ST M25P80
flash
or the internal MSP430 flash. Unfortunately, I didn't
predict that flash bridge would support the internal
flash
chip at the time I created it, so I think the way the
code
is right now you can use FlashBridge to access either
the
external flash or the internal flash. There are just
some file naming issues that get in the way of using
both,
I've heard of several people altering FlashBridge in 1.x
to access both.
The other component you'll be interested in is the
Configurator component, also available in that CVS,
which
uses FlashBridge to divide up the small internal flash
on
the MSP430 microcontroller and share as non-volatile
storage for your application components. Using the
Configurator, we're now able to store and load global
program variables from non-volatile memory.
I've stopped updating/supporting the TinyOS 1.x versions
of these components because I've moved onto TinyOS 2.x,
but hopefully you'll still find them useful. Below is a
snippet from the readme doc from the 1.x
FlashBridgeViewer
application
(contrib/rincon/tos/lib/flashbridge/apps/flashbridgeviewer).
-David
$ flashbridge
No arguments found
Usage: java com.rincon.flashviewer [mote] [command]
COMMANDS
-read [start address] [range]
-write [start address] [22 characters]
-erase [sector]
-flush
-crc [start address] [range]
-ping
Let's ping the mote to see if we have FlashBridgeViewer
installed:
$ flashbridge -ping
Pong! The mote has FlashViewer installed.
Great, now let's read a page of data:
$ flashbridge -read 0 0x100
0x0 to 0x100
_________________________________________________
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
Let's write some data. The FlashBridge itself lets you
write as much data at a time as you want, but our
TOS_Msg's being
passed back and forth over UART only hold so much. And
there's
not much you can specify on the command line anyway, so
here's what
happens:
$ flashbridge -write 0x0 hello_flashbridge!
Writing data
0x68 0x65 0x6c 0x6c 0x6f 0x5f 0x66 0x6c 0x61 0x73 0x68
0x62 0x72 0x69 0x64 0x67
0x65 0x21
SUCCESS: 18 bytes written to 0x0
We'll read 0x20 bytes back from 0x0 to make sure what we
wrote exists:
$ flashbridge -read 0 0x20
0x0 to 0x20
_________________________________________________
68 65 6C 6C 6F 5F 66 6C 61 73 68 62 72 69 64 67 |
hello_fl ashbridge
65 21 FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
!
Keep in mind that the AT45DB flash doesn't necessarily
put
what you wrote
onto the physical flash until you flush it out, so
here's
how you flush:
$ flashbridge -flush
SUCCESS: Flush complete
We can take the CRC of the data we just wrote:
$ flashbridge -crc 0x0 18
SUCCESS: CRC is 0x6D3F
And we can erase the entire sector. FlashBridge was
designed for sector
erases, which you can actually go in and edit if you
want
- but it's not
entirely recommended. The ST M25P80 flash erases in
sector-lengths, which
is 64kB at a time. Atmel's AT45DB flash chip erases in
page-lengths, which
is 256B at a time. To maintain compatibility between
the
two chips,
FlashBridge erases the full 64kB at a time on both the
AT45DB and the STM25P
chips. It can probably be done faster on the AT45DB
implementation
than it is right now, but I haven't programmed any of
the
block erase
stuff that the chip actually supports.
Another option would be to go in and edit the
FlashSettings.h
file for the AT45DB and define smaller sector sizes and
readjust
all those flash parameters, and that should maintain
compatibility as well.
So let's erase. It takes about 1 second/sector - which
is
1 second per erase.
$ flashbridge -erase 0
SUCCESS: Sector 0 erase complete
And for that AT45DB you'll want to flush after that as
well to make sure
changes are commmited to flash.
Now let's read back address 0x0:
$ flashbridge -read 0 0x100
0x0 to 0x100
_________________________________________________
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
On Wed, 21 Feb 2007 15:20:33 +0000
"Bob Merrison" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm developing an application in TinyOS-1.x for a
Moteiv
>TMote Sky mote that
> makes fairly heavy use of the mote's 1024k external
>flash - via the
> components BlockStorageC, FormatStorageC (from
Deluge),
>and FlashWPC. My
> application has various configuration parameters that
>need to be persisted
> when the device is reset, as well as some data that it
>collects while
> running. As such, when formatting the flash I create
two
>volumes -
> VOLUME_ID_SYS (ID 0xD0) to store the config stuff and
>VOLUME_ID_MATCH (ID
> 0xD1) to store the main data as it is collected. The
>sequence of events that
> occur when the device is first started up is:
>
> [In StdControl.start] Call Mount.mount(VOLUME_ID_SYS)
>[Mount the system
> volume]
> [In Mount.mountDone] Call BlockRead.read(...) [Read in
>system configuration
> parameters]
> [In BlockRead.readDone] Call
>Mount.mount(VOLUME_ID_MATCH) [Mount the main
> data volume]
> [In Mount.mountDone] Call BlockWrite.erase() [Clear
out
>main data on
> startup]
> [In BlockWrite.eraseDone] Set state to main idle
state.
>
> I'm checking the return value and status of every
>operation and nothing is
> going wrong. Reading and writing to the system config
>volume works
> absolutely perfectly. However, I am getting some
really
>weird problems with
> the main data volume. Once some data has been
collected
>and stored in flash,
> when I attempt to read a record out of the flash the
>values are not at all
> what I expected them to be. This itself wasn't a huge
>concern, as it could
> well have been a problem with my data collection code.
>To try to figure out
> what was going wrong, I added the FlashViewer
component
>to my application,
> connected to it using the FlashViewer Java
application,
>issued the mount
> command to mount the main data volume (-mount 0xD1)
and
>then read what
> should have been the first data record. The record was
>completely empty (all
>Fs). I restarted the mote so that my application would
>bind the main data
> volume and then ran FlashViewer again, this time not
>issuing any mount
> commands first, so that it would use whatever volume
was
>already mounted.
> Strangely enough, I got the same nonsense data out
that
>I had read before
> using my normal method.
>
> All I can surmise from this is that somehow when I
mount
>the main data
> volume on startup some different area of memory is
being
>mounted. Can anyone
> offer any suggestion as to what might be going on?
