safe_spi error codes

pgbpsu

Can anyone help me decipher an error code from safe_spi (the workhorse of fsrw)?

I'm using lonesock's safe_spi version 0.3.0 2009 July 19 to work with an SD card directly at the block level. My card is working because I'm able to communicate with it. However, when I try to read the first block on the disk I get an error 252.

  mounted     := -1
  uarts.str(DEBUG,string(13,13,13,"Trying to locate the SD card. This takes one cog. "))
  mounted:=sd.start(SD_Basepin)
  waitcnt(clkfreq + cnt)                   

  uarts.str(DEBUG,string(13,"Card we are working with: "))
  case mounted
    1 : uarts.str(DEBUG,string("MMC",13))
    2 : uarts.str(DEBUG,string("SD",13))
    3 : uarts.str(DEBUG,string("SDHC",13)) 
    other : uarts.str(DEBUG,string("UNKNOWN",13))


  uarts.str(DEBUG,string(13,"Result of readblock command: "))
  mounted := \sd.readblock(0,@blockZero)
  uarts.dec(DEBUG, mounted)

where blockZero is defined in the VAR sections as:
byte blockZero[512] ' set aside 512 bytes as block zero stuff

The above code produces:

Trying to locate the SD card. This takes one cog.
Card we are working with: SDHC

Result of readblock command: 252

And finally the readblock method from safe_spi

PUB readblock( block_index, buffer_address )
  if SPI_engine_cog == 0
    abort ERR_SPI_ENGINE_NOT_RUNNING
  if (buffer_address & 3)
    abort ERR_BLOCK_NOT_LONG_ALIGNED
  SPI_block_index := block_index
  SPI_buffer_address := buffer_address
  SPI_command := "r"
  repeat while SPI_command == "r"
  if SPI_command < 0
    abort SPI_command

There are some ERROR codes defined at the top of safe_spi, but none that equal 252. Without the abort trap when calling the readblock method, the code hangs right where the method is called.

I looked at FSRW and I believe I'm using this correct. Anyone know what error 252 means?

Stepping back to a (much) older version of FSRW and using sdspifasm to read block zero, I get a zero as the return value. And, even if I don't use the abort trap operator ( \ ) I still get a zero from the readblock method without hanging. The hardware hasn't changed so I suspect I'm either using lonesock's method incorrectly, or its not meant to be used this way. I'd like to use the newer version of the block level methods because they are faster. I wouldn't be fiddle with the block layer if speed weren't an issue.


Any thoughts are greatly appreciated.
Thanks,
Peter

lonesock

Hi, Peter.

All the error codes thrown by the safe_spi driver were intended to be negative, so I don't know where a positive 252 could come from. Some things to try:

* run it at a lower PLL (like 8x)
* make sure the card can be formatted and read using a computer
* try reading the same block multiple times in a row, and see if you get the same error condition for each
* try a different card (maybe of different type...MMC/SD/SDHC)
* archive the project and email it to me (the same user name as on this forum, at gmail.com)

Sorry I can't be of more help,
Jonathan

pgbpsu

Hi Jonathan-

I'll give the slower clock rate a try. When I was running these test I know the card was readable. At this point however, I've now re-written the first block (using an older version of the block write methods) so now it's not readable by any machine- at least not using normal filesystem mounts. I can still read it using dd. I'll try another card and see what that gives. At the moment it's not as urgent as I first thought since I've got a working version. Do you know if/how much faster your block layer is than Tom's original FSRW block routines?

In this application it's all about speed so if there's little difference there's no need to solve this.

Thanks,
Peter

lonesock

Well, from what I can tell, the old version sdspiqasm would get approximately 300 KBytes/s read and write, though that is via FSRW, not raw access. The safe_spi driver can get you over 900 KBytes/s read and write, though with raw access the read speeds are just over 1MB/s, and the raw writing speed is nearer 2MB/s. I can get more exact numbers if you wish, but the short answer is, the newest version is much faster. (I haven't tried Kye's latest code...maybe that is fast enough?)

Jonathan

pgbpsu

There's so much else for me to tackle in this particular application, I think I'll work out the rest of the code and return to this if speed is still an issue. I was hoping this would be a simple fix, like I was just using it incorrectly : (
At the moment speed isn't my biggest problem and the modularization of the block level codes should allow me to return to that and swap it out without change to the rest of the code.

Thanks again for the suggestions.
Peter