lylehaze:
Sorry to say, i couldn't understand anything from your hardware picture. I think first try sdcard code on a simple xmos board rather this comples one.
The sequencial read error what ever you are geting is shows same error what i had. I am sure there is noise in pcb/sdcard breakout board. If you follów my hardware picture your problem will be solved.
Please give attention on hardware noise.
Regards
Jags
sc_sdcard is now running on XC-3 board
Jagspaul,
In my system the L02 chip is part of the motherboard. It's right there beside the SD card.
Most of the connections from the XMOS chip are routed to a slot. You can see a board plugged in to
that slot (holding up the SD card adapter).
We don't use the USB JTAG adapters that you guys use. We have the JTAG port built
in already. That's why I had to replace the printf() statements with my own channel-based replacement.
On the bright side, by slowing down the SD_4bit code I have been able to get perfect
writes (raw). The reads still aren't right but at least it's the very same every time. No more random errors.
Unfortunately I have other projects that I need to prepare for the show next week.
I might have to demonstrate an "almost working" XMOS project.
Thanks anyway for the help! :)
LyleHaze
In my system the L02 chip is part of the motherboard. It's right there beside the SD card.
Most of the connections from the XMOS chip are routed to a slot. You can see a board plugged in to
that slot (holding up the SD card adapter).
We don't use the USB JTAG adapters that you guys use. We have the JTAG port built
in already. That's why I had to replace the printf() statements with my own channel-based replacement.
On the bright side, by slowing down the SD_4bit code I have been able to get perfect
writes (raw). The reads still aren't right but at least it's the very same every time. No more random errors.
Unfortunately I have other projects that I need to prepare for the show next week.
I might have to demonstrate an "almost working" XMOS project.
Thanks anyway for the help! :)
LyleHaze
LyleHaze,
Don't get upset.
You are facing same problem what I had.
Pls go through first page of this topic (http://www.xcore.com/forum/viewtopic.php?f=26&t=1837) and find my reply.
Now my project is running with short flat cable soldered directly to micro SD jacket. Still now my SD card breakout board is not working even with a short flat cable.
please note that the same breakout board is working fine with my arduino.
I am sure this issue related to XMOS chip only. XMOS chip port is highly sensitive of noise. XMOS team must look on this matter. Otherwise every body will face same problem like us. Nobody can make any full prove project with XMOS chip where SD interface is needed.
I can't say anything regarding SPI SD card interface. I can only say that SIP is slow than 4-bit interface. In my project I need to play YUV video from SD card. So high data throughput is required and SIP is not suitable for that.
Also I am sure there will be same reading error if you wants to run SPI SD card with 25 mhz clock, as because the issue is related with high speed reading on XMOS chip port.
My observation:
Please note that there is issue only for high speed reading from XMOS port, no issue in case of writing. In case of writing XMOS port sourcing logic 1 and sinking logic 0, that could be a point to note for no issue on writing. On reading a port XMOS port is high impedance and external device must source and sink this port with adequate current. As per my knowledge SD card can't source adequate current, so High pull-up of port is needed, and that that could be a point to note for error on reading. That is why I suggest you to use high pull-up (2.2K) on 4-bit data and cmd port.
Finally once again I request XMOS team to look on this matter for sake of there users.
regards
jags
Don't get upset.
You are facing same problem what I had.
Pls go through first page of this topic (http://www.xcore.com/forum/viewtopic.php?f=26&t=1837) and find my reply.
After that I found solutions from segher's replyI 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
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
Attachments:
Xmos_SD.JPG [995.74 KiB]
Not downloaded yet
Now my project is running with short flat cable soldered directly to micro SD jacket. Still now my SD card breakout board is not working even with a short flat cable.
please note that the same breakout board is working fine with my arduino.
I am sure this issue related to XMOS chip only. XMOS chip port is highly sensitive of noise. XMOS team must look on this matter. Otherwise every body will face same problem like us. Nobody can make any full prove project with XMOS chip where SD interface is needed.
I can't say anything regarding SPI SD card interface. I can only say that SIP is slow than 4-bit interface. In my project I need to play YUV video from SD card. So high data throughput is required and SIP is not suitable for that.
Also I am sure there will be same reading error if you wants to run SPI SD card with 25 mhz clock, as because the issue is related with high speed reading on XMOS chip port.
My observation:
Please note that there is issue only for high speed reading from XMOS port, no issue in case of writing. In case of writing XMOS port sourcing logic 1 and sinking logic 0, that could be a point to note for no issue on writing. On reading a port XMOS port is high impedance and external device must source and sink this port with adequate current. As per my knowledge SD card can't source adequate current, so High pull-up of port is needed, and that that could be a point to note for error on reading. That is why I suggest you to use high pull-up (2.2K) on 4-bit data and cmd port.
Finally once again I request XMOS team to look on this matter for sake of there users.
regards
jags
Hi LyleHaze,
I think your card your card is getting extra (unwanted) clocks since expexted data end read data are shifted. Clock is already quite below the max speed for the card; do you have the same problem also without optimization (debug mode)?
To slow down further add a dummy operation (for ex. assignment to a dummy volatile variable) between every sequence SetClk(0); SetClk(1).
But I don't think it solves the problem, you are not missing clocks, you are getting extra clocks. This means a bad rising edge of the clk line, maybe reflection due to impedece mismatch of the xmos out pin and sd input? Try to load (1K or 2K and/or a few pf) clk line next to the SD.
Lele
I think your card your card is getting extra (unwanted) clocks since expexted data end read data are shifted. Clock is already quite below the max speed for the card; do you have the same problem also without optimization (debug mode)?
To slow down further add a dummy operation (for ex. assignment to a dummy volatile variable) between every sequence SetClk(0); SetClk(1).
But I don't think it solves the problem, you are not missing clocks, you are getting extra clocks. This means a bad rising edge of the clk line, maybe reflection due to impedece mismatch of the xmos out pin and sd input? Try to load (1K or 2K and/or a few pf) clk line next to the SD.
Lele
The sc_sdcard code allows the card to use any interface voltage from
2.7V to 3.6V; you might want to change that. And check what is actually
on the bus :-)
2.7V to 3.6V; you might want to change that. And check what is actually
on the bus :-)
Thanks all for the help.
jags:
Since I am preparing this as a project for a group that will be new to XMOS programming, I have to keep the build simple. Wiring directly to an SD Card or being unable to use a short ribbon cable are both deal-killers for me.
I agree that the drive strength of the XS1-L2 chip is a lot weaker than with some other chips I have used. This is not the first time in this same project that weak outputs have cost me time (both development time and executable time). But it is what it is and I have to create a reliable product from what I have now.
lele:
Crosstalk from wires in the ribbon is likely. You suggested running the debug xe to slow it down a bit.. I already have added delays between all clocks, and I have tried #defining different values to play with the timing a bit. Any slowdown makes it more consistent, but no amount will "fix" the writes.
Good idea, but the extra clocks due to crosstalk are still a problem (with reads). Any amount of slowdown fixes all the write issues.
Segher: I did not know that the output voltages are selectable! My scope was seeing about 3.7 volts peak-to-peak at the SD Card. I thought that was a bit high but didn't pay it too much mind. I guess 0.2 volts of "overshoot" on each end might be about right.
All:
I fly out on Wednesday for the show, and I have a HUGE amount of code to finish before then.
I may have to present it as-is, but if I get a chance, I'll re-wire it for SPI mode and hope that things might work better. 4Bit mode is just not solid enough for my needs. Otherwise I'll play more after I return.
Thanks to you all..
I'm slowly getting up to speed, and all the details have slowed me way down.
These chips are pretty cool, but getting a new platform "up" and ready has been a nightmare.
I truly appreciate all the help!
Lyle
jags:
Since I am preparing this as a project for a group that will be new to XMOS programming, I have to keep the build simple. Wiring directly to an SD Card or being unable to use a short ribbon cable are both deal-killers for me.
I agree that the drive strength of the XS1-L2 chip is a lot weaker than with some other chips I have used. This is not the first time in this same project that weak outputs have cost me time (both development time and executable time). But it is what it is and I have to create a reliable product from what I have now.
lele:
Crosstalk from wires in the ribbon is likely. You suggested running the debug xe to slow it down a bit.. I already have added delays between all clocks, and I have tried #defining different values to play with the timing a bit. Any slowdown makes it more consistent, but no amount will "fix" the writes.
Good idea, but the extra clocks due to crosstalk are still a problem (with reads). Any amount of slowdown fixes all the write issues.
Segher: I did not know that the output voltages are selectable! My scope was seeing about 3.7 volts peak-to-peak at the SD Card. I thought that was a bit high but didn't pay it too much mind. I guess 0.2 volts of "overshoot" on each end might be about right.
All:
I fly out on Wednesday for the show, and I have a HUGE amount of code to finish before then.
I may have to present it as-is, but if I get a chance, I'll re-wire it for SPI mode and hope that things might work better. 4Bit mode is just not solid enough for my needs. Otherwise I'll play more after I return.
Thanks to you all..
I'm slowly getting up to speed, and all the details have slowed me way down.
These chips are pretty cool, but getting a new platform "up" and ready has been a nightmare.
I truly appreciate all the help!
Lyle