USB-Serial + Jessie = Corrupted data. Help from linux wizards pls?
696 views
Skip to first unread message
Andrew C
Sep 11, 2016, 3:41:00 AM9/11/16
to PiDP-8
Looking for some help to understand how/why my serial stream is being mangled.
Setup is Pi2B with Jessie, then
- plug in a USB-serial dongle.
- edit cmdline.txt to remove references to ttyUSB devices
- create a serial...@ttyUSB0.service file and insert
[Service]
ExecStart=-/sbin/agetty --8bits ttyUSB0 9600 vt100
After all necessary restarts I have a serial port that works but sends mangled data.
The dongle is recognised, lsusb returns
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
stty -F /dev/ttyUSB0 returns
speed 9600 baud; line = 0; min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8 -opost -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
First sign of problem:
During bootup, VT100 shows garbage characters
- I removed /dev/ttyUSB0 from cmdline.txt, so why does ttyUSB0 get anything during bootup
- and, why is it getting garbage, rather than showing good boot/login text?
Second sign of problem:
When I hook up a VT100 terminal at 9600 8N1 to the ttyUSB0 I get garbage.
AND the kind of mangling is different according to how the data is sent.
1) If I look at the transmitted data with the storage scope I can see that the bit times are 9600 baud - that's OK. rate is correct
2) If I use 'screen /dev/ttyUSB0' then for every character typed on the Pi I get one serial character at 9600 with 8N1 format - that part is correct
BUT the ASCII character is wrong!
I type '1' on the pi and the VT100 gets 'Q',
similarly pi 2 -> vt100 R, pi 3 -> VT100 s, pi 4 -> vt100 T. Why is the 8bit ASCII getting remapped??
3) If I use 'echo 1 > /dev/ttyUSB0' then I do not get a single 8N1 character. I get at least 16 bits, still 9600 baud but not formed as 8N1.
Why am I not getting a single 8bit ASCII char? Is this a unicode issue??
So I am getting different serial results depending on how I send '1' to /dev/ttyUSB0.
4) I have connected same USB-serial adapter to the PC and Hyperterminal at 9600 8N1 works perfectly with the VT100.
So the adapter is OK and it talks to the VT100 OK. No problem with levels or grounds.
I think that the USB-serial dongle is recognised and working, the CH340 is meant to be supported OK in RaPi
I think that something in Jessie is messing with the data. I'm not good enough with linux to know what or where... :(
Looking for help from the gurus.
Thanks in advance.
Setup is Pi2B with Jessie, then
- plug in a USB-serial dongle.
- edit cmdline.txt to remove references to ttyUSB devices
- create a serial...@ttyUSB0.service file and insert
[Service]
ExecStart=-/sbin/agetty --8bits ttyUSB0 9600 vt100
After all necessary restarts I have a serial port that works but sends mangled data.
The dongle is recognised, lsusb returns
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
stty -F /dev/ttyUSB0 returns
speed 9600 baud; line = 0; min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8 -opost -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
First sign of problem:
During bootup, VT100 shows garbage characters
- I removed /dev/ttyUSB0 from cmdline.txt, so why does ttyUSB0 get anything during bootup
- and, why is it getting garbage, rather than showing good boot/login text?
Second sign of problem:
When I hook up a VT100 terminal at 9600 8N1 to the ttyUSB0 I get garbage.
AND the kind of mangling is different according to how the data is sent.
1) If I look at the transmitted data with the storage scope I can see that the bit times are 9600 baud - that's OK. rate is correct
2) If I use 'screen /dev/ttyUSB0' then for every character typed on the Pi I get one serial character at 9600 with 8N1 format - that part is correct
BUT the ASCII character is wrong!
I type '1' on the pi and the VT100 gets 'Q',
similarly pi 2 -> vt100 R, pi 3 -> VT100 s, pi 4 -> vt100 T. Why is the 8bit ASCII getting remapped??
3) If I use 'echo 1 > /dev/ttyUSB0' then I do not get a single 8N1 character. I get at least 16 bits, still 9600 baud but not formed as 8N1.
Why am I not getting a single 8bit ASCII char? Is this a unicode issue??
So I am getting different serial results depending on how I send '1' to /dev/ttyUSB0.
4) I have connected same USB-serial adapter to the PC and Hyperterminal at 9600 8N1 works perfectly with the VT100.
So the adapter is OK and it talks to the VT100 OK. No problem with levels or grounds.
I think that the USB-serial dongle is recognised and working, the CH340 is meant to be supported OK in RaPi
I think that something in Jessie is messing with the data. I'm not good enough with linux to know what or where... :(
Looking for help from the gurus.
Thanks in advance.
Neil Higgins
Sep 11, 2016, 5:13:05 AM9/11/16
to PiDP-8
Have you checked the cable? :-/
Ed Thierbach
Sep 11, 2016, 10:59:25 AM9/11/16
to Andrew C, PiDP-8
Hi, Andrew -- to me, this still smells like a baud rate / data bits / parity issue. You've already well-verified that the baud rate is correct everywhere.
Looks like agetty can't support 8 data bits plus parity:
http://tldp.org/HOWTO/Text-Terminal-HOWTO-15.html heading 8-bit data bytes (plus parity)
so I'm wondering if it's misdetecting the terminal's parity. The USB-serial adapter throws an extra twist in there as well.
You sure your VT100 is set to 8N1?
As a test, try removing the --8bit option from agetty and set the VT100 to 7E1 and see if that helps.
Good luck and let us know how you progress!
-Ed-
--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/5d949c4c-6a6d-458e-ad76-6066102f6506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rick Murphy
Sep 11, 2016, 1:16:17 PM9/11/16
to Andrew C, PiDP-8
When you use "echo 1 >/dev/ttyUSB0" what gets sent is "1" followed by a newline. That's why you get at least two characters.
You report that the wrong characters get echoed - 1 -> Q, 2-> R, etc. That's converting 0x31 to 0x51. If that's consistently happening, then your USB to serial adapter isn't getting set up properly. But I can't think of anything that would start flipping bits like that.
You report that the wrong characters get echoed - 1 -> Q, 2-> R, etc. That's converting 0x31 to 0x51. If that's consistently happening, then your USB to serial adapter isn't getting set up properly. But I can't think of anything that would start flipping bits like that.
What happens if you cat some file and send it to the serial port? Or something like "ls -lR / >/dev/ttyUSB0" ?
I agree with Ed - this really feels like a baud/parity mismatch of some kind.
-Rick
On Sun, Sep 11, 2016 at 3:41 AM, Andrew C <atc...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/5d949c4c-6a6d-458e-ad76-6066102f6506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
Ed Thierbach
Sep 11, 2016, 2:34:38 PM9/11/16
to PiDP-8
Looks like the stock CH34x Linux driver has some problems with parity. If your adapter ("HL-340") uses that chip, maybe that's the problem. Here's a couple of threads about it, with links to the updated driver on the chip manufacturer's site:
Might still be worth changing terminal parity, and turning off 8bit on agetty, to see if you get any improvement.
-Ed-
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAPdDV0gaEzQorntatNPwKPeGj39YAE8xndZfWKXBGp%3Df0twmOQ%40mail.gmail.com.
Obsolescence
Sep 11, 2016, 5:29:17 PM9/11/16
to PiDP-8
Andrew,
On Sunday, September 11, 2016 at 9:41:00 AM UTC+2, Andrew C wrote:
Your procedure looks slightly different from the one I used, see this post:
https://groups.google.com/d/msg/pidp-8/-leCRMKqI1Q/rzw7nM2aKQAJ
Maybe that helps. But, I use the standard (ultra-cheap) PL2303 cables, so your problem may also be a driver problem with the ch340.
One thing to check for - is hardware handshaking off on the PC side? Can't really have anything to do with your symptoms - but then I got garbled output because of this once, strangely enough.
I will also upload a pipaOS version update in the coming days. It's long overdue because there are some software improvements - next to this particular configuration option needing to be added. But give me a few days for that!
Kind regards,
Oscar.
On Sunday, September 11, 2016 at 9:41:00 AM UTC+2, Andrew C wrote:
Setup is Pi2B with Jessie, then []
Your procedure looks slightly different from the one I used, see this post:
https://groups.google.com/d/msg/pidp-8/-leCRMKqI1Q/rzw7nM2aKQAJ
Maybe that helps. But, I use the standard (ultra-cheap) PL2303 cables, so your problem may also be a driver problem with the ch340.
One thing to check for - is hardware handshaking off on the PC side? Can't really have anything to do with your symptoms - but then I got garbled output because of this once, strangely enough.
I will also upload a pipaOS version update in the coming days. It's long overdue because there are some software improvements - next to this particular configuration option needing to be added. But give me a few days for that!
Kind regards,
Oscar.
Andrew C
Sep 12, 2016, 6:33:22 AM9/12/16
to PiDP-8
Thanks all for reading and thinking.
I'm getting worried that it's going to be that CH340s are no good with RaPi linux. I got a CH340 based dongle based on a quick search that suggested there were drivers built into debian and support was good. When I had problems as above, I tried another different USB-serial that I have had for quite a while, and had the same problem.
Same problem with two different USB-serials, what was the thing in common - so I thought it was something in Jessie messing with the data, a setup that I had missed deep inside linux..
Now I check that second USB-serial - it is also CH340 based!!!
And some more googling finds others with CH340 problems, specifically with RaPi.
So, I have ordered a PL2303 based dongle. I will report back to you all when this is tried. If you hear the facepalm first, you will know the answer.............
A
I'm getting worried that it's going to be that CH340s are no good with RaPi linux. I got a CH340 based dongle based on a quick search that suggested there were drivers built into debian and support was good. When I had problems as above, I tried another different USB-serial that I have had for quite a while, and had the same problem.
Same problem with two different USB-serials, what was the thing in common - so I thought it was something in Jessie messing with the data, a setup that I had missed deep inside linux..
Now I check that second USB-serial - it is also CH340 based!!!
And some more googling finds others with CH340 problems, specifically with RaPi.
So, I have ordered a PL2303 based dongle. I will report back to you all when this is tried. If you hear the facepalm first, you will know the answer.............
A
Andrew C
Oct 7, 2016, 1:48:16 AM10/7/16
to PiDP-8
Hi all, have been busy but pleased to report success.
The main problem seems to have been dongle chipset that was not properly supported in RaPi. I have changed to a PL2303 based dongle and everything is working, with just one puzzle remaining.
** It's very important to do lots of googling to find a compatible chipset, I did not do enough checking the first time :(
** Also beware that some cheap dongles have incompatible clone chips, there is no way to tell this until you discover that it wont' work.
For everyones reference, here's my setup, with notes:
1) Install PL2303 based USB-serial dongle.
lsusb
Bus 001 Device 007: ID 1267:0201 Logic3 / SpectraVideo plc A4Tech SWOP-3 Mouse
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 005: ID 0b38:0010 Gear Head 107-Key Keyboard
Bus 001 Device 008: ID 0781:5576 SanDisk Corp.
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
2) /etc/systemd/system/serial...@ttyUSB0.service
Puzzle: If the USB0 agetty is left active, then the SIMH session on the serial terminal fails.
Don't know why this problem occurs. Commenting out the startup of a console on USB0 prevents the problem.
-----------snip ----------------
[Service]
#ExecStart=-/sbin/agetty --8bits ttyUSB0 9600 vt100
#ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=ttyUSB0
TTYPath=/dev/ttyUSB0
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes
[Install]
WantedBy=getty.target
3) cmdline.txt
Also prevent a root console starting on the USB0
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
4) /opt/pidp8/bootscripts/0.script
Set SIMH to use the USB0 serial terminal
reset
set cpu 32k
set cpu noidle
set console serial=/dev/ttyUSB0;9600-8n1
att rk0 ../imagefiles/os8/os8.rk05
boot rk0
-------------- end of setup ------------------
And this is all working nicely, talking to my original VT100.
One final issue:
Using the above setup I cannot get into the SIMH command prompt from the VT100. ctrl-E is not recognised.
Nevertheless, I'm happy with progress and will test the VT100-PDP8 environment for a while before looking into the SIMH/RaPi side.
Thanks to everyone who helped!!
I will put a photo of the PiDP8 with the VT100 in the photo thread!
The main problem seems to have been dongle chipset that was not properly supported in RaPi. I have changed to a PL2303 based dongle and everything is working, with just one puzzle remaining.
** It's very important to do lots of googling to find a compatible chipset, I did not do enough checking the first time :(
** Also beware that some cheap dongles have incompatible clone chips, there is no way to tell this until you discover that it wont' work.
For everyones reference, here's my setup, with notes:
1) Install PL2303 based USB-serial dongle.
lsusb
Bus 001 Device 007: ID 1267:0201 Logic3 / SpectraVideo plc A4Tech SWOP-3 Mouse
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 005: ID 0b38:0010 Gear Head 107-Key Keyboard
Bus 001 Device 008: ID 0781:5576 SanDisk Corp.
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
2) /etc/systemd/system/serial...@ttyUSB0.service
Puzzle: If the USB0 agetty is left active, then the SIMH session on the serial terminal fails.
Don't know why this problem occurs. Commenting out the startup of a console on USB0 prevents the problem.
-----------snip ----------------
[Service]
#ExecStart=-/sbin/agetty --8bits ttyUSB0 9600 vt100
#ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=ttyUSB0
TTYPath=/dev/ttyUSB0
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes
[Install]
WantedBy=getty.target
3) cmdline.txt
Also prevent a root console starting on the USB0
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
4) /opt/pidp8/bootscripts/0.script
Set SIMH to use the USB0 serial terminal
reset
set cpu 32k
set cpu noidle
set console serial=/dev/ttyUSB0;9600-8n1
att rk0 ../imagefiles/os8/os8.rk05
boot rk0
-------------- end of setup ------------------
And this is all working nicely, talking to my original VT100.
One final issue:
Using the above setup I cannot get into the SIMH command prompt from the VT100. ctrl-E is not recognised.
Nevertheless, I'm happy with progress and will test the VT100-PDP8 environment for a while before looking into the SIMH/RaPi side.
Thanks to everyone who helped!!
I will put a photo of the PiDP8 with the VT100 in the photo thread!
Reply all
Reply to author
Forward
0 new messages