<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Good grief. A year into this, and still writing about SD CARD issues with ESP32. If I could get into a room with the engineer who decided to share boot strapping pins with SDCARD pins, and to hard wire the SDIO controller to specific pins, I would literally try to slap some sense into him.</div><div class=""><br class=""></div><div class="">The China guys and I have been struggling for the past couple of months trying to work out why we can’t get as much speed out of the SD CARD as we wanted. If we raise the speed to the normal 20MHz, we randomly get errors (timeouts, checksums, etc). It looked like interference on the bus lines, but scoping those we can’t find any. Dropping the speed to 16MHz works around the issue, but SD CARD accesses are slow.</div><div class=""><br class=""></div><div class="">Then, we worked out it wasn’t random. It was based on whether we were powering from USB or external 12V. On the bench it works fine. In the car the problem appears. Simply put, if the USB was plugged in the ‘interference’ disappeared. If USB was unplugged, it came back. USB + external 12V combination also didn’t suffer from the issue, so the problem is not coming from the 12v side. The issue often appeared on only the second test of SD CARD, not the first. We didn’t see this problem on either the v3.0 developer modules, or v3.1 prototypes.</div><div class=""><br class=""></div><div class="">We looked at the capacitors and pull-up resistors on that side of the circuit, without success. Whatever we did made little difference (or randomly changed things for the better/worse). We thought maybe ground-line interference, but nope. We spent some time looking at C20, C22, C23 to see if the manufacturers had messed up the component values - they hadn’t.</div><div class=""><br class=""></div><div class="">Anyway, to cut a long story short, we finally found the culprit. The CP2102 chip itself.</div><div class=""><br class=""></div><div class="">We’d already had to change the power supply design early on in the project to cope with a bug in CP2102 not correctly handling USB host disconnect and not properly going into suspend mode (to reduce power consumption of cp2101 circuit when usb was disconnected) - our current design completely powers down the cp2102 chip when the USB cable is disconnected. Michael Stegen had previously warned me about clones of this chip (see <a href="https://wiki.sha2017.org/w/Projects:Badge" class="">https://wiki.sha2017.org/w/Projects:Badge</a> and what they went through), and we had added the extra resistor already to cope with that eventuality. But, from what we can tell this is not a clone part issue. Here is what we found:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">OVMS v3.0 and early v3.1 prototypes use CP2102 v1412+. For that chip, when the USB cable is disconnected, CSL-TXD is 3.3v.</li><li class="">OVMS v3.1 first production batch use a newer CP2102 v1708+. For that chip, when the USB cable is disconnected, CSL-TXD is pulled down to 0.78v.</li><li class="">We have replaced the cp2102 on a v3.1 first production module with v1412+, and SD CARD resumes normal operation (even with usb disconnected).</li><li class="">The version number seems to be a date code. YYWW (year, week), I guess.</li><li class="">We have absolutely no idea why this would be affecting the SD CARD performance or interference. Somehow, that CSL-TXD line is going through the ESP32 chip and affecting the SDIO controller (perhaps related to the bootstrapping pins dual use). The interference we see is inside the ESP32, not on the lines going from ESP32 to the SDCARD (which is why we couldn’t see it on the scope).</li></ol></div><div class=""><br class=""></div><div class="">I tried shutting down the pins on the ESP32 for CSL-TXD and CSL-RXD, to see if I could work around the problem in firmware, but couldn’t get it to work. There is no way of knowing whether the USB is connected, and even if we did know, setting CSL-TXD and CSL-RXD pins to output mode, or float, doesn’t seem to make any difference.</div><div class=""><br class=""></div><div class="">The good news is that we’ve at least identified the problem. We are (a) checking the revision of cp2102 chip in the upcoming production batch, and (b) changing QC procedures to set SD CARD bus speed to default (20MHz) and randomly test modules twice on 12V power. Latest production batch is now using v1742+, and that has been tested as working. Going forward, we can resolve this.</div><div class=""><br class=""></div><div class="">As for the first production batch units, they are what they are. For normal SD CARD operation (copying files, flashing firmware, etc), it makes little difference. I guess most users don’t even have an SD CARD inserted. The speed limitation really only becomes an issue if you are trying to log lots of data to SD CARD (such as CAN bus dumps). If the USB is connected, you can 'config set sdcard maxfreq.khz 20000’ and it will work faster. The CP2102 chip can be changed, and I’ll do that for anyone that needs it. I’m asking China to send me some from the latest production batch that we know works. Replacement is relatively straightforward, but involves micro-soldering (the cp2102 is a surface mount chip, very small footprint, with lots of other components near it on the board).</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div></div></body></html>