 | |
LPC quad UART garbling 8th bit in TX data - difficult to reproduce -any ideas?
Miscellaneous PC Hardware Miscellaneous PC hardware topics (comp.sys.ibm.pc.hardware.misc)
 |
| | Thread Tools | Search this Thread | Display Modes |
#11
 
| ||||||||||
| ||||||||||
|
Re: LPC quad UART garbling 8th bit in TX data - difficult toreproduce - any ideas? -
01-26-2010
, 12:04 PM
|
Hyperterminal is known to garble *RECEIVED* characters under certain circumstances if the first three characters recived are identical. *This fault, once triggered, persists until the application is exited. I wonder if it is possible for the same bug to also affect transmit? * And, maybe special thanks to Ian Malcolm - his bug description is the |
If I exit Hyperterminal and start it again, the problem is typically
still there.
It survives even a power-cycle :-/
Quote:
|
Please try a 3rd party terminal and see if the problem goes away... [suggested by several polite people] |
Yes, this is definitely something I should do.
I've seen one more occurrence of the problem,
but didn't have a chance to test this - I probably inadvertently
reset the UART and the problem went away before I tried a different
terminal.
I have Putty and CRT on my USB flash drive just in case.
Quote:
|
Also censoring the uart chip brand and number will not lead you to any answers... * I know :-( |
After some early rookie experience in that way, I prefer to be
cautious.
After all, I'm not sure exactly where the problem is, and this
decription
could cast a shade on innocent hardware, which otherwise looks pretty
good...
Quote:
|
What happens if you send a string of genuine 8-bit characters, eg extended ASCII? This will force Windows to "think about" the 8th bit, whereas anything you type at the keyboard will usually be 7 bits. right, tried that - made a file containing a megabyte of some |
and the problem was still there. Back to 7bit characters, and still it
was there.
Quote:
|
It would be rational to suspect other serial processes (IRDA as well as COM ports). Ha, I haven't checked for IRDA. Makes me wonder if the IRDA modes |
could use this kind of hardware feature. The UART's can work in some
IRDA modes,
but the hardware doesn't have a physical IR port, and as far as I
know, the IR modes
are not even offered in the BIOS setup for the COM ports. I can only
hope they're
properly disabled. Anyway I believe that Windows don't detect an IR
port.
Have to check to make sure - thanks for that note.
Still it makes me wonder. If the UART device was seized by some IRDA
service,
the production app running on the PC would fail to open it as a COM
port.
Sounds weird...
I was wondering if some Windows-internal ISA PnP stuff or generic
SuperIO
support could be messing with the SuperIO chip's config registers at
random.
Those are a special bank of registers with multiplexed access,
separate from
the classic ISA UART footprints in IO space.
Perhaps more likely the BIOS could have some bugs in that direction
(ACPI/SMI
handling and whatnot). Wish I had an LPC bus probe :-)
Quote:
|
Is is possible the send or receive is set to 7 bits + parity and the other set to 8 bits? that would mess up the 8th bit on 50% of the possible characters. No. It works just fine most of the time. |
Seen such misconfigurations before. This is different.
Most important it garbles every *other* character in a string.
Thanks for the suggestion though :-)
Quote:
|
You have a "stock Windows serial system"? No Windows updates, no driver updates? I'd suspect a problem right there. Go ahead and try *ALL* the updates. It's a cut of XP Embedded based on XP SP3. I've checked the versions |
serial.sys and serenum.sys - they're the same as on my laptop,
with Windows Update active.
Quote:
|
Given the concatenation of somewhat oddball chipsets in this system, and the claim that it works properly under Linux, I'd suspect driver issues, particularly flow control handling. Are your serial devices actually wired correctly for hardware flow control? no they're not :-) You _don't_ use flow control on RS485. |
You don't get anything transmitted (the write() syscall blocks),
or you get whole characters lost at the other end (FIFO overruns).
Quote:
|
Many well-meaning but clueless engineers get the RS-232 signals for different devices miswired, and never notice because they've mishandled flow control and don't use it much. [chuckle] don't tell me about well-meaning engineers :-) |
Such as auto-loopback relays on Ethernet ports, in hardware
intended for firewall applications... or they use Linux in an embedded
box,
are soo very secretive about it (except that you can see the version
strings
in the firmware images available for download), and they can't seem to
get *default routing* right, and they have bugs in serial port
handling
on a great 16C950 UART (those are two areas where Linux has been
okay for decades now, in my experience).
Quote:
|
You should also definitely state which Windows and Linux operating systems you're using. the production OS is XPe, derived from XP SP3 (Czech locale I |
The Linux that I'm using for tests, is an in-house mini-distro
assembled by hand
(scripted file copy) based on Fedora 5, with a 2.6.28.6 kernel
(custom config). Booting via PXE and working just fine with my
tools :-)
----
The lasting problem is that I keep getting pieces of the suspected
hardware
RMA'ed due to irrelevant problems (software misconfigurations, RS485
wiring sins),
and only now and then an odd piece happens to show the "flipping bit"
symptom.
Based on the set of observations so far, I can't even tell if the
"flipping bit syndrome in Hyperterminal" was to blame for a particular
production
malfunction, or if it was just the other problem I found on site :-)
This is something I have to sort through myselfs.
The publishable results of this ongoing customer case so far have
been:
1) a snippet of Mingw C++ code that attempts to mimick the
"hyperterminal reset"
(I straced hyperterminal to see what it does at the level of
syscalls,
and then I tried to reproduce that at the level of DLL function
calls :-)
http://www.fccps.cz/download/adv/frr/COMRESET.zip
I've hooked it up into the startup sequence of the last culprit
just in case.
2) a brain-dump of collected thoughts on RS485 grounding and
termination.
My head tends to relax if I write things down an publish for the
benefit of others
(provided that they can read through the mess :-)
http://www.fccps.cz/download/adv/frr/RS485/RS485.html
The important point is that I'm still having fun :-)
Thanks for your help everybody, take care
Frank Rysanek
#12
| |||
| |||
|
|
Dear gentlemen, many thanks to all of you who responded :-) I'm delighted to see that the USENET is still alive, and that it's sometimes the same people responding to me, who used to respond ~10 years ago... On 22 pro 2009, 15:23, Ian Malcolm wrote: Hyperterminal is known to garble *RECEIVED* characters under certain circumstances if the first three characters recived are identical. *This fault, once triggered, persists until the application is exited. I wonder if it is possible for the same bug to also affect transmit? * And, maybe special thanks to Ian Malcolm - his bug description is the closest to mine :-) If I exit Hyperterminal and start it again, the problem is typically still there. It survives even a power-cycle :-/ Please try a 3rd party terminal and see if the problem goes away... [suggested by several polite people] Yes, this is definitely something I should do. I've seen one more occurrence of the problem, but didn't have a chance to test this - I probably inadvertently reset the UART and the problem went away before I tried a different terminal. I have Putty and CRT on my USB flash drive just in case. Also censoring the uart chip brand and number will not lead you to any answers... * I know :-( It's a matter of not biting the hand that feeds you. After some early rookie experience in that way, I prefer to be cautious. After all, I'm not sure exactly where the problem is, and this decription could cast a shade on innocent hardware, which otherwise looks pretty good... What happens if you send a string of genuine 8-bit characters, eg extended ASCII? This will force Windows to "think about" the 8th bit, whereas anything you type at the keyboard will usually be 7 bits. right, tried that - made a file containing a megabyte of some character with the MSb=log.1, and the problem was still there. Back to 7bit characters, and still it was there. It would be rational to suspect other serial processes (IRDA as well as COM ports). Ha, I haven't checked for IRDA. Makes me wonder if the IRDA modes possibly could use this kind of hardware feature. The UART's can work in some IRDA modes, but the hardware doesn't have a physical IR port, and as far as I know, the IR modes are not even offered in the BIOS setup for the COM ports. I can only hope they're properly disabled. Anyway I believe that Windows don't detect an IR port. Have to check to make sure - thanks for that note. Still it makes me wonder. If the UART device was seized by some IRDA service, the production app running on the PC would fail to open it as a COM port. Sounds weird... I was wondering if some Windows-internal ISA PnP stuff or generic SuperIO support could be messing with the SuperIO chip's config registers at random. Those are a special bank of registers with multiplexed access, separate from the classic ISA UART footprints in IO space. Perhaps more likely the BIOS could have some bugs in that direction (ACPI/SMI handling and whatnot). Wish I had an LPC bus probe :-) Is is possible the send or receive is set to 7 bits + parity and the other set to 8 bits? that would mess up the 8th bit on 50% of the possible characters. No. It works just fine most of the time. The peers are set allright against each other. Seen such misconfigurations before. This is different. Most important it garbles every *other* character in a string. Thanks for the suggestion though :-) You have a "stock Windows serial system"? No Windows updates, no driver updates? I'd suspect a problem right there. Go ahead and try *ALL* the updates. It's a cut of XP Embedded based on XP SP3. I've checked the versions of serial.sys and serenum.sys - they're the same as on my laptop, with Windows Update active. Given the concatenation of somewhat oddball chipsets in this system, and the claim that it works properly under Linux, I'd suspect driver issues, particularly flow control handling. Are your serial devices actually wired correctly for hardware flow control? no they're not :-) You _don't_ use flow control on RS485. Anyway a flow control misconfiguration behaves very different. You don't get anything transmitted (the write() syscall blocks), or you get whole characters lost at the other end (FIFO overruns). Many well-meaning but clueless engineers get the RS-232 signals for different devices miswired, and never notice because they've mishandled flow control and don't use it much. [chuckle] don't tell me about well-meaning engineers :-) What the Taiwanese HW designers can come up with... Such as auto-loopback relays on Ethernet ports, in hardware intended for firewall applications... or they use Linux in an embedded box, are soo very secretive about it (except that you can see the version strings in the firmware images available for download), and they can't seem to get *default routing* right, and they have bugs in serial port handling on a great 16C950 UART (those are two areas where Linux has been okay for decades now, in my experience). You should also definitely state which Windows and Linux operating systems you're using. the production OS is XPe, derived from XP SP3 (Czech locale I believe). The Linux that I'm using for tests, is an in-house mini-distro assembled by hand (scripted file copy) based on Fedora 5, with a 2.6.28.6 kernel (custom config). Booting via PXE and working just fine with my tools :-) ---- The lasting problem is that I keep getting pieces of the suspected hardware RMA'ed due to irrelevant problems (software misconfigurations, RS485 wiring sins), and only now and then an odd piece happens to show the "flipping bit" symptom. Based on the set of *observations so far, I can't even tell if the "flipping bit syndrome in Hyperterminal" was to blame for a particular production malfunction, or if it was just the other problem I found on site :-) This is something I have to sort through myselfs. The publishable results of this ongoing customer case so far have been: 1) a snippet of Mingw C++ code that attempts to mimick the "hyperterminal reset" * * (I straced hyperterminal to see what it does at the level of syscalls, * * *and then I tried to reproduce that at the level of DLL function calls :-) * *http://www.fccps.cz/download/adv/frr/COMRESET.zip * * I've hooked it up into the startup sequence of the last culprit just in case. 2) a brain-dump of collected thoughts on RS485 grounding and termination. * * My head tends to relax if I write things down an publish for the benefit of others * * (provided that they can read through the mess :-) * *http://www.fccps.cz/download/adv/frr/RS485/RS485.html The important point is that I'm still having fun :-) Thanks for your help everybody, take care Frank Rysanek |
that had a windows pc interfacing with a PLC. We were using win98 if
I remember correctly. I think the uart and windows had an issue
because of the way windows would multitask. Windows would lock the
application just long enough to put it out of sync with the uart, and
cause garbled data, or a frozen application. I think there were also
problems with keeping other applications from accessing the port, even
though it should have been locked. At first, I would have to restart
windows when the app crashed. But then I rewrote the app, so I could
just re-initiate communications when it failed. I have a binder
around here somewhere, with our notes and data sheets and the like. I
don't know if they'll apply to you, but I'll post a better explanation
if I can find them.
I must be getting old when I remember fixing something, but don't
remember how the hell I did it. Then tell a long drawn out story with
no useful information whatsoever.
-Lazers
#13
| |||
| |||
|
|
Dear gentlemen, many thanks to all of you who responded :-) I'm delighted to see that the USENET is still alive, and that it's sometimes the same people responding to me, who used to respond ~10 years ago... On 22 pro 2009, 15:23, Ian Malcolm wrote: Hyperterminal is known to garble *RECEIVED* characters under certain circumstances if the first three characters recived are identical. *This fault, once triggered, persists until the application is exited. I wonder if it is possible for the same bug to also affect transmit? * And, maybe special thanks to Ian Malcolm - his bug description is the closest to mine :-) If I exit Hyperterminal and start it again, the problem is typically still there. It survives even a power-cycle :-/ Please try a 3rd party terminal and see if the problem goes away... [suggested by several polite people] Yes, this is definitely something I should do. I've seen one more occurrence of the problem, but didn't have a chance to test this - I probably inadvertently reset the UART and the problem went away before I tried a different terminal. I have Putty and CRT on my USB flash drive just in case. Also censoring the uart chip brand and number will not lead you to any answers... * I know :-( It's a matter of not biting the hand that feeds you. After some early rookie experience in that way, I prefer to be cautious. After all, I'm not sure exactly where the problem is, and this decription could cast a shade on innocent hardware, which otherwise looks pretty good... What happens if you send a string of genuine 8-bit characters, eg extended ASCII? This will force Windows to "think about" the 8th bit, whereas anything you type at the keyboard will usually be 7 bits. right, tried that - made a file containing a megabyte of some character with the MSb=log.1, and the problem was still there. Back to 7bit characters, and still it was there. It would be rational to suspect other serial processes (IRDA as well as COM ports). Ha, I haven't checked for IRDA. Makes me wonder if the IRDA modes possibly could use this kind of hardware feature. The UART's can work in some IRDA modes, but the hardware doesn't have a physical IR port, and as far as I know, the IR modes are not even offered in the BIOS setup for the COM ports. I can only hope they're properly disabled. Anyway I believe that Windows don't detect an IR port. Have to check to make sure - thanks for that note. Still it makes me wonder. If the UART device was seized by some IRDA service, the production app running on the PC would fail to open it as a COM port. Sounds weird... I was wondering if some Windows-internal ISA PnP stuff or generic SuperIO support could be messing with the SuperIO chip's config registers at random. Those are a special bank of registers with multiplexed access, separate from the classic ISA UART footprints in IO space. Perhaps more likely the BIOS could have some bugs in that direction (ACPI/SMI handling and whatnot). Wish I had an LPC bus probe :-) Is is possible the send or receive is set to 7 bits + parity and the other set to 8 bits? that would mess up the 8th bit on 50% of the possible characters. No. It works just fine most of the time. The peers are set allright against each other. Seen such misconfigurations before. This is different. Most important it garbles every *other* character in a string. Thanks for the suggestion though :-) You have a "stock Windows serial system"? No Windows updates, no driver updates? I'd suspect a problem right there. Go ahead and try *ALL* the updates. It's a cut of XP Embedded based on XP SP3. I've checked the versions of serial.sys and serenum.sys - they're the same as on my laptop, with Windows Update active. Given the concatenation of somewhat oddball chipsets in this system, and the claim that it works properly under Linux, I'd suspect driver issues, particularly flow control handling. Are your serial devices actually wired correctly for hardware flow control? no they're not :-) You _don't_ use flow control on RS485. Anyway a flow control misconfiguration behaves very different. You don't get anything transmitted (the write() syscall blocks), or you get whole characters lost at the other end (FIFO overruns). Many well-meaning but clueless engineers get the RS-232 signals for different devices miswired, and never notice because they've mishandled flow control and don't use it much. [chuckle] don't tell me about well-meaning engineers :-) What the Taiwanese HW designers can come up with... Such as auto-loopback relays on Ethernet ports, in hardware intended for firewall applications... or they use Linux in an embedded box, are soo very secretive about it (except that you can see the version strings in the firmware images available for download), and they can't seem to get *default routing* right, and they have bugs in serial port handling on a great 16C950 UART (those are two areas where Linux has been okay for decades now, in my experience). You should also definitely state which Windows and Linux operating systems you're using. the production OS is XPe, derived from XP SP3 (Czech locale I believe). The Linux that I'm using for tests, is an in-house mini-distro assembled by hand (scripted file copy) based on Fedora 5, with a 2.6.28.6 kernel (custom config). Booting via PXE and working just fine with my tools :-) ---- The lasting problem is that I keep getting pieces of the suspected hardware RMA'ed due to irrelevant problems (software misconfigurations, RS485 wiring sins), and only now and then an odd piece happens to show the "flipping bit" symptom. Based on the set of *observations so far, I can't even tell if the "flipping bit syndrome in Hyperterminal" was to blame for a particular production malfunction, or if it was just the other problem I found on site :-) This is something I have to sort through myselfs. The publishable results of this ongoing customer case so far have been: 1) a snippet of Mingw C++ code that attempts to mimick the "hyperterminal reset" * * (I straced hyperterminal to see what it does at the level of syscalls, * * *and then I tried to reproduce that at the level of DLL function calls :-) * *http://www.fccps.cz/download/adv/frr/COMRESET.zip * * I've hooked it up into the startup sequence of the last culprit just in case. 2) a brain-dump of collected thoughts on RS485 grounding and termination. * * My head tends to relax if I write things down an publish for the benefit of others * * (provided that they can read through the mess :-) * *http://www.fccps.cz/download/adv/frr/RS485/RS485.html The important point is that I'm still having fun :-) Thanks for your help everybody, take care Frank Rysanek |
http://omgili.com/probleme-rs232-sp3-windows-xp
#14
| |||
| |||
|
|
On Jan 26, 9:04*am, "Frantisek.Rysa... (AT) post (DOT) cz" Frantisek.Rysa... (AT) post (DOT) cz> wrote: Dear gentlemen, many thanks to all of you who responded :-) I'm delighted to see that the USENET is still alive, and that it's sometimes the same people responding to me, who used to respond ~10 years ago... On 22 pro 2009, 15:23, Ian Malcolm wrote: Hyperterminal is known to garble *RECEIVED* characters under certain circumstances if the first three characters recived are identical. *This fault, once triggered, persists until the application is exited. I wonder if it is possible for the same bug to also affect transmit? * And, maybe special thanks to Ian Malcolm - his bug description is the closest to mine :-) If I exit Hyperterminal and start it again, the problem is typically still there. It survives even a power-cycle :-/ Please try a 3rd party terminal and see if the problem goes away... [suggested by several polite people] Yes, this is definitely something I should do. I've seen one more occurrence of the problem, but didn't have a chance to test this - I probably inadvertently reset the UART and the problem went away before I tried a different terminal. I have Putty and CRT on my USB flash drive just in case. Also censoring the uart chip brand and number will not lead you to any answers... * I know :-( It's a matter of not biting the hand that feeds you. After some early rookie experience in that way, I prefer to be cautious. After all, I'm not sure exactly where the problem is, and this decription could cast a shade on innocent hardware, which otherwise looks pretty good... What happens if you send a string of genuine 8-bit characters, eg extended ASCII? This will force Windows to "think about" the 8th bit, whereas anything you type at the keyboard will usually be 7 bits. right, tried that - made a file containing a megabyte of some character with the MSb=log.1, and the problem was still there. Back to 7bit characters, and still it was there. It would be rational to suspect other serial processes (IRDA as well as COM ports). Ha, I haven't checked for IRDA. Makes me wonder if the IRDA modes possibly could use this kind of hardware feature. The UART's can work in some IRDA modes, but the hardware doesn't have a physical IR port, and as far as I know, the IR modes are not even offered in the BIOS setup for the COM ports. I can only hope they're properly disabled. Anyway I believe that Windows don't detect an IR port. Have to check to make sure - thanks for that note. Still it makes me wonder. If the UART device was seized by some IRDA service, the production app running on the PC would fail to open it as a COM port. Sounds weird... I was wondering if some Windows-internal ISA PnP stuff or generic SuperIO support could be messing with the SuperIO chip's config registers at random. Those are a special bank of registers with multiplexed access, separate from the classic ISA UART footprints in IO space. Perhaps more likely the BIOS could have some bugs in that direction (ACPI/SMI handling and whatnot). Wish I had an LPC bus probe :-) Is is possible the send or receive is set to 7 bits + parity and the other set to 8 bits? that would mess up the 8th bit on 50% of the possible characters. No. It works just fine most of the time. The peers are set allright against each other. Seen such misconfigurations before. This is different. Most important it garbles every *other* character in a string. Thanks for the suggestion though :-) You have a "stock Windows serial system"? No Windows updates, no driver updates? I'd suspect a problem right there. Go ahead and try *ALL* the updates.. It's a cut of XP Embedded based on XP SP3. I've checked the versions of serial.sys and serenum.sys - they're the same as on my laptop, with Windows Update active. Given the concatenation of somewhat oddball chipsets in this system, and the claim that it works properly under Linux, I'd suspect driver issues, particularly flow control handling. Are your serial devices actually wired correctly for hardware flow control? no they're not :-) You _don't_ use flow control on RS485. Anyway a flow control misconfiguration behaves very different. You don't get anything transmitted (the write() syscall blocks), or you get whole characters lost at the other end (FIFO overruns). Many well-meaning but clueless engineers get the RS-232 signals for different devices miswired, and never notice because they've mishandled flow control and don't use it much. [chuckle] don't tell me about well-meaning engineers :-) What the Taiwanese HW designers can come up with... Such as auto-loopback relays on Ethernet ports, in hardware intended for firewall applications... or they use Linux in an embedded box, are soo very secretive about it (except that you can see the version strings in the firmware images available for download), and they can't seem to get *default routing* right, and they have bugs in serial port handling on a great 16C950 UART (those are two areas where Linux has been okay for decades now, in my experience). You should also definitely state which Windows and Linux operating systems you're using. the production OS is XPe, derived from XP SP3 (Czech locale I believe). The Linux that I'm using for tests, is an in-house mini-distro assembled by hand (scripted file copy) based on Fedora 5, with a 2.6.28.6 kernel (custom config). Booting via PXE and working just fine with my tools :-) ---- The lasting problem is that I keep getting pieces of the suspected hardware RMA'ed due to irrelevant problems (software misconfigurations, RS485 wiring sins), and only now and then an odd piece happens to show the "flipping bit" symptom. Based on the set of *observations so far, I can't even tell if the "flipping bit syndrome in Hyperterminal" was to blame for a particular production malfunction, or if it was just the other problem I found on site :-) This is something I have to sort through myselfs. The publishable results of this ongoing customer case so far have been: 1) a snippet of Mingw C++ code that attempts to mimick the "hyperterminal reset" * * (I straced hyperterminal to see what it does at the level of syscalls, * * *and then I tried to reproduce that at the level of DLL function calls :-) * *http://www.fccps.cz/download/adv/frr/COMRESET.zip * * I've hooked it up into the startup sequence of the last culprit just in case. 2) a brain-dump of collected thoughts on RS485 grounding and termination. * * My head tends to relax if I write things down an publish for the benefit of others * * (provided that they can read through the mess :-) * *http://www.fccps.cz/download/adv/frr/RS485/RS485.html The important point is that I'm still having fun :-) Thanks for your help everybody, take care Frank Rysanek You might try posting here.http://omgili.com/probleme-rs232-sp3-windows-xp |
http://www.arcelect.com/technica.htm
#15
| ||||||||||
| ||||||||||
|
|
Hyperterminal is known to garble *RECEIVED* characters under certain circumstances if the first three characters recived are identical. This fault, once triggered, persists until the application is exited. I wonder if it is possible for the same bug to also affect transmit? And, maybe special thanks to Ian Malcolm - his bug description is the |
If I exit Hyperterminal and start it again, the problem is typically
still there.
It survives even a power-cycle :-/
Quote:
|
Please try a 3rd party terminal and see if the problem goes away... [suggested by several polite people] |
Yes, this is definitely something I should do.
I've seen one more occurrence of the problem,
but didn't have a chance to test this - I probably inadvertently
reset the UART and the problem went away before I tried a different
terminal.
I have Putty and CRT on my USB flash drive just in case.
Quote:
|
Also censoring the uart chip brand and number will not lead you to any answers... I know :-( |
After some early rookie experience in that way, I prefer to be
cautious.
After all, I'm not sure exactly where the problem is, and this
decription
could cast a shade on innocent hardware, which otherwise looks pretty
good...
Quote:
|
What happens if you send a string of genuine 8-bit characters, eg extended ASCII? This will force Windows to "think about" the 8th bit, whereas anything you type at the keyboard will usually be 7 bits. right, tried that - made a file containing a megabyte of some |
and the problem was still there. Back to 7bit characters, and still it
was there.
Quote:
|
It would be rational to suspect other serial processes (IRDA as well as COM ports). Ha, I haven't checked for IRDA. Makes me wonder if the IRDA modes |
could use this kind of hardware feature. The UART's can work in some
IRDA modes,
but the hardware doesn't have a physical IR port, and as far as I
know, the IR modes
are not even offered in the BIOS setup for the COM ports. I can only
hope they're
properly disabled. Anyway I believe that Windows don't detect an IR
port.
Have to check to make sure - thanks for that note.
Still it makes me wonder. If the UART device was seized by some IRDA
service,
the production app running on the PC would fail to open it as a COM
port.
Sounds weird...
I was wondering if some Windows-internal ISA PnP stuff or generic
SuperIO
support could be messing with the SuperIO chip's config registers at
random.
Those are a special bank of registers with multiplexed access,
separate from
the classic ISA UART footprints in IO space.
Perhaps more likely the BIOS could have some bugs in that direction
(ACPI/SMI
handling and whatnot). Wish I had an LPC bus probe :-)
Quote:
|
Is is possible the send or receive is set to 7 bits + parity and the other set to 8 bits? that would mess up the 8th bit on 50% of the possible characters. No. It works just fine most of the time. |
Seen such misconfigurations before. This is different.
Most important it garbles every *other* character in a string.
Thanks for the suggestion though :-)
Quote:
|
You have a "stock Windows serial system"? No Windows updates, no driver updates? I'd suspect a problem right there. Go ahead and try *ALL* the updates. It's a cut of XP Embedded based on XP SP3. I've checked the versions |
serial.sys and serenum.sys - they're the same as on my laptop,
with Windows Update active.
Quote:
|
Given the concatenation of somewhat oddball chipsets in this system, and the claim that it works properly under Linux, I'd suspect driver issues, particularly flow control handling. Are your serial devices actually wired correctly for hardware flow control? no they're not :-) You _don't_ use flow control on RS485. |
You don't get anything transmitted (the write() syscall blocks),
or you get whole characters lost at the other end (FIFO overruns).
Quote:
|
Many well-meaning but clueless engineers get the RS-232 signals for different devices miswired, and never notice because they've mishandled flow control and don't use it much. [chuckle] don't tell me about well-meaning engineers :-) |
Such as auto-loopback relays on Ethernet ports, in hardware
intended for firewall applications... or they use Linux in an embedded
box,
are soo very secretive about it (except that you can see the version
strings
in the firmware images available for download), and they can't seem to
get *default routing* right, and they have bugs in serial port
handling
on a great 16C950 UART (those are two areas where Linux has been
okay for decades now, in my experience).
Quote:
|
You should also definitely state which Windows and Linux operating systems you're using. the production OS is XPe, derived from XP SP3 (Czech locale I |
The Linux that I'm using for tests, is an in-house mini-distro
assembled by hand
(scripted file copy) based on Fedora 5, with a 2.6.28.6 kernel
(custom config). Booting via PXE and working just fine with my
tools :-)
----
The lasting problem is that I keep getting pieces of the suspected
hardware
RMA'ed due to irrelevant problems (software misconfigurations, RS485
wiring sins),
and only now and then an odd piece happens to show the "flipping bit"
symptom.
Based on the set of observations so far, I can't even tell if the
"flipping bit syndrome in Hyperterminal" was to blame for a particular
production
malfunction, or if it was just the other problem I found on site :-)
This is something I have to sort through myselfs.
The publishable results of this ongoing customer case so far have
been:
1) a snippet of Mingw C++ code that attempts to mimick the
"hyperterminal reset"
(I straced hyperterminal to see what it does at the level of
syscalls,
and then I tried to reproduce that at the level of DLL function
calls :-)
http://www.fccps.cz/download/adv/frr/COMRESET.zip
I've hooked it up into the startup sequence of the last culprit
just in case.
2) a brain-dump of collected thoughts on RS485 grounding and
termination.
My head tends to relax if I write things down an publish for the
benefit of others
(provided that they can read through the mess :-)
http://www.fccps.cz/download/adv/frr/RS485/RS485.html
The important point is that I'm still having fun :-)
Thanks for your help everybody, take care
Frank Rysanek
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.