FSRW Errors

Jay Kickliter

Every once in a while i find that FSRW creates a file on my SD card that I didn't want. Sometimes it has a file name off by a character or two, and other times the file name is actually a string that was meant to be appended to a differenct file. I am using the sdspiqasm block lever driver. I tried the others, but none of them work for me.

Any ideas?

Here's the code (with a lot cut out for clarity):

OBJ                                                     ' 1 cog for main
  uarts           : "pcFullDuplexSerial4FC"             ' 1 cog
  phone           : "MotorolaC168Iinterface"            ' 0 cog
  gpsParser       : "GPS_IO_4P"                         ' 1 cog for parsing
  thermometer     : "OneWire"                           ' 1 cog
  floatFormatter  : "FloatString"                       ' 0 cogs
  floatEngine     : "FloatMath"                         ' 0 cogs
  config          : "config"                            ' 0 cogs
  sdfat           : "fsrw"                              ' 1 cog
  
PUB Main
  temperatureCelcius := 0
  config.Init(@configinfo)
  uarts.Init
  uarts.AddPort(0,config.GetPin(CONFIG#DEBUG_RX),config.GetPin(CONFIG#DEBUG_TX), UARTS#PINNOTUSED, UARTS#PINNOTUSED, UARTS#DEFAULTTHRESHOLD, UARTS#NOMODE,UARTS#BAUD19200)
  uarts.AddPort(1,config.GetPin(CONFIG#PHONE_RX),config.GetPin(CONFIG#PHONE_TX), UARTS#PINNOTUSED,UARTS#PINNOTUSED,UARTS#DEFAULTTHRESHOLD, UARTS#NOMODE,UARTS#BAUD4800)
  uarts.AddPort(2,config.GetPin(CONFIG#GPS_RX),config.GetPin(CONFIG#GPS_TX), UARTS#PINNOTUSED,UARTS#PINNOTUSED,UARTS#DEFAULTTHRESHOLD, UARTS#INVERTRX,UARTS#BAUD4800)
  uarts.Start
  gpsParser.start
  phone.start
  cognew(cameraTimer, @cameraStack)
  cognew(logData, @loggerStack)
  phone.setEchoOff
  thermometer.start(THERMOMETER_DATA)

PUB logData | size
  dira[noparse][[/noparse]16] := 1 
  sdfat.mount(SD_BASE_PIN)
  repeat
    outa[noparse][[/noparse]16] := 1
    sdfat.popen(string("poslog.csv"), "a")
    if (size := strsize(gpsParser.date)) > 0 AND size < 13
      SDWrite(gpsParser.date)
    sdfat.pputc(COMMA)
    if (size := strsize(gpsParser.time)) > 0 AND size < 13
      SDWRite(gpsParser.time)
    sdfat.pputc(COMMA)
    if (size := strsize(gpsParser.GPSAltitude)) > 0 AND size < 13
      SDWrite(gpsParser.GPSAltitude)
    sdfat.pputc(COMMA)
    if (size := strsize(gpsParser.latitude)) > 0 AND size < 13
      SDWrite(gpsParser.latitude)
    sdfat.pputc(COMMA)
    if (size := strsize(gpsParser.longitude)) > 0 AND size < 13
      SDWrite(gpsParser.longitude)
    sdfat.pputc(COMMA)
    if (size := strsize(gpsParser.date)) > 0 AND size < 13
      SDWrite(gpsParser.speed)
    sdfat.pputc(CR)         
    sdfat.pclose
    outa[noparse][[/noparse]16] := 0
    waitcnt(clkfreq * 5 + cnt)

PUB SDwrite(strAddr )                                   ' Writes the string located at strAddr to the SD card
  repeat strsize(strAddr)                               ' loop for each character in string
    sdfat.pputc(byte[noparse][[/noparse]strAddr++])                        ' Write the character to the file that's open

Jay Kickliter

I realized that I forgot to add the 150ohm inline resistors. Could that be causing the problem? It does work most of the time.

CarlosFandango

I've found FSRW (with sdspiqasm) to be totally reliable - all in all, a very excellent piece of code. And
I'm working it very hard with ordinary file accesses mixed in with large numbers of block level operations.

If what you describe was happening in my code, I would initially be looking for coding errors that were
inadvertently creating files I didn't want. Over and above that I have found that it also pays to consider
such things as stack space as the possible source of such issues.

In general I find that it's better to write specifc code that tests any distinct object functionality, and which
will prove that the object is working as expected. In order to test functionality in this way the test shell
should be absolutely as short and as concise as possible. Then you will hopefully be able to determine
whether it's a hardware or software error, and much more easily.

rokicki

First, with the qasm drives, you specifically do *not* want to use the inline 150 ohm resistors.

If you do, things will almost certainly not work (the RC time constant will be sufficiently high that
your rise and fall times will stink and the card probably won't see the data).

Second, if you are getting broken file names, that's probably due to something somewhere
overwriting memory somewhere. I would:

1. Make sure you're using the latest fsrw (I updated it last month); there was a bug in there.

2. Are you plugging/unplugging the card while the prop is on? If you are, try not to do this
and see if it makes a difference.

3. Are you using multiple cogs? See if you can reproduce it using only a single cog.

Fundamentally, what you need to do is figure out how to make it happen *reliably*. Once you
can get the bug to occur reliably, then you can start eliminating code chunks and/or objects
until you reduce the problem to the minimum code. Then we can figure out what's wrong.

mcstar

Is there a way to use fsrw with more than one cog? I've mounted the Sd card in one cog, then I open a file, read from it and close the file. Then I attempt to mount it again in another cog (long after the first cog closed the file) and the second cog hangs on the call to mount. Is there a way to "unmount" the card so other cogs can use it? I suppose a work around would be to make a single cog responsible for all disk access, but has anyone else run into this or is it only my code?

Mike Green

The SD card driver is not designed for use by more than one cog.

mcstar

OK, thanks Mike, I'll redesign the file access to use one cog then. I just wanted to make sure I didn't miss something.

Harrison.

You could try the one I posted here: http://forums.parallax.com/showthread.php?p=751612. It supports multiple open files and should support access from separate cogs. Beware that it is based on a slightly older version of fsrw which has a bug when your code uses both .pwrite(...) and .pputc(...).