sc_sdcard is now running on XC-3 board

[jagspaul]

now I am getting quite high speed (Read=3.5MB/s , writing 2.5 MB/s) on 4bit SD interface. Actually that time I was using debug build instead release. After trying with release build I got this speed.

thanks
jags

[LyleHaze]

Greetings!
I also am having some trouble with the SDcard software.
I am running on an XS1-L02 C5 chip.
I have the following connections wired for
a 4 bit interface to the SD Card:

SD card pin number XMOS pin
9 P4C1
1 P4C0
2 P1H0 with 10K pullup
3 Ground
4 3V3
5 P1J0
6 Ground
7 P4C3 with 10K pullup
8 P4C2

I am using an https://www.olimex.com/Products/Modules ... MOD-SDMMC/ board for the connection.
This board includes the 10K pullup resistors as indicated above.

I have checked every connection.
from SD_CardHost.xc I have:

Code: Select all

static SDHostInterface SDif[] = // LIST HERE THE PORTS USED FOR THE INTERFACES
//       CLK,         CMD,     DAT3..0,
{XS1_PORT_1J, XS1_PORT_1H, XS1_PORT_4C, 0, 0, 0}; // ports used for interface #0

in diskio.h I find:

Code: Select all

#define BUS_MODE_4BIT

when I run sdcard_test it fails after:

Code: Select all

    rc = f_getfree("0:", &fre_clust, &fs);

with FR_NO_FILESYSTEM, /* (13) There is no valid FAT volume */
I've tried a few different cards, no luck.

The programming adapter I have does NOT support printf(), so my
ability to gather troubleshooting information is a bit limited.

At this point I'm going to get a fresh copy of the SDCard software
to make sure I didn't screw something up, then maybe scope all the signals
to see if anything looks wrong in hardware.

ANY suggestions on where else to look would be greatly appreciated.

Thanks,
LyleHaze

[LyleHaze]

Follow Up:

created a new "chprintf()" that I can use to replace printf statements. all output
goes to a streaming channel. So I can replace printf statements with something that
works for me. :)

I rebuilt the entire project, careful to replace all files related to sc_sdcard with
freshly downloaded replacements.. just in case I edited something incorrectly.

reset the define 4_bit, set the pins correctly, all compiles fine.

Any attempt to open or access the card returns error 13, FR_NO_FILESYSTEM.

I tried changing #define _use_mkfs to 1 so I could try formatting the card, but
I get a couple warnings:
passing argument 3 of 'disk_ioctl' from an incompatible pointer type.

I'm sure I can edit the warning away, but I hesitate to cause new problems before
solving old ones.

I copied the sdcard_test and gave it a run.. the very first function that accesses the
sd card (f_getfree()) returns error 13, FR_NO_FILESYSTEM.

I tried f_mkfs(0,0,512) to format.. failed with FR_NOT_ENABLED.
This is the first possible error except for checking the input arguments, and is returned
if FatFS(drv) returns NULL.

Still struggling, open for ANY suggestions.

Thanks,
LyleHaze

[Lele]

Did you try to format the card FAT32 elsewhere (in a PC) then use in the project?
Also try to do raw access using this sample code:
http://www.xcore.com/forum/viewtopic.php?p=12285#p12285

Lele

[LyleHaze]

Thank you for your help. :)
I tried formatting FAT32 in my XP machine, no difference.
I ran the code you pointed to, after putting it in a thread
and changing printf() to chprintf()..
5120 bytes written. Write rate: 3436KBytes/Sec
5120 bytes read. Read rate: 2070KBytes/Sec

This was (as you can tell) ten blocks of 512.

On the bright side, it's the most positive result I have seen yet! :) :)

ThIs is on a 2Gig card, I can get brand names and such if you like.
Earlier tonight while still digging for clues, I wrote little apps to toggle
each pin used for the SDCard one at a time at 1KHz.. Checked with a scope
at the socket and all looked great. So I hopefully have ruled out wrong
wiring or mislabeled terminals. (This is only the second project ever built on this
board, so the possibility of having the pins named wrong caught my attention)

A quick look with WinHex at the sd card (after the test) shows:
Almost all zero data up to 0057C9A5
lots of random garbage (some sequential counts) until 60BF1BA3
And all zeros from there on.

Again, thanks for your help.. and I'm up for anything you suggest, after I've
slept for a few hours. (now 4:AM here)

LyleHaze

curious..
I added a loop to check the returned values.. exact copy here:

Code: Select all

for(i = 0; i < sizeof(Buff); i++)
{
    if(Buff[i] != (i + i / 512))
    {
        chprintf(chanout, "Buffer readback failure at byte %d\n", i);
        return(234); // random non-zero return value
    }
}

Then I ran this a few more times: Results look like:

Code: Select all

Write rate: 1130KBytes/Sec
5120 bytes read. Read rate: 3392KBytes/Sec
Buffer readback failure at byte 2
5120 bytes written. Write rate: 2694KBytes/Sec
5120 bytes read. Read rate: 1886KBytes/Sec
Buffer readback failure at byte 2
5120 bytes written. Write rate: 948KBytes/Sec 
5120 bytes read. Read rate: 3406KBytes/Sec
Buffer readback failure at byte 1
5120 bytes written. Write rate: 1876KBytes/Sec 
5120 bytes read. Read rate: 1883KBytes/Sec
Buffer readback failure at byte 2

So it looks like results are all over the place..

Just trying to include as much information as I can..
Now 5:AM. I'm really going to sleep this time!

[jagspaul]

Hi LyleHaze,
I am not surprised to see you are also puzzle with XMOS SD card 4 bit interface.
Actually I have little bit bitter experience on this issue. If you go through this topic very carefully, I am sure you could solve this.

XMOS port is very noise sensitive. You must give attention on PCB noise issue. I also got puzzled with SD Card break out board. finally I got success on direct soldering a mocro SD card jacket with a bus cable as short as possible. still now my break out board is not working with XMOS. I also suggest you to pull up D0-D3 & CMD port.

Please find my hardware picture in this topic and try to follow. Also you make a sector 0 dump and post. If possible post picture of your hardware setup, It will be useful to make any farther comment.

EDIT:
Please post code of SDCardHost4Bit.xc . As per my hardware code is

Code: Select all

static SDHostInterface SDif[] = {XS1_PORT_1E, XS1_PORT_1O, XS1_PORT_4F, 0, 0, 0};

Post value of sector 0 word location 510. For a valid FAT it must be 0xaa55.

Regards
jags

[LyleHaze]

A bit of sleep.. and back into it.

jagspaul:
The pin defines in my project are:

Code: Select all

static SDHostInterface SDif[] = // LIST HERE THE PORTS USED FOR THE INTERFACES
//       CLK,         CMD,     DAT3..0,
{XS1_PORT_1J, XS1_PORT_1H, XS1_PORT_4C, 0, 0, 0}; // ports used for interface #0

And I verified all connections with a scope.

This socket does use a short ribbon cable, and if I want to mount direct to the interface card I'll need to buy a different socket adapter. The datasheet for the one I'm using now, along with pictures and descriptions, is here

A photo of my setup right now looks like:

003small.JPG

So you can see why I can't attach mine the same way you did. :)

I will be giving a presentation on this project in less than a week.
I'd really like to show a working project if possible.

I wonder if slowing down the interface speed might improve performance?
Better working slow than not at all..

Thanks for your help!
LyleHaze

[Lele]

I agree with Jags, probably the flat length
Lele

[LyleHaze]

By what Jagspaul has said, making the wires shorter has improved, but not completely solved the problem. Since I will be sharing this project with a bunch of others, many with even less experience that myself (scary, I know), I need to find a way to make it as solid as possible, even if it means a loss of speed.

When I added the readback tests to the raw performance test, the speed numbers were random, and the readback would fail on the first or second byte. Random results are a pretty sure sign of interface issues.

Just for curiosity, I went in to SDCard_4Bit.xc (something like that, it's on the other machine) and added a bunch of short delays throughout the code, mostly where SD clocking was being done.

Even though I made the delay _too_long_ for testing, I got back much more reliable results.
The read/write speeds are now about 1/2 Megabyte per second, and the readback error is ALWAYS at character 9. We write a 9, we read back a 0.

OK, so still not just right, but at least it's doing the exact same thing every time.
I do not understand enough about SD and File storage to know if the error is related
to the file system or perhaps I missed a delay at the end of a loop or something.

All quite interesting.. maybe I'll try the sd_example_code with these new edits in place
and see if it fares any better.

I really don't want to post the modified code, as it is
a> Not mine
b> Not working
c> not very fast
but it does point to one possible way to resolve these issues.

I do have a question though:
Has ANYONE reported errors like this when using the SPI code?
If not, maybe I just need to re-wire the socket and go that way.

WinHex shows the data write was great.. starting at sector 10,
looks like it's working great.. I wonder why the readback keeps
failing at BYTE 9?

Code: Select all

5120 bytes written. Write rate: 514KBytes/Sec                                           
5120 bytes read. Read rate: 621KBytes/Sec                                               
Buffer readback failure at byte 9                                                       
 wrote 9, read 0 

Thanks for all the help,
LyleHaze

[LyleHaze]

More information.. more clues:
As I said before, I checked with WinHex and the data wrote beautifully.
I checked it carefully and saw no errors at all.

Curious about the read error at byte 9, I modified the read buffer test
to continue checking regardless of errors found. In that data lie some clues
as to where the raw read is tripping up.

Almost all bytes after byte 9 have errors, but most of them are
sequential errors: Every value is off by the same offset.

I don't want to dump a 282K text file here, but I'll show the first few lines,
so ytou can see what I am seeing. Here's the top of the file:

Code: Select all

5120 bytes written. Write rate: 521KBytes/Sec
5120 bytes read. Read rate: 466KBytes/Sec
Buffer readback failure at byte 9: wrote 9, read 0
Buffer readback failure at byte 10: wrote 10, read 160
Buffer readback failure at byte 11: wrote 11, read 0
Buffer readback failure at byte 12: wrote 12, read 0
Buffer readback failure at byte 13: wrote 13, read 16
Buffer readback failure at byte 14: wrote 14, read 17
Buffer readback failure at byte 15: wrote 15, read 18
Buffer readback failure at byte 16: wrote 16, read 19
Buffer readback failure at byte 17: wrote 17, read 20
Buffer readback failure at byte 18: wrote 18, read 21
Buffer readback failure at byte 19: wrote 19, read 22
Buffer readback failure at byte 20: wrote 20, read 23
Buffer readback failure at byte 21: wrote 21, read 24
Buffer readback failure at byte 22: wrote 22, read 25
Buffer readback failure at byte 23: wrote 23, read 26
Buffer readback failure at byte 24: wrote 24, read 27
Buffer readback failure at byte 25: wrote 25, read 28
Buffer readback failure at byte 26: wrote 26, read 29
Buffer readback failure at byte 27: wrote 27, read 30
Buffer readback failure at byte 28: wrote 28, read 18
Buffer readback failure at byte 29: wrote 29, read 2
Buffer readback failure at byte 30: wrote 30, read 18
Buffer readback failure at byte 31: wrote 31, read 34
Buffer readback failure at byte 32: wrote 32, read 50
Buffer readback failure at byte 33: wrote 33, read 66
Buffer readback failure at byte 34: wrote 34, read 82
Buffer readback failure at byte 35: wrote 35, read 98
Buffer readback failure at byte 36: wrote 36, read 114
Buffer readback failure at byte 37: wrote 37, read 130
Buffer readback failure at byte 38: wrote 38, read 146
Buffer readback failure at byte 39: wrote 39, read 162
Buffer readback failure at byte 40: wrote 40, read 44
Buffer readback failure at byte 41: wrote 41, read 34

so around bytes 9, 10, 11, 12 things got screwy.. But we come
out of that reading 3 bytes ahead of the correct place. This pattern
holds until byte 28, where we lose the timing again. This pattern repeats
throughout the data. most of it is correct data from the wrong location.

I checked the data on the SD card, it is sequenced correctly.
So apparently something in the read loop is losing sync occasionally.
It might be caused by my delays, but since they did not harm the
write process, maybe not.

Still curious to learn if anyone has had issues with the SPI module.

I'm digging as deep as I can.. I hope someone finds this useful, or
at least amusing! :)

LyleHaze