Re: Strange problems with CH340G (uchcom)
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=0002,SPD=FULL,NFR=1,SLEN=48,IVAL=0 > > > frame[0] WRITE 46 bytes > > > 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 > > > || > > > 0020 55 55 55 55 55 55 55 55 55 55 55 55 55 C0 -- -- |U. > > > | > > > 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=0082,SPD=FULL,NFR=1,SLEN=32,IVAL=0,ERR=0 > > > frame[0] READ 31 bytes > > > 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 > > > || > > > 0010 64 64 64 64 64 64 64 64 64 64 64 64 64 64 0D -- |dd. > > > | > > >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=" 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. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Strange problems with CH340G (uchcom)
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=0002,SPD=FULL,NFR=1,SLEN=48,IVAL=0 > > frame[0] WRITE 46 bytes > > 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 > > || > > 0020 55 55 55 55 55 55 55 55 55 55 55 55 55 C0 -- -- |U. > > | > > 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=0082,SPD=FULL,NFR=1,SLEN=32,IVAL=0,ERR=0 > > frame[0] READ 31 bytes > > 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 > > || > > 0010 64 64 64 64 64 64 64 64 64 64 64 64 64 64 0D -- |dd. > > | > >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=" 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. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Strange problems with CH340G (uchcom)
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=0002,SPD=FULL,NFR=1,SLEN=48,IVAL=0
frame[0] WRITE 46 bytes
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 ||
0020 55 55 55 55 55 55 55 55 55 55 55 55 55 C0 -- -- |U. |
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=0082,SPD=FULL,NFR=1,SLEN=32,IVAL=0,ERR=0
frame[0] READ 31 bytes
64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 ||
0010 64 64 64 64 64 64 64 64 64 64 64 64 64 64 0D -- |dd. |
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=" are clearing
the FIFO. Could you check if there is such a message just before the
expected data?
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Strange problems with CH340G (uchcom)
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=0002,SPD=FULL,NFR=1,SLEN=48,IVAL=0 frame[0] WRITE 46 bytes 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 || 0020 55 55 55 55 55 55 55 55 55 55 55 55 55 C0 -- -- |U. | 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=0082,SPD=FULL,NFR=1,SLEN=32,IVAL=0,ERR=0 frame[0] READ 31 bytes 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 || 0010 64 64 64 64 64 64 64 64 64 64 64 64 64 64 0D -- |dd. | But no reading after sending the request. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. 12:32:43.674075 usbus1.6 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes C0 5F 00 00 00 00 08 00 -- -- -- -- -- -- -- -- |._..| frame[1] READ 8 bytes flags 0x12 status 0xcb9a3 12:32:43.674958 usbus1.6 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes 30 00 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |0. | flags 0x12 status 0xeb9a1 12:32:43.675019 usbus1.6 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes C0 95 06 07 00 00 08 00 -- -- -- -- -- -- -- -- || frame[1] READ 8 bytes flags 0x12 status 0xeb9a3 12:32:43.675335 usbus1.6 SUBM-INTR-EP=0081,SPD=FULL,NFR=1,SLEN=0,IVAL=1 frame[0] READ 8 bytes flags 0xa status 0xeb023 12:32:43.675369 usbus1.6 SUBM-BULK-EP=0082,SPD=FULL,NFR=1,SLEN=0,IVAL=0 frame[0] READ 1024 bytes flags 0xa status 0xcb023 12:32:43.675510 usbus1.6 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes BF EE -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x12 status 0xcb9a1 12:32:43.781672 usbus1.6 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 40 A4 9F 00 00 00 00 00 -- -- -- -- -- -- -- -- |@...| flags 0x10 status 0xca1a3 12:32:43.782914 usbus1.6 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0x10 status 0xea1a1 12:32:43.782952 usbus1.6 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 40 A4 9F 00 00 00 00 00 -- -- -- -- -- -- -- -- |@...| flags 0x10 status 0xea1a3 12:32:43.783910 usbus1.6 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0x10 status 0xca1a1 12:32:43.783945 usbus1.6 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes C0 95 05 18 00 00 08 00 -- -- -- -- -- -- -- -- || frame[1] READ 8 bytes flags 0x12 status 0xcb9a3 12:32:43.784892 usbus1.6 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes 3F C3 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |?. | flags 0x12 status 0xeb9a1 12:32:43.784919 usbus1.6 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 40 9A 05 18 3F C3 00 00 -- -- -- -- -- -- -- -- |@...?...| flags 0x10 status 0xea1a3 12:32:43.785882 usbus1.6 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0x10 status 0xca1a1 12:32:43.785908 usbus1.6 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
Re: Strange problems with CH340G (uchcom)
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. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Strange problems with CH340G (uchcom)
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. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
