David,
Thanks for the help, but I'm still having difficulties. Attempting to
over-write the version of TinyOS that was supplied with my motes with
1.1.15 is not pretty - I get a massive number of error messages when I
attempt to compile anything. With an awful lot of effort I might be
able to fix up all the problems and make it work, but I'm not
convinced that this would fix my problem - since I compiled your
MediaFormat app using my current version of TOS and that works
perfectly.
I'm pretty sure I'm wiring StdControl to FlashBridgeC properly as I've
just copied what you've done in MediaFormat, and like you say I
wouldn't be getting the Ready event otherwise, I don't think.
Now I'm wondering (in horror) if it could have something to do with
the fact that the external flash shares a bus with the radio hardware
on tmotes. My application uses GenericComm to access the radio as
opposed to SP, since up until now that's been really simple to use and
has done everything I've needed to do. However, this didn't seem to
cause any problems back when I was using BlockWrite etc...
Any more thoughts?
Bob
On 2/22/07, David Moss <[EMAIL PROTECTED]> wrote:
Bob -
Glad you got through most of the issues you were having.
Sorry I wasn't here to reply to your emails, I've been
out of the office, and will continue to be mostly out for
the rest of the week.
The first thing that comes to my mind is - are you
properly wiring up StdControl to FlashBridgeC? It sounds
like you are, since you're getting a ready() event.
I wonder if there could be incompatibilities between your
newly updated HALSTM25P and the other files in your TinyOS
version? What TinyOS version are you using? Perhaps you
should try installing the 1.1.15 version if you don't have
that already.
I'm not sure about the details of powering on the STM25P,
so forcing it to think that it's on might work - but it
also might break things more.
-David
On Thu, 22 Feb 2007 01:41:26 +0000
"Bob Merrison" <[EMAIL PROTECTED]> wrote:
> 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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
