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