Okay, I fixed this by grabbing the STM25P stuff from CVS and using them instead of the ones that shipped with my TMote units. It compiles now, but the yellow light just stays on indefinitely when I run it on the mote...
On 2/21/07, 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
