sc_sdcard is now running on XC-3 board

Technical questions regarding the XTC tools and programming with XMOS.
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

sc_sdcard is now running on XC-3 board

Post by jagspaul »

I want to play video file on my XC-3 LED tile from SD card as video source. In this board only two 1-bit port and 2 or 3 4-bit ports are available so I have only option to use 4-bit data interface. I made hardware connection as follows.

Sdcard port ----------------- Xmos port
------------------------------------
D0 ---------------------------- XS1_PORT_4F3
D1 ---------------------------- XS1_PORT_4F2
D2 ---------------------------- XS1_PORT_4F1
D3 ---------------------------- XS1_PORT_4F0
CMD -------------------------- XS1_PORT_1O
CLK --------------------------- XS1_PORT_1E

And in the source file I have changes as following below.
Makefile -------- TARGET = XC-3
diskio.h -------- #define BUS_MODE_4BIT

SDCardHost4Bit.xc -------------
static SDHostInterface SDif[] = {XS1_PORT_1E, XS1_PORT_1O, XS1_PORT_4F, 0, 0, 0};

I checked with both FAT & FAT32 SD card but unfortunately I get error as following below on both the SD card.

Code: Select all

Failed with rc=13.
Can any body tell me what’s wrong I have done.
Is there anybody who got success on sc_sdcard module with 4 bit interface ready to share some information.

Thanks
jags


jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

Code: Select all

typedef struct SDHostInterface
{
  out port Clk; // a 1 bit port
  port Cmd; // a 1 bit port. Need an external pull-up resistor if not an XS1_G core
  port Dat; // a 4 bit port. Beware: connect D0 to PortBit3, D1 to PortBit2, D2 to PortBit1, D3 to PortBit0
            // D0 (PortBit3) need an external pull-up resistor if not an XS1_G core
/*
   D D C     C   D D
   a a m     l   a a
   t t d     k   t t
   1 0           3 2
   __________________
  /  | | | | | | | | |
  || D C - + C - D D |
  |D 3 M G 3 L G 0 1 |
  |2   D N . K N     |
  |      D 3   D     |
  |        V         |
*/
  /* fields returned after initialization */
  unsigned long Rca; // RCA returned by SD card during initialization. Relative card address.
  unsigned char Ccs; // CCS returned by SD card during initialization. Card capacity status: 0 = SDSC; 1 = SDHC/SDXC
  unsigned long BlockNr; // number of 512 bytes blocks. Returned by initialization.
} SDHostInterface;
Why this awareness to connect XMOS 4-bit port to SD card 4-bit data bus reversely. If we connect directly i.e. D0-> Port_d0 then what blunder will happen?

I have check low level disk I/O routine working fine.
DRESULT drel1;
DSTATUS stat1;
stat1 = disk_initialize(0);
printf("\nInit=%u.\n", stat1);
drel1 = disk_write(0,"jagspaul",100,10);
printf("\nWrite=%u.\n", drel1);
for( i = 0; i < 20; i++) Buff = 0;
drel1 = disk_read(0,Buff,100,10);
printf("\nread=%u.\n", drel1);

printf("\nresult=%s.\n", Buff);
Output:
jagspaul


Waiting for your help.

Thanks
jags
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

Strange!!!!!!!!!
No body here has come to help??????
Any ways I am sharing some of my observations.

Regarding reverse connection of 4-bit data I cheeked and found it is all write.

I have made a simple low level disk IO test on XMOS & STM32 board.
On XMOS board I write a string (“XMOS SIDE”) at sector no. 123 and read a string at sector no. 456.

On STM32 board I write a string (“STM32 SIDE”) at sector no. 456 and read a string at sector no. 123.

As a result I found read string “STM32 SIDE” on XMOS terminal and string “XMOS SIDE” on STM32 terminal. It shows string write by XMOS readable by STM32 and vice versa. As FAT32 on my STM32 board is running well so we can make a conclusion that low level disk IO of XMOS side is perfect.

Now we have to check FAT32 library.


Regards
jags
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm

Post by Lele »

reverse connection of 4-bit data is because of the way data are shifted out from buffered XMOS port (cards require most significant nibble first so every 32bit (big endian) data buffer is bit reversed making msb to be at port line 0)
As far error 13 in ff.h file there is the list of error codes:

Code: Select all

typedef enum {
  FR_OK = 0,        /* (0) Succeeded */
  FR_DISK_ERR,      /* (1) A hard error occured in the low level disk I/O layer */
  FR_INT_ERR,        /* (2) Assertion failed */
  FR_NOT_READY,      /* (3) The physical drive cannot work */
  FR_NO_FILE,        /* (4) Could not find the file */
  FR_NO_PATH,        /* (5) Could not find the path */
  FR_INVALID_NAME,    /* (6) The path name format is invalid */
  FR_DENIED,        /* (7) Acces denied due to prohibited access or directory full */
  FR_EXIST,        /* (8) Acces denied due to prohibited access */
  FR_INVALID_OBJECT,    /* (9) The file/directory object is invalid */
  FR_WRITE_PROTECTED,    /* (10) The physical drive is write protected */
  FR_INVALID_DRIVE,    /* (11) The logical drive number is invalid */
  FR_NOT_ENABLED,      /* (12) The volume has no work area */
  FR_NO_FILESYSTEM,    /* (13) There is no valid FAT volume */
  FR_MKFS_ABORTED,    /* (14) The f_mkfs() aborted due to any parameter error */
  FR_TIMEOUT,        /* (15) Could not get a grant to access the volume within defined period */
  FR_LOCKED,        /* (16) The operation is rejected according to the file shareing policy */
  FR_NOT_ENOUGH_CORE,    /* (17) LFN working buffer could not be allocated */
  FR_TOO_MANY_OPEN_FILES,  /* (18) Number of open files > _FS_SHARE */
  FR_INVALID_PARAMETER  /* (19) Given parameter is invalid */
} FRESULT;
may be low level writing corrupted the fat table? Have you re-formatted?
regards
Lele
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

Thanks Lele for your response.
There is no issue with SD card FAT as it is working on my STM32 board and also windows.

I have replaced the FAT library with a working one (my STM32) and get same result.Then I debug and found XMOS getting 0xffff at sector 0 byte location 510 instead 0xaa55. Then I take a dump of entire sector 0 on both the board XMOS & STM32. See below , XMOS board reading totally wrong data. And this make me sure that the issue is with low level IO.
XMOS DUMP:
235, 88, 144, 77, 83, 68, 79, 83, 53, 46, 48, 0, 2, 8, 38, 0
2, 0, 0, 0, 0, 128, 0, 3, 240, 15, 0, 0, 0, 0, 0, 0
3, 160, 11, 80, 224, 0, 0, 0, 0, 0, 0, 32, 0, 0, 0, 16
0, 96, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
2, 153, 17, 233, 149, 4, 228, 242, 4, 228, 20, 212, 82, 2, 2, 2
4, 100, 21, 67, 51, 34, 2, 2, 3, 60, 152, 237, 27, 207, 71, 184
236, 24, 237, 155, 208, 7, 200, 132, 224, 40, 165, 100, 11, 64, 140, 209
55, 48, 91, 159, 255, 248, 175, 22, 96, 182, 198, 64, 102, 11, 109, 24
14, 35, 255, 126, 40, 108, 220, 14, 208, 100, 22, 96, 183, 201, 102, 247
225, 102, 137, 70, 248, 131, 126, 22, 0, 117, 56, 131, 126, 42, 0, 119
50, 102, 139, 70, 28, 102, 131, 192, 12, 187, 0, 128, 185, 1, 0, 232
43, 0, 233, 72, 3, 160, 167, 219, 71, 216, 191, 10, 200, 76, 7, 65
115, 207, 247, 64, 155, 64, 235, 176, 112, 12, 209, 14, 190, 234, 11, 125
235, 229, 160, 151, 222, 190, 9, 140, 209, 108, 209, 150, 102, 6, 99, 180
111, 128, 130, 74, 0, 102, 106, 0, 102, 80, 6, 83, 102, 104, 16, 0
1, 0, 128, 126, 2, 0, 8, 82, 0, 11, 68, 27, 186, 165, 88, 165
100, 12, 209, 48, 130, 28, 0, 129, 181, 90, 160, 133, 20, 0, 108, 16
16, 132, 13, 0, 228, 96, 43, 68, 40, 165, 100, 8, 191, 76, 209, 59
9, 102, 88, 102, 88, 102, 88, 102, 88, 235, 42, 102, 51, 210, 102, 11
116, 225, 134, 111, 127, 31, 236, 40, 172, 166, 104, 189, 6, 108, 30, 161
7, 118, 26, 134, 214, 138, 86, 64, 138, 232, 192, 228, 6, 10, 204, 184
1, 2, 205, 19, 102, 97, 8, 37, 79, 241, 195, 0, 2, 102, 64, 73
8, 87, 31, 252, 52, 229, 68, 196, 69, 34, 2, 2, 2, 2, 2, 0
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
0, 208, 165, 38, 86, 214, 247, 102, 82, 6, 70, 151, 54, 183, 50, 6
247, 34, 6, 247, 70, 134, 87, 34, 6, 214, 86, 70, 150, 18, 239, 240
208, 164, 70, 151, 54, 178, 6, 87, 39, 38, 247, 47, 240, 208, 165, 7
38, 87, 55, 50, 6, 22, 231, 146, 6, 182, 87, 146, 7, 70, 242, 7
38, 87, 55, 70, 23, 39, 64, 208, 160, 0, 0, 0, 0, 10, 204, 189
128, 0, 5, 90, 165, 21, 94, 119, 46, 130, 171, 95, 111, 255, 255, 255
STM32 DUMP
DUMP: 235, 88, 144, 77, 83, 68, 79, 83, 53, 46, 48, 0, 2, 8, 38, 0
DUMP: 2, 0, 0, 0, 0, 248, 0, 0, 63, 0, 255, 0, 0, 0, 0, 0
DUMP: 0, 240, 58, 0, 181, 14, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0
DUMP: 1, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DUMP: 0, 0, 41, 145, 30, 153, 80, 78, 79, 32, 78, 65, 77, 69, 32, 32
DUMP: 32, 32, 70, 65, 84, 51, 50, 32, 32, 32, 51, 201, 142, 209, 188, 244
DUMP: 123, 142, 193, 142, 217, 189, 0, 124, 136, 78, 2, 138, 86, 64, 180, 8
DUMP: 205, 19, 115, 5, 185, 255, 255, 138, 241, 102, 15, 182, 198, 64, 102, 15
DUMP: 182, 209, 128, 226, 63, 247, 226, 134, 205, 192, 237, 6, 65, 102, 15, 183
DUMP: 201, 102, 247, 225, 102, 137, 70, 248, 131, 126, 22, 0, 117, 56, 131, 126
DUMP: 42, 0, 119, 50, 102, 139, 70, 28, 102, 131, 192, 12, 187, 0, 128, 185
DUMP: 1, 0, 232, 43, 0, 233, 72, 3, 160, 250, 125, 180, 125, 139, 240, 172
DUMP: 132, 192, 116, 23, 60, 255, 116, 9, 180, 14, 187, 7, 0, 205, 16, 235
DUMP: 238, 160, 251, 125, 235, 229, 160, 249, 125, 235, 224, 152, 205, 22, 205, 25
DUMP: 102, 96, 102, 59, 70, 248, 15, 130, 74, 0, 102, 106, 0, 102, 80, 6
DUMP: 83, 102, 104, 16, 0, 1, 0, 128, 126, 2, 0, 15, 133, 32, 0, 180
DUMP: 65, 187, 170, 85, 138, 86, 64, 205, 19, 15, 130, 28, 0, 129, 251, 85
DUMP: 170, 15, 133, 20, 0, 246, 193, 1, 15, 132, 13, 0, 254, 70, 2, 180
DUMP: 66, 138, 86, 64, 139, 244, 205, 19, 176, 249, 102, 88, 102, 88, 102, 88
DUMP: 102, 88, 235, 42, 102, 51, 210, 102, 15, 183, 78, 24, 102, 247, 241, 254
DUMP: 194, 138, 202, 102, 139, 208, 102, 193, 234, 16, 247, 118, 26, 134, 214, 138
DUMP: 86, 64, 138, 232, 192, 228, 6, 10, 204, 184, 1, 2, 205, 19, 102, 97
DUMP: 15, 130, 84, 255, 129, 195, 0, 2, 102, 64, 73, 15, 133, 113, 255, 195
DUMP: 78, 84, 76, 68, 82, 32, 32, 32, 32, 32, 32, 0, 0, 0, 0, 0
DUMP: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DUMP: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
DUMP: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 13, 10, 82, 101
DUMP: 109, 111, 118, 101, 32, 100, 105, 115, 107, 115, 32, 111, 114, 32, 111, 116
DUMP: 104, 101, 114, 32, 109, 101, 100, 105, 97, 46, 255, 13, 10, 68, 105, 115
DUMP: 107, 32, 101, 114, 114, 111, 114, 255, 13, 10, 80, 114, 101, 115, 115, 32
DUMP: 97, 110, 121, 32, 107, 101, 121, 32, 116, 111, 32, 114, 101, 115, 116, 97
DUMP: 114, 116, 13, 10, 0, 0, 0, 0, 0, 172, 203, 216, 0, 0, 85, 170
Then I test Low level IO with a simple code

Code: Select all

for(i=0;i<512;i=i+1)
	{
    	if(i<256)
    		Buff[i] = i;
    	else
    		Buff[i] = i - 256;
	}*/
    drel1 = disk_write(0,Buff,512,1);
    for( i = 0; i < 512; i++) Buff[i] = 0;
    drel1 = disk_read(0,Buff,512,1);

    for(i=0;i<512;i=i+16)
	{
		//printf("\n%x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x, %x",Buff[i],
		printf("\n%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d",Buff[i],
				Buff[i+1],Buff[i+2],Buff[i+3],Buff[i+4],Buff[i+5],Buff[i+6],Buff[i+7],
				Buff[i+8],Buff[i+9],Buff[i+10],Buff[i+11],Buff[i+12],Buff[i+13],Buff[i+14],Buff[i+15]);
	}

And found XMOS is dumping wrong
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 1
1, 17, 33, 49, 65, 81, 97, 113, 129, 145, 161, 177, 193, 209, 225, 242
2, 18, 34, 50, 66, 82, 98, 114, 130, 146, 162, 178, 194, 210, 226, 243
3, 19, 35, 51, 67, 83, 99, 115, 131, 147, 163, 179, 195, 211, 227, 244
4, 20, 36, 52, 68, 84, 100, 116, 132, 148, 164, 180, 196, 212, 228, 245
5, 21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197, 213, 229, 246
6, 22, 38, 54, 70, 86, 102, 118, 134, 150, 166, 182, 198, 214, 230, 247
7, 23, 39, 55, 71, 87, 103, 119, 135, 151, 167, 183, 199, 215, 231, 248
8, 24, 40, 56, 72, 88, 104, 120, 136, 152, 168, 184, 200, 216, 232, 249
9, 25, 41, 57, 73, 89, 105, 121, 137, 153, 169, 185, 201, 217, 233, 250
10, 26, 42, 58, 74, 90, 106, 122, 138, 154, 170, 186, 202, 218, 234, 251
11, 27, 43, 59, 75, 91, 107, 123, 139, 155, 171, 187, 203, 219, 235, 252
12, 28, 44, 60, 76, 92, 108, 124, 140, 156, 172, 188, 204, 220, 236, 253
13, 29, 45, 61, 77, 93, 109, 125, 141, 157, 173, 189, 205, 221, 237, 254
14, 30, 46, 62, 78, 94, 110, 126, 142, 158, 174, 190, 206, 222, 238, 255
1, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 0
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 1, 1
17, 33, 49, 65, 81, 97, 113, 129, 145, 161, 177, 193, 209, 225, 242, 2
18, 34, 50, 66, 82, 98, 114, 130, 146, 162, 178, 194, 210, 226, 243, 3
19, 35, 51, 67, 83, 99, 115, 131, 147, 163, 179, 195, 211, 227, 244, 4
20, 36, 52, 68, 84, 100, 116, 132, 148, 164, 180, 196, 212, 228, 245, 5
21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197, 213, 229, 246, 6
22, 38, 54, 70, 86, 102, 118, 134, 150, 166, 182, 198, 214, 230, 247, 7
23, 39, 55, 71, 87, 103, 119, 135, 151, 167, 183, 199, 215, 231, 248, 8
24, 40, 56, 72, 88, 104, 120, 136, 152, 168, 184, 200, 216, 232, 249, 9
25, 41, 57, 73, 89, 105, 121, 137, 153, 169, 185, 201, 217, 233, 250, 10
26, 42, 58, 74, 90, 106, 122, 138, 154, 170, 186, 202, 218, 234, 251, 11
27, 43, 59, 75, 91, 107, 123, 139, 155, 171, 187, 203, 219, 235, 252, 12
28, 44, 60, 76, 92, 108, 124, 140, 156, 172, 188, 204, 220, 236, 253, 13
29, 45, 61, 77, 93, 109, 125, 141, 157, 173, 189, 205, 221, 237, 254, 14
30, 46, 62, 78, 94, 110, 126, 142, 158, 174, 190, 206, 222, 238, 255, 1
242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254,
Then I read & dump the same sector on STM32 and found right result. That means some how XMOS disk_write() routine is working and disk_read() is not working.

This is very Strange what I found.

Please note that I am using G4 core and I have not used any external pull up.

Writing for help.

thanks
jags
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm

Post by Lele »

Hi Jags,
I run your code in my XC-1 and XC-2 boards (just added a drel1 = disk_initialize(0); at beginning and removed a mismatching */) and had good read values (0 to 255 twice).
I'm using SD2GB and SDHC4GB (no microSD and no 1.8V. compliant)
What size/kind of card are you using?
Also could be usefull to know the content of SDif[0].BlockNr and SDif[0].Ccs after disk_initialize.

Please do the same test at address 0 to avoid block/byte addressing mode misalignment( drel1 = disk_write(0,Buff,0,1); drel1 = disk_read(0,Buff,0,1);
if that works then try to manually change (0 to 1 or 1 to 0) the value of SDif[IfNum].Ccs that is loaded in the disk_initialize function at line
SDif[IfNum].Ccs = ((Resp[1] & 2)) ? 1 : 0;
(To check the raw card content I suggest a software for PC called "WinHex")
Lele
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

You have some missing nybbles and some extra nybbles that
read as 0xf. Sounds like you have some noise on your board?
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

I am using micro SD 2GB
after disk init I get
SDif[IfNum].BlockNr=3af000, SDif[IfNum].Ccs=0

My disc_write() routine is working fine only I have problem with disk_read().

Any help?????

jags
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm

Post by Lele »

Looks correct for 2gb card:
0x3af000*512=1977614336bytes card size
and Ccs=0 (means byte address mode) is fine for cards less than 4GB.
I can only suggest to double check wiring(power and dat lines).
I'm using wery short wires to avoid clock reflection/crosstalk that could cause multiple un-wanted clock edges. Also the problem could be the drive strength of microSD when reading since writing is Ok.
S1031329.JPG
You do not have the required permissions to view the files attached to this post.
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

Thanks segher & Lele.

Finlay my problem has been solved. Now it is working fine. Actual there was noise in my SD Card break out board as well as bread board. Lele's picture shows me way. Finally I have taken a Micro SD to MMC convertor and short length bus cable and soldered it directly to MMC convertor.

Thanks & regards
jags
You do not have the required permissions to view the files attached to this post.