unable to mount SD card
Patrick1ab
Posts: 136
Hi all!
I know that I've seen a similar thread once, but I couldn't find it anymore (even with the search function).
After changing the I/O Pins of my Propeller/SD card interface from
DO 16
CLK 17
DI 18
CS 19
to
DO 12
CLK 11
DI 10
CS 9
I am not able to mount an sd card anymore.
I checked all the solder joints: They are all connected and there is no short circuit.
I'm using pull up resistors (as I always do) and even shortened the cables a bit.
The fsrw version I use is 2.6.
What I recognize is, that it takes quite a while (a second or 2) before the mount function returns an error.
The error code which is returned is -100, so according to the table it's ERR_ASM_NO_READ_TOKEN.
Please try to help me, if you've got an idea what the problem could be.
Thanks!
Patrick
I know that I've seen a similar thread once, but I couldn't find it anymore (even with the search function).
After changing the I/O Pins of my Propeller/SD card interface from
DO 16
CLK 17
DI 18
CS 19
to
DO 12
CLK 11
DI 10
CS 9
I am not able to mount an sd card anymore.
I checked all the solder joints: They are all connected and there is no short circuit.
I'm using pull up resistors (as I always do) and even shortened the cables a bit.
The fsrw version I use is 2.6.
What I recognize is, that it takes quite a while (a second or 2) before the mount function returns an error.
The error code which is returned is -100, so according to the table it's ERR_ASM_NO_READ_TOKEN.
Please try to help me, if you've got an idea what the problem could be.
Thanks!
Patrick
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
thanks for your quick reply.
I put the code in the attachments, but I'm not sure if you can find the problem in there.
I only changed one line in the "checkforSD" procedure of the "Main.spin" file:
from
to
Maybe I'll try to hook up my oscilloscope to see whether the signals are distorted somehow.
What has happened when you switched the pins is the I/O "distance" has got longer for high numbered cogs. Since the fsrw object is one of the later cogs to start up it is probably in a high numbered cog (I haven't counted). This means it is closer (in terms of OR gates) to the pins 16-31 than 0-15. So using the fsrw code which runs at 20MHz the propagation delay/current draw is causing you problems I suspect. Other people have had this problem. One solution is to start the cog up as the first object (this puts it very close to the output pins) another is to use a slower block access layer. I have written one (it's in DracBlade_spi.spin) but it's not very portable, it also doesn't support HCSD so if you can get the mb_raw_spi version to work, that would be best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I'm going to try that. It would be great, if this is the solution.
Meanwhile I did some measurements with my oscilloscope and saw that my CLK-Signal wasn't as nice, as it should have been.
Some kind of capacitance (see the purple signal on the first picture)
I renewed the solder joints and as you can see in the second picture now it looks much better.
Another thing which bothered me is the echo I had on the DO-Line (green signal); maybe the connections are still too long.
I was able to clean this a bit by adding a pull down resistor.
As the problem still persists, I am going to start the fsrw cog first.
If two of them are outputs from the prop, there are clearly setup/hold violations going on there.
Would you be willing to get the same picture, but using the original pins?
We may be on to something here.
That is, you are using the fastest, hottest, driver there. Can you switch to the safe driver
by changing it as follows:
and let me know if that solves it, and/or if that changes your scope pictures in any way?
thanks for your reply.
This is really weird:
I switched to the safe driver and it works perfectly. Switching back to the high speed driver, I've got the same problem as before.
Now it's even getting more confusing :-D : Have a look at the signals (Picture 1 is the safe driver, Picture 2 the high speed version)
If there is a setup/hold violation, then this exists in both drivers, doesn't it?
CS: yellow signal
DI: blue signal
CLK: purple signal
DO: green signal
No, this is starting to *perhaps* make more sense. Are these both using the 12-9 pin set?
Looking at your images, things are probably just fine, although it's hard to know precisely
what portion of the protocol is pictured in your images. The thing is, your time frame is, if
I'm interpreting it correctly, 10us/div, so setup/hold would be *much* too small to show up
at that temporal resolution. In both pictures, that portion of the protocol is probably working
fine; the failure is probably occurring much later.
For your purposes, would the safe driver suffice? It's not *that* much slower.
-tom
Yes, both are using this pin set. Sorry, I was too lazy to change it again...
The portion of the protocol you see, are the very first bits the driver is sending when the mount_explicit function is called.
At the moment (for testing purposes) I can live with the slower version, but I'm eager to find a solution so that I can get the high speed driver working aswell.
You were right. If I start fsrw first and afterwards the other objects, it works just fine.
Now I have to find a way to "reserve" a cog or start the SPI driver of fsrw without mounting an SD card, since the other objects have to start even if there is no SD card inserted at the beginning.
things just to use the fancy driver. The "simple" driver is actually a crowning achievement of engineering and does
very, very well.
Me too I'm having problems mounting my SD card. I was trying to use 2GB and 16Mb ones as well.
I'm using CS, DI, SCLK, DO on pins 16-19 with 10K pullups to 3.3V (unused data pins are connected to 3.3v through 10K pullups), booth vss are connected to GND
Take a look at the output of test.spin form the object exchange.
It will fail with both hi or slow speed drivers.
The first test are ok but it looks like it fails during "mount_explicit"
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Do a single non-sequential write...Done/s
How fast can we read, sequentially?
Now the filesystem tests ms at 1359 kB/s
Trying to mount
Erroneously returned from start!
-20
does anyone have an idea?
Thanks in advance!
If you look at the pictures of the Prop I chip, you'll see that the I/O pin pads are located along the periphery of the chip while the cogs themselves are located across one dimension of the chip. There's also a block diagram of the Prop I on the Propeller Downloads web page that shows how the I/O pins are chained together functionally. The net result is that there's a short delay (I think on the order of maybe 2ns-4ns) for the I/O signal on the "far end" of the chip as compared to the one closest to the I/O pad. This is not a "silicon errata". It's simply a result of the deliberate design of the I/O structure of the Prop including the gate delays involved in the chain of OR gates. It could be "fixed" by completely redesigning the I/O structure to balance the timings from one cog to another. There would still be differences, but they would be smaller and it would be a major redesign of the chip. Considering that the instruction execution time is on the order of 40ns to 50ns and the system clock time is maybe 10ns to 12.5ns, you're talking about small fractions of the basic clock time of the device.
Robert
Ok, this might sound silly, but if it's a known issue that the cog number affects the timing, have the code retrieve it's cog number and make it automatically adjust the timing. It can't be that much of an effort to make it work like that.
Just my humble opinion...
KK