Okay, now I've run into another really strange problem. Running
MediaFormat on my motes works fine and now I'm attempting to use
FlashBridge in my own application. Basically all I'm doing with it is
waiting for the FlashBridge.ready event to fire and then posting a
task to erase sector 0. Nothing more fancy than what MediaFormat does.
However, the call to FlashBridge.erase is never returning. I've done
some digging down in the source code and it seems to be getting as far
as the line in HALSTM25PM.newRequest where it attempts to turn the
power on if it's currently off. I can only surmise that something in
the low-level communication with the flash in HALSTM25PM.sendCmd is
blocking things for some reason.
I'm completely baffled as to why this would occur for my application
but not the MediaFormat one. As far as I can tell everything I'm doing
with FlashBridge is identical. Is there anything else that might step
on its toes? Any other suggestions for what might be going on?
Cheers.
On 2/21/07, Bob Merrison <[EMAIL PROTECTED]> wrote:
After much head-scratching I think I found a bug in your MediaFormat
component. Line 145 of MediaFormatM.nc was:
if(currentEraseUnit <= call FlashSettings.getTotalEraseUnits()) {
But the erase units are zero-indexed. Changing the <= to < seems to
fix it up nicely. Thanks for your help, I'll stop spamming the list
now :)
On 2/21/07, Bob Merrison <[EMAIL PROTECTED]> wrote:
> Do I need to format my flash to your Blackbook format or anything? I'm
> attempting to run the MediaFormat application included with
> FlashBridge, but the yellow light on my mote just stays on...
>
> On 2/21/07, David Moss <[EMAIL PROTECTED]> wrote:
> > Looks like you're using an older version of 1.x? I was
> > using 1.1.15 at the time I created that, and the HALSTM25P
> > interface had changed just before then.
> >
> > I should just make the newest HALSTM25P file available in
> > the rincon directory, since quite a few people run into
> > this issue.
> >
> > The version I have of the tos/lib/Flash/STM25P HAL
> > components/interfaces is attached, renamed with a .zip.txt
> > format because my email server would eat it otherwise.
> >
> > -David
> >
> >
> >
> > On Wed, 21 Feb 2007 17:10:15 +0000
> > "Bob Merrison" <[EMAIL PROTECTED]> wrote:
> > > On attempting to compile:
> > > ../../media/stm25p/Stm25pFlashBridgeM.nc:260: too few
> > >arguments to function `HAL
> > > STM25P.computeCrc'
> > >
> > > This is your call to computeCrc:
> > > call HALSTM25P.computeCrc(¤tCrc, currentCrc, addr,
> > >len);
> > >
> > > This is the defintion of the command:
> > > command result_t computeCrc(uint8_t rh, uint16_t
> > >*crcResult, uint16_t
> > > crc, stm25p_addr_t addr, stm25p_addr_t len)
> > >
> > > I can't find any documentation for HALSTM25P, so I have
> > >no idea what
> > > that "rh" parameter is. Any ideas?
> > >
> > > On 2/21/07, David Moss <[EMAIL PROTECTED]> wrote:
> > >> 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?
> > >>
> > >>
> > > _______________________________________________
> > > 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
