Prev: NAD Cassette Deck ...
Next: There's a result then ...
From: tlvp on 21 Dec 2009 21:15
On Mon, 21 Dec 2009 10:53:53 -0500, Frantisek.Rysanek(a)post.cz <Frantisek.Rysanek(a)post.cz> wrote:

> Dear Everyone,
>
> apologies for cross-posting, I'm wondering if some of the veterans of
> 10-15 years ago are still reading these USENET groups...
> I'm sending this problem description just in case the weird symptoms
> ring a bell with someone - if someone happens to have a past
> experience that might resemble my symptoms.
> I will deliberately not name the vendors involved - we are not sure
> exactly where the problem is.
>
> Strange as it may seem to the majority PC user nowadays, in our
> industrial process control practice we're still using RS232 and its
> flavours RS485, RS422. The problem at hand occurs in a [brand
> censored] panel PC (that's an LCD with an embedded motherboard in a
> flat wallmount box), that's based on an Intel Atom, coupled with the
> i945GSE chipset (including some ICH7 flavour for a south bridge). The
> PC doesn't seem to contain a full-fledged SuperIO chip (no floppy, no
> PS2, no LPT/joystick, just USB) and its three serial ports are
> implemented using a [brand censored] quad UART chip, that connects to
> the ICH via an LPC bus. The quad UART chip has some configurable
> "industrial" features, such as TEMT bit exported to an outer modem
> control signal (for HW-based RS485 RX/TX steering) and something
> called "9bit mode".
>
> Under some circumstances, for an unknown reason, the quad UART tends
> to produce garbled TX data. You open the HyperTerminal, select a COM
> port, configure it for 9600 8N1, without flow control. If you send a
> string of e.g. the ASCII character "a", the 8th bit in every *second*
> character is inverted. Bit 8 in the RS232 character = the last before
> the stop bit = the MSB. One character okay, another character garbled.
> In HyperTerminal, it looks like a string of good characters mixed with
> non-ascii garbage. An interesting feature seems to be, that it does
> this with *any* character you can type on the keyboard - any letters
> or numbers. If you type different characters in a sequence, the
> garbage doesn't occur. If you keep sending a single character, it
> starts producing garbage. It doesn't matter if you type the characters
> isolated (so that the FIFO is empty all the time) or if you send a
> string via the clipboard, so that the characters get "clocked out"
> back to back (and buffered in the UART's 16byte FIFO in the process).
>
> The waveform is fairly clear, either the bit is there nice and clear,
> or it's completely absent - there are no glitches or weird
> malformations. There's no doubt that the garbage is coming out of the
> UART's "trasmitter shift register". Observed with an oscilloscope
> straight at the UART's TTL level output, before RS232/485 drivers,
> with nothing attached to the RS232/485 ports (no load on the drivers).
> Observed on port 1 and 3 of the quad-UART chip. Unfortunately I don't
> have an LPC bus analyzer to check if perhaps the data is coming
> garbled from the ICH. Makes me wonder how come that everything else
> works just fine, all the addresses and data on the LPC bus - just that
> bit #8 gets garbled. Otherwise it might be attributed to interference
> from WiFi or BlueTooth (both in the box).
>
> Another problem is that the symptom tends to go away if you start
> looking too hard or poking around. On some machines it seems to appear
> after a cold boot, after a period of inactivity. On other machines, it
> starts after some flawless production runtime. It definitely seems to
> go away if you switch the baud rate away from 9600 and back to 9600.
> And it doesn't come back after the next reboot...
>
> An interesting aspect is, that it only occurs on Windows XP Embedded.
> If the problem occurs, and I reboot to Linux (via Etherboot), I cannot
> reproduce it with Minicom or other serial TTY software that I have. If
> I reboot back to XPe on a CF card, you bet it's there. This is a known-
> clean system with only the basic drivers: a stock Windows serial.sys,
> and the next closest driver to RS232 is a Penmount touchscreen driver
> (never a problem with that one, sitting fixed on its own port). I've
> tried with a pristine system, before the visualization app gets
> installed (the production app that works with the COM ports), and I
> cannot imagine a filter driver sitting on the COM ports - in the first
> place I haven't installed any, in the second place I don't know what
> purpose it might have.
>
> I'd really love to know where the gremlins are hiding this time :-)
>
> If you've read this far, thanks a lot for your attention.
>
> Frank Rysanek

You speak of opening "the HyperTerminal" -- is that the terminal app
that's part of Win XP? If so, be aware that it itself is flawed, at
least in my experience: when I was using it to capture data from an
RS-232 serial line communications link, it would habitually and
consistently buffer its capture contents so badly that scrolling
back to earlier parts of the capture, that *had* looked OK at first,
showed very badly garbled contents.

My solution was to replace it with some other Terminal app, coming
from the public domain, that turned out *not* to manifest such issues.

No guarantee that that's where *your* issues arise, of course, but as
the issue arises under XP and not under Linux, it's a thought ... .

HTH; and cheers, -- tlvp



--
Avant de repondre, jeter la poubelle, SVP
 | 
Pages: 1
Prev: NAD Cassette Deck ...
Next: There's a result then ...