Return-Path: Received: from network-box.com ([unix socket]) by nbmailhq5.network-box.com with LMTPA; Thu, 17 May 2018 10:22:58 +0800 X-Sieve: CMU Sieve 2.4 Received: from nbmailscanhq5.network-box.com (unknown [10.12.18.182]) by network-box.com (Postfix) with ESMTP id C9515403A18B for ; Thu, 17 May 2018 10:22:58 +0800 (HKT) Received: from nbmailhk1.network-box.com (localhost [127.0.0.1]) by nbmailscanhq5.network-box.com (Postfix) with ESMTP id 9AE17A15EA for ; Thu, 17 May 2018 10:22:56 +0800 (HKT) Received: from unknown (EHLO nbmailhk1.network-box.com) (10.8.12.9) by 127.0.0.1 (Network Box) with SMTP id '35da105a-5979-11e8-8728-7e2b5a688fa9'; 17 May 2018 02:22:58 -0000 X-Scanned-By-nbmailscanhq5: eMail scan performed by network-box X-Scanned-By-nbmailscanhq5: Network Box scan job 35fe948e-5979-11e8-8728-7e2b5a688fa9 X-Scanned-By-nbmailscanhq5: Network Box message id 35da105a-5979-11e8-8728-7e2b5a688fa9 Received: from nbmailscanhq5.network-box.com (unknown [10.12.18.182]) by nbmailhk1.network-box.com (Postfix) with ESMTP id 54EAC9004B for ; Thu, 17 May 2018 10:22:56 +0800 (HKT) Received: from charged.hk (localhost [127.0.0.1]) by nbmailscanhq5.network-box.com (Postfix) with ESMTP id 29FBEA148D for ; Thu, 17 May 2018 10:22:54 +0800 (HKT) Received: from unknown (EHLO charged.hk) (10.12.12.188) by 127.0.0.1 (Network Box) with SMTP id '34581966-5979-11e8-8728-7e2b5a688fa9'; 17 May 2018 02:22:56 -0000 X-Scanned-By-nbmailscanhq5: eMail scan performed by network-box X-Scanned-By-nbmailscanhq5: Network Box scan job 3483e370-5979-11e8-8728-7e2b5a688fa9 X-Scanned-By-nbmailscanhq5: Network Box message id 34581966-5979-11e8-8728-7e2b5a688fa9 Received: from [10.12.12.188] (localhost [IPv6:::1]) by charged.hk (Postfix) with ESMTP id CD96080C3209; Thu, 17 May 2018 10:22:53 +0800 (HKT) X-Original-To: ovmsdev@lists.openvehicles.com Delivered-To: ovmsdev@lists.openvehicles.com Received: from nbmailscanhq5.network-box.com (unknown [10.12.18.182]) by charged.hk (Postfix) with ESMTP id F2EEF80C3206 for ; Thu, 17 May 2018 10:22:52 +0800 (HKT) Received: from [10.8.2.100] (localhost [127.0.0.1]) by nbmailscanhq5.network-box.com (Postfix) with ESMTP id CDD23A148D for ; Thu, 17 May 2018 10:22:50 +0800 (HKT) Received: from unknown (EHLO [10.8.2.100]) (10.8.2.100) by 127.0.0.1 (Network Box) with SMTP id '3260165e-5979-11e8-bc2d-7e2b5a688fa9'; 17 May 2018 02:22:52 -0000 X-NetworkBox-Signature-Group-NBHQ: 0501; GROUP; NBHQ; nbmailscanhq5; 5f807f87e3ee1abc656824757c2e72b78c10b3a3d4e7fe436f9d8a276ab99468 X-Scanned-By-nbmailscanhq5: eMail scan performed by network-box X-Scanned-By-nbmailscanhq5: Network Box scan job 3289eab0-5979-11e8-bc2d-7e2b5a688fa9 X-Scanned-By-nbmailscanhq5: Network Box message id 3260165e-5979-11e8-bc2d-7e2b5a688fa9 From: Mark Webb-Johnson Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <56C111E5-AC24-4BE2-8800-61616261D757@webb-johnson.net> Date: Thu, 17 May 2018 10:22:49 +0800 To: OVMS Developers X-Mailer: Apple Mail (2.3445.6.18) Subject: [Ovmsdev] SD CARD speed vs cp2102 X-BeenThere: ovmsdev@lists.openvehicles.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: OVMS Developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: OVMS Developers Content-Type: multipart/mixed; boundary="===============3083041437029062667==" Errors-To: ovmsdev-bounces@lists.openvehicles.com Sender: "OvmsDev" --===============3083041437029062667== Content-Type: multipart/alternative; boundary="Apple-Mail=_EB7CB4E2-AA24-4719-B238-F6D6B040E0EA" --Apple-Mail=_EB7CB4E2-AA24-4719-B238-F6D6B040E0EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. The China guys and I have been struggling for the past couple of months = trying to work out why we can=E2=80=99t 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=E2=80=99t find = any. Dropping the speed to 16MHz works around the issue, but SD CARD = accesses are slow. Then, we worked out it wasn=E2=80=99t 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 = =E2=80=98interference=E2=80=99 disappeared. If USB was unplugged, it = came back. USB + external 12V combination also didn=E2=80=99t 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=E2=80=99t see this problem on either the v3.0 developer modules, = or v3.1 prototypes. 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=E2=80=99t. Anyway, to cut a long story short, we finally found the culprit. The = CP2102 chip itself. We=E2=80=99d 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 https://wiki.sha2017.org/w/Projects:Badge 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: 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. 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. We have replaced the cp2102 on a v3.1 first production module with = v1412+, and SD CARD resumes normal operation (even with usb = disconnected). The version number seems to be a date code. YYWW (year, week), I guess. 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=E2=80=99t see it on the scope). 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=E2=80=99t = 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=E2=80=99t seem to make any difference. The good news is that we=E2=80=99ve 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. 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=E2=80=99t 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=E2=80= =99 and it will work faster. The CP2102 chip can be changed, and I=E2=80=99= ll do that for anyone that needs it. I=E2=80=99m 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). Regards, Mark. --Apple-Mail=_EB7CB4E2-AA24-4719-B238-F6D6B040E0EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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.

The China guys and I have been = struggling for the past couple of months trying to work out why we = can=E2=80=99t 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=E2=80=99t find any. Dropping the speed to 16MHz = works around the issue, but SD CARD accesses are slow.

Then, we worked out it = wasn=E2=80=99t 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 =E2=80=98interference=E2= =80=99 disappeared. If USB was unplugged, it came back. USB + external = 12V combination also didn=E2=80=99t 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=E2=80=99t see = this problem on either the v3.0 developer modules, or v3.1 = prototypes.

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=E2=80=99t.

Anyway, to cut a long story short, we finally found the = culprit. The CP2102 chip itself.

We=E2=80=99d 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 https://wiki.sha2017.org/w/Projects:Badge 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:

  1. 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.
  2. 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.
  3. We have replaced the cp2102 on = a v3.1 first production module with v1412+, and SD CARD resumes normal = operation (even with usb disconnected).
  4. The version = number seems to be a date code. YYWW (year, week), I guess.
  5. 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=E2=80=99t see it on the scope).

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=E2=80=99t 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=E2=80=99t seem to make any difference.

The good news is that we=E2=80=99ve 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.

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=E2=80=99t 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=E2=80=99 = and it will work faster. The CP2102 chip can be changed, and I=E2=80=99ll = do that for anyone that needs it. I=E2=80=99m 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).

Regards, Mark.

= --Apple-Mail=_EB7CB4E2-AA24-4719-B238-F6D6B040E0EA-- --===============3083041437029062667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev --===============3083041437029062667==--