SD card problems

Ale

I have been trying (after everyone got it working ) to get the SD card to work without any luck :-(

I am using the fsrwFemto and sdspiFemto sources from the 3.007 FemtoBasic source.

My card is connected as follows:

Pin 1 (Alias /CS) to PA15
Pin 2 (Alias DI) to PA14
Pin 5 (Alias CLK) to PA12
Pin 7 (Alias DO) to PA13

There are pull-up of 13 kbytes in all other lines. Pin 4 is +3.3V and 3 and 6 are GND.

I initialize the card as follows:

CON
sdCS = 15
sdDI = 14
sdCLK = 12
sdDO = 13

VAR
  long i2cCtrl
  byte tbuf[noparse][[/noparse]20]

OBJ
  sdfat: "fsrwFemto"
  term: "FullDuplexSerial"

pub go | x
   x := \start
   term.str(string("Returned from start", 13))
   term.dec(x)
   term.tx(13)

PUB start | r, sta, bytes
   term.start(31, 30, 0, 9600)
   term.str(string("IOProp: Mounting.", 13))
   sdfat.start(@i2cCtrl)
   sdfat.mount(sdDO, sdCLK, sdDI, sdCS)
   term.str(string("Mounted.", 13))
   term.str(string("Dir: ", 13))

Now I only get as far as the error: Returned from start -1669 either there is a card or not, but do not be that fast... When I sniff the communication with a ligic analyzer I see the following picture:

I thought the driver had to clock, i.e. using CLK! at least 80 times before any command could be sent... here there is nothing, nothing besides those 8 pulses in DI. What is going on ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

CassLan

Have you tried using any other program that already has working SD Card code on your hardware? I
m thinking of mparks ED, or OBCs PropDOS? This way you could rule out if its yours hardware or your software.

Rick

Ale

I tried rockiki's demo... same result :-(

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Cluso99

Ale: Are the 4 SD pins used for anything else?

The femto routine requires an eeprom to be present. I modified the sdspifemto routine to release the SD cards D0 pin (because I use it for multiple purposes). Otherwise it just ran on the TriBlade with the pin changes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

mynet43

Ale,

I think the problem may be with your call to
sdfat.start(@i2cCtrl)

You defined i2cCtrl as:
long i2cCtrl

I believe it needs to be defined as:
long i2cCtrl

The fsrwFemto routine needs two longs to work with.

Jim

mynet43

Oops!

I forgot the forum formatting doesn't allow you to show these subscripts [noparse]:([/noparse]

So it should be:

long i2cCtrl with two longs defined...

Hard to tell what you really have it the forum doesn't show what you enter.

Jim

Ale

It says of course i2cCtrl[noparse][[/noparse] 2 ] as it should... again the formatting. The pins are not used for anything else.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Mike Green

I don't see anything wrong with your code or your description of the wiring. The mount routine should produce about 32K clocks. The negative return value is -string("...") with an error message. DI should be an output (from the Prop) and DO is an input (to the Prop) since the names are SD card relative. You're not showing the _CLKMODE and _XINFREQ definitions, but the SPI routines should work even with the RCFAST clock as long as the compiler sets CLKFREQ to something reasonable (I don't know if it does this).

Check your wiring and try another SD card.

mpark

It might be the 13 kbyte pull-ups [noparse]:)[/noparse]

Ale

mpark: those are a h3ll of a bunch of resistors ... too much Futurama causes that .

I did not say, I'm using a 6.5 MHz crystal with PLL16x. (But that sure is not the problem). I'm worried about the lack of clock pulses...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Mike Green

Your 6.5MHz crystal with PLL16X could be the problem. That's a 104MHz clock. From the datasheet curves on maximum operating frequency, you should be ok at room temperature at 3.3V supply voltage. That's based on a small sample of chips. You may have a Propeller that's less tolerant.

My view is that you may be able to get away with operating out-of-spec, but, if you're running into problems, you first make sure that you're operating within specs ... your problems may go away. If not, you leave it that way (in spec) until you figure out what's really wrong and fix it, then try it out-of-spec.

Rayman

First, you don't need any pullups. I don't think the clock is a problem. My guess would be you have some wires crossed somewhere... Make sure you don't have DO and DI backwards...

Check out the table and pin photo on this page:
http://www.rayslogic.com/propeller/Programming/SD_Card/SD_Card.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Ariba

Ale said...
My card is connected as follows:

Pin 1 (Alias /CS) to PA15
Pin 2 (Alias DI) to PA14
Pin 5 (Alias CLK) to PA12
Pin 7 (Alias DO) to PA13

You should swap the PA12 and PA13 connection: DO on PA12 and CLK on PA13. Many application that uses Rockikis SD card driver define only an SD-basepin and expects the pins in the order: DO, CLK, DI, CS.

But this can not be the only reason, for your problem, because the Femto code allows to define all the pins separatly.

Andy

Clock Loop

Mike Green said...
Your 6.5MHz crystal with PLL16X could be the problem. That's a 104MHz clock. From the datasheet curves on maximum operating frequency, you should be ok at room temperature at 3.3V supply voltage. That's based on a small sample of chips. You may have a Propeller that's less tolerant.

I have a prop that won't clock above 103 mhz. For me that could be the result of a bad layout (or a lack of a layout, my prop is deadbugged.) Above 103 mhz the prop starts to run the program wrong, it will partially work for a while.

But even a deadbugged prop clocks in at 103 mhz. Im sure if I threw in a few caps right on top of the VDD/VSS pins, i could get more speed. Perhaps you just need a few caps near the props VDD/VSS pins?

Ale

I'll try to resolder DO and CLK. But I'm using the femto's version because I could (theoretically) get away with using pins that are not in a row.

BPM: My layout is a bit better, 2 decoupling CAPS 1uF and 100 nF, crystal is quite close, few mm away... see the layout in my sig's page. I'll investigate further.

Rayman: I got a head start looking at your page. But now I do not know what is wrong

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Rayman

If the clock were the issue, it should work if you change PLL16X to PLL8X...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Mike Green

The FemtoBasic driver is very happy with the SPI pins assigned to any I/O pins in any order

Sapieha

Hi Ale.

If it was only Clock isue You wil not have that fine Data pulses on DI pin.
Have You PulUpps on all SD signal pin's ?.
I use 15K resistors and it funktion corectly with 15MHz PLLx8

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Ale

I downloaded propDOS, and bought a MMC card (because I have some MMC-only sockets) but I get the error InitSDCard

Does anyone knows if the current driver in propDOS supports MMC cards at all ?
I can see that the card answers something like :
CMD 40: response 01
CMD 77!: 05
CMD 69!: 05

The 77 and 69 shouldn't be 55 and 41 ?! (I'm testing at 48 MHz, so no clock problems)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Post Edited (Ale) : 6/12/2009 1:14:56 PM GMT

Ale

Yes, yes, yes !!!

There is a small bug in sdspiFemto.spin:

The commands should be $55 and $41 HEX and not decimal !!

Here the fixed version: The following code may only work with MMC cards !

:initRead               call    #spiRecvByte            ' Output a stream of 32K clocks
                        djnz    spiBlkCnt,#:initRead    '  in case SD card left in some
                        mov     spiOp,#0                '   undefined state
                        mov     spiParm,#0
                        call    #spiSendCmd             ' Send a reset command and deselect
                        or      outa,spiMaskCS          '  to get SD card into SPI mode
:waitIdle               mov     spiOp,#$55
                        call    #spiSendCmd             ' APP_CMD (Application Specific)
                        mov     spiOp,#$41
                        call    #spiSendCmd             ' SEND_OP_COND (Initialization)
                        or      outa,spiMaskCS
                        cmp     i2cData,#1         wz   ' Wait until response not In Idle

The two images show one the bad commands that get both a $05 answer, and the good commands with the right answer for the $41 command ($01)

See next posts please!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

Post Edited (Ale) : 6/12/2009 4:23:29 PM GMT

Mike Green

According to Sandisk's SD protocol manual (attached), those commands are correct (see page 5-9) as decimal 55 (Cmd55) and decimal 41 (ACmd41). Somewhere I have another SD protocol description that says the same thing. It's odd that your card responds properly to commands that the formal documentation says that they shouldn't. I'm confused. I spent a lot of time going through the formal SD card documentation making sure that I got everything right and I tested it with several SD cards I had on hand including some Sandisk cards.

Ale

Mike:

I generated some confusion. Firstly I tested a SD card (well, three) with a SD socket. It does not work, there is something funny with that socket.
Then I bought a MMC card and used a MMC only socket. This seemed to work (post: I downloaded propDOS...) but failed to mount because the command 55 (dec) + 0x40 = 0x77 is unknown or something like that. Command 41 (dec) is also unknown. But CMD1 (0x41) works. Why are you using CMD55/ACMD41 instead of CMD1 directly ? (I see that the commands are in dec, I saw them in another table where 0x40 was already or'd to them). The point is as it is it does not seem to be compatible with MMC cards, at least not with this "extreme memory" card I got :-(.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

mynet43

I noticed that Mike's spec is dated 2003.

It's probably fine, but I discovered a newer one from 2006.

It seems to cover a lot of the same stuff, so you could compare the two if that helps.

Jim

Mike Green

There was a change to the initialization command sequence from the MMC card protocol to the SD card protocol. The Cmd55/ACmd41 sequence is for SD cards only as far as I can tell. The MMC card protocol requires Cmd0/Cmd1. There were some suggestions for initializing either an MMC or SD card by looking at the response from the card and using different command sequences. Unfortunately, the cog is very tight on memory and there was no room for anything other than the basic SD card initialization. I should have documented it more thoroughly. I'll add a comment for future releases.

Ale

I see, there are a few longs free (8 exactly), so it is quite tight.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92

lonesock

I posted a version of Rokicki's FSRW code in this thread:

http://forums.parallax.com/showthread.php?p=746666

That version can handle MMC, SD, and SDHC cards.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

mynet43

@ lonesock,

I tried the SD/SDHC driver you referenced.

It says to use this (sdspifasm_ls) in place of "sdspiqasm" in the "fsrw" routine.

I tried this, by modifying a version of fsrw. When I did this, it worked perfectly with a standard SD card (1 GB).

However, when I tried an SDHC card (8 GB), I got an abort error of -20.

When I looked in fsrw, I discovered this piece of code in the "mount" routine:

   if (brlong(@buf+$36) <> constant("F" + ("A" << 8) + ("T" << 16) + ("1" << 24)) or buf[noparse][[/noparse]$3a] <> "6")
      abort(-20) ' not a fat16 volume

Does anyone know if there is a special version of 'fsrw' that will work correctly with this driver?

Thanks for the help. Tell me if you think I should move this to another thread.

Jim

lonesock

mynet43 said...
...
However, when I tried an SDHC card (8 GB), I got an abort error of -20.

You are exactly right, my modified code can mount MMC & SD & SDHC cards, but FSRW handles the file system. It only handles FAT16 as of right now. FAT16 can only handle 2GB partitions.

You could partition a flash card > 2GB with multiple 2GB partitions, each of which is formatted as FAT16, except you can't under Windows, as Windows will not let you put more than one partition on a flash drive. So you could do it under Linux, but I'm not sure if Windows would read anything other than the 1st partition.

Typically cards larger than 2GB are formatted FAT32, which can handle larger partitions. The FAT32 code isn't too much more complicated than FAT16, but I think there are various reasons what FSRW does not support FAT32. 1) most people are happy with < 2GB, 2) there are licensing issues with long filename support, and 3) nobody just jumped in and added FAT32 support yet (at least I haven't [noparse][[/noparse]8^)

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

mynet43

Aha, I misinterpreted your original post.

I thought it said it could handle MMC, SD and SDHC cards. I didn't realize they had to be formatted as FAT16.

The larger ones always come formatted as FAT32.

I'll stick with the SD cards for now. I hope they keep selling them.

Jim