Such behavior has been first observed on the SDHC, Class 4, 4GB cards by SanDisk - some of them require hundreds of ms (not units of ms as it might be derived from the SD specification) between the moment it is powered up and the moment it is ready to communicate.
We bumped into it while trying to shorten the power-on reset active timeout for the processor from 200ms to 33ms (details in the attachment).
Later observed on other cards as well.
Please, take it into account in your designs.
I think due to this reason I am not able to create any file in my Transcend 4gb class 4 micro SDHC card. I tried a lot but SDHC couldn't work till date. I am using K60 and K40(Kwikstik) boards in that board I am using 'FAT' and 'FATFsMemSDHC' component from Processor expert. My card is working with SPI mode. So How do I make my card working with SDHC? I had a look into the attached file in the 1st post but didn't know how to use it. So kindly help me to resolve the issue.
Thanks and Regards
According to the SD specification, SD cards of all speeds and flavors, first wake up into the SPI mode, which has the lowest-speed and single-bit data – this is the data bit line, which had been observed (with a scope) in the attached PDF document, and activity on it meant the SD card passed the power-up initialization stage properly. Your statement “My card is working with SPI mode” proves your case is different than ours.
Your problem is definitely in how to make the SD card switch from the SPI to a higher-speed, multi-bit data mode of interest (e.g. SDHC of your class).
Please, refer to your SDHC card datasheet to find a specific set of commands to be sent to the SD card for that as well as bus signal timing (data, clock, etc.) – are you sure you are meeting these requirements?
BTW, some time ago we bumped into a data transmission problem in the SDHC mode, and, if I am not wrong, it appeared to be due to using a counterfeit device (we had to read the manufacturer’s name from the SD card and compare to that on the SDHC card body).
Regards, Naoum Gitnik.
The same thing happens with some USB memory sticks.
When one of our MCF5329-based devices boots it is able to have its code reloaded by plugging in a USB stick. We don't want this to delay the boot for too long, so the code turns the 5V USB power on, waits for a while and then looks to see if the device is present before trying to perform the file-system open.
The maximum time is detailed in:
Universal Serial Bus Specification Revision 2.0
18.104.22.168 Connect and Disconnect Signaling
Figure 7-29. Power-on and Connection Events Timing
Δt2 (TSIGATT) This is the maximum time from when VBUS is up to valid level
(4.01 V) to when a device has to signal attach. Δt2 represents the time required
for the device’s internal power rail to stabilize and for D+ or D- to reach VIH
(min) at the hub. Δt2 must be less than 100 ms for all hub and device implementations.
So we were waiting for double the above - 200ms. That wasn't enough.
Here's the measure time from power-on until the key pulls the pin down for various USB memory sticks:
0 = Alcor Micro 64M Key <1ms
1 - Old White + Heat Shrink: 27ms
2 - Bare White: 27ms
3 - Bare Write "test": 61ms
4 - 2GB Blue (Flakey) 66ms
5 - Corsair: 72ms
6 - DSE: 73ms
7 - Miscreant 1 150ms
8 - Miscreant 2:330ms
9 - Miscreant 3 (8GB): 366ms
Our device doesn't have an external hub. The key plugs directly into the MCF5329's USB port. Our USB stack supplier said that an external hub may mask this problem, which is why others may not be seeing this.