From owner-freebsd-usb@FreeBSD.ORG Tue Apr 21 13:44:04 2015 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2F2A567 for ; Tue, 21 Apr 2015 13:44:04 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 467E51960 for ; Tue, 21 Apr 2015 13:44:03 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t3LDhM67045651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2015 15:43:34 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t3LDhB96083297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2015 15:43:11 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t3LDhBXr035053; Tue, 21 Apr 2015 15:43:11 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t3LDhB4L035052; Tue, 21 Apr 2015 15:43:11 +0200 (CEST) (envelope-from ticso) Date: Tue, 21 Apr 2015 15:43:11 +0200 From: Bernd Walter To: Hans Petter Selasky Cc: ticso@cicely.de, freebsd-usb@freebsd.org, Bernd Walter Subject: Re: Strange problems with CH340G (uchcom) Message-ID: <20150421134311.GE29418@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20150420194855.GA29418@cicely7.cicely.de> <5535E84D.2010905@selasky.org> <20150421104931.GC29418@cicely7.cicely.de> <55362D11.5080106@selasky.org> <20150421111055.GD29418@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150421111055.GD29418@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:44:04 -0000 On Tue, Apr 21, 2015 at 01:10:55PM +0200, Bernd Walter wrote: > On Tue, Apr 21, 2015 at 12:57:21PM +0200, Hans Petter Selasky wrote: > > On 04/21/15 12:49, Bernd Walter wrote: > > >On Tue, Apr 21, 2015 at 08:03:57AM +0200, Hans Petter Selasky wrote: > > >>On 04/20/15 21:48, Bernd Walter wrote: > > >>>I tried to flash an ESP8266 with the onboard CH340. > > >>>The same board works fine when I use a CP2102 instead of the CH340. > > >>>Flashing requires a python tool, which sends a SLIP encoded request > > >>>and expects a SLIP encoded response with 115200@8n1. > > >>>The read function however times out receiving the response without > > >>>getting a single byte, even if I add a high delay between sending and > > >>>reading. > > >>>The strange thing is that I can see a valid response on a scope just > > >>>a few µs after the request completes, while the receiver don't even > > >>>see the first byte. > > >>>If however I physically loopback the CH340 it receives it's own request > > >>>just fine. > > >>>Two CH340 xconnected work fine too. > > >>>Same when I xconnect a CH340 and a CP2102. > > >>>Now I'm completely out of ideas, why the python tool has problems > > >>>to see the response data with the CH340. > > >>> > > >> > > >>Try using: > > >> > > >>usbdump -i usbusX -f Y -vvv -s 65536 > > >> > > >>And see if the reply is seen by the USB ... maybe it is a timing issue > > >>like one character at a time instead of a word. > > > > > >I can't see the reply on USB. > > >This is the first request: > > >12:32:44.019677 usbus1.6 > > >SUBM-BULK-EP=00000002,SPD=FULL,NFR=1,SLEN=48,IVAL=0 > > > frame[0] WRITE 46 bytes > > > 0000 C0 00 08 24 00 00 00 00 00 07 07 12 20 55 55 55 |...$........ > > > UUU| > > > 0010 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 > > > |UUUUUUUUUUUUUUUU| > > > 0020 55 55 55 55 55 55 55 55 55 55 55 55 55 C0 -- -- |UUUUUUUUUUUUU. > > > | > > > flags 0x9 > > > status 0xca023 > > > > > > > > >It retries this a few times. > > >But all BULK reads happen before. > > > > > >In the usbdump.ch340x I'd tried something else. > > >I'd hit 'd' during that on a CP2102 terminal programm, which was connected > > >to the RX-line. > > >And at the beginning they got read: > > >12:42:51.930004 usbus1.6 > > >DONE-BULK-EP=00000082,SPD=FULL,NFR=1,SLEN=32,IVAL=0,ERR=0 > > > frame[0] READ 31 bytes > > > 0000 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 > > > |dddddddddddddddd| > > > 0010 64 64 64 64 64 64 64 64 64 64 64 64 64 64 0D -- |dddddddddddddd. > > > | > > >But no reading after sending the request. > > > > > > > Hi, > > > > If you don't see the traffic on USB and there are no USB errors, then > > maybe one of those control messages "SUBM-CTRL-EP=00000000" are clearing > > the FIFO. Could you check if there is such a message just before the > > expected data? > > No - with the ESP8266 connected the response data is send to the CH340 > after the request got out. > There is no such request after the first request until it gives up. > During this time I only see the bulk writes with new requests. > There must be something stopping the CH340 from receiving before the > first request gets send. Sorry - I have a wrong test in between. I've botched the usbdump.ch340x test. I don't know why it received the initial 'd's, but the connections were wrong. So in fact it receives the data from the CP2102 after sending the initial request. But it still doesn't receive the response from the ESP8266. Will continue to investigate the problem. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.