Issues with Modern microSDHC (U1 or UHS-I)

Technical Support
, , , ,
1

Recently We switched the microSDHC card installed on our devices from the usual 4/8 GB to a Trascend micro SDHC 16GB Class-10 U1.

We started experiencing issues with our application.
Most notably, regarding a feature used to test speech audiometry by making a patient listen to words, reproduced from wav files:

  • The feature is designed to browse the sd folders and files for the wanted list of wavs, on opening and whenever the list is changed by user. It take a little more time than usual with these new SD, resulting in slower loading times. It happens also in other similar situations;
  • More important, the first few (4.5) wav files reproduced till boot are clearly jumpy.

I made few tests with different SD:

  • The SD with the problem: Trascend micro SDHC 16GB Class-10 U1, UHS-I;
  • Another 16 GB gave no issues: Kingston micro SDHC 16GB Class-4 non-UHS;
  • Trascend micro SDHC 8GB Class-10 non-UHS. The 8GB from my usual debug device, gave no issues;

Now, the only relevant differences i can tell are:

  • whether the sd of class-10 supports also class U1;
  • whether the sd supports UHS bus speed or not (I suppose the host side on toradex soc is non-UHS, isn’t it?);

We are currently searching for a replacement, but I would like to know if there’s any known issue regarding/related this and any workaround or registry key to set.

Thank you in advance.

2

If it can by any chance be useful, I detected some hardware info about the SD connector mounted on our board, from @Sciur :

  • 68k pull-up resistor on MMDAT;
  • 33k pull-up resistor on MMCMD;
3

Dear @EnricoPompeiani

The Colibri T20 does not support UHS, so there’s no obvious reason why the UHS card should behave differently.
I suspect that the SD card firmware needs to do some management tasks while booting up, e.g. reading some meta data into the cache. By default the host (T20) does toggle the SD card clock only during read/write accesses. The SD card can delay the termination of such reads/writes in order to keep the clock running.

If my guess is correct, the following registry setting might help:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SDIO]
"ClockAlwaysOn"= 1

This setting is documented in our developer page article:

Regards, Andy

4

Dear @andy.tx

I checked out the registry key and i applied the change on both SDIO and SDIO2 to be safe.
Unfortunately it does not seem to have had any effect.

On the other hand, it seems the number of times the issue happened reduced after being formatted, maybe there’s a relation.

We also tried and reproduced the issue using the colibri eva board, to verify our custom board is not to be blamed.

5

Dear @EnricoPompeiani,

Thank you for your reply.

As per this documentation : https://kb.sandisk.com/app/answers/detail/a_id/1996/~/difference-between-speed-class%2C-uhs-speed-class%2C-speed-ratings-%28performance%29, speed rating considered differently than the actual that would explain the issue.

Also, we don’t support UHS in our Windows Embedded Compact BSPs. If you really need to use UHS card then you would consider switching to Linux : https://developer.toradex.com/knowledge-base/sd-mmc-card-(linux)#uhs-i-support

Let us know if you have any questions.