We developed our own PCB with an OMAP-L138 (and some boards with an AM1806). Linux is used as OS and U-Boot as bootloader. We have problems with the SD-Card. Both U-Boot and Linux have occasional problems (but far too often) while accessing the SD-Card, to a degree that U-Boot cannot read anything at all and Linux returns wrong data to the upper layers (which leads to other errors, like wrong md5sums which were manually created, although the SD-Card is still ok, as tested on another system). Analyzing it more thoroughly there are CRC errors (the status bit of the SD/MMC controller leads to this). We use the recommended Pull Ups and wire lengths are within a margin < 26 mm compared to CLK (equals ca. 0.2 ns). After many tests we got the following results:- We have tried many different SD-Cards, including Industrial Grade SD-Cards, which does not change anything- Failures occure while reading and writing (droping the OS filesystem cache to force it)- Failures occure on the OMAP-L138 and AM1806- Lower the main PLL clock does not help- Lower the SD-Card clock (from 38 MHz) down to 8 MHz does not help- The problem cannot be triggered on both OMAP-L138 Zoom Eval Boards we own (which not even have Pull Ups, they were added on a later design we assume)- Our OMAP-L138s/AM1806s have Revision 2.0, the CPUs on the Zoom Eval Boards have Revision 1.1- Cooling down the CPU (refigerant spray) almost immediately triggers the error- Heating the CPU has neither a positive, nor a negative effect- Inserting a delay (with a gate) in the CLK signal (of ca. 5 ns) avoids ALL hardware related problems so far (neither cooling, nor manually inducing EMI, triggered the error anymore)From our perspective (which may be wrong) it looks like the CPU has a silicon bug at least since Revision 2.0- Sometimes it happens that the whole OS locks up (which can be analyzed with the SysRq debug option from Linux, where one can see, that the MMC/SD driver waits forever), this is quite likely the problem of an unstable MMC/SD driver. I modified the driver from U-Boot slightly to test if it's possible to recover automatically after the CPU was cooled down, and indeed it was possible, so I assume the driver from Linux should be able to do that as well. Not sure if TI cares about that at all (IMHO software should assume that hardware may occasionaly fail, not sending an interrupting or whatever).
No much to suggest. I think the OMAP-L138 has internal pullups that are sufficient for MMC/SD operation. I have had problems where the MMC/SD controller is very sensitive to processor supply voltage that is too high.
Thanks for your hint.
The first Zoom Eval Baords do not have a Pull Up and work well, therefore I agree. The newer design guides from TI suggest that one needs Pull Ups, that's why I mentioned it explicitly.
Our custom OMAP-L137 board does not use pullups for space reasons. I'll have to get our HW guys to check the newer design guides.
For me, the card works fine except when I was using an analog power supply that was easily bumped. The card started exhibiting problems when the power supply strayed upward. I vaguely remember a touch above 3.3V was bad. Something to do with the card logic level theshold.