Andreas Hadler <Andreas.Hadler@t-online.de> wrote:
>"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote:
>>
>>Would you be so kind and publish your findings here?
>>I use the FT232 chips in a product and I certainly want to know about this
>>'bug'.
>
>First of all: I'm using FTDI's Windows VCP driver.
>
>When the device starts to talk while data are continously send to the
>device, there seems to be a lock-up in the sending direction. Closing
>the comport in this situation leads to a freeze (win98 etc) or, on
>NT5, to a process lock, so that neither driver nor terminal can be
>terminated by the taskmanager.
>
>The long version (even not with all details):
<snipped (look at the archives)>
I hate to follow-up to myself, but I just got a PM that reminded me to
try to unplug the FTDI-based adapter. Never thought of this - my
installations most of the time are not easy to access, so I didn't
consider this option.
With NT5, unplugging (and, eventually, replugging) the FTDI clears the
seem-so deadlock. I can re-open the port afterwards.
Does anybody know how to force this unplug/replug-sequence
programmatically?
Andreas
--
Andreas Andersson: Have you not yet learned the lesson that if
something seems dead easy, it's probably because you haven't
understood the problem?
Reply by Don McKenzie●June 16, 20042004-06-16
Andreas Hadler wrote:
> Thats fine. And I can confirm that the FTDI based cables in most
> operating conditions seem to be the most reliable I found. It's just a
> special condition that deterministically and reproducible shows this
> problem. I can't avoid this condition - sigh.
>
> BTW, I didn't meant to insult or dispraise you or your products. It
> was just a glimpse of hope that started my outburst.
>Andreas Hadler wrote:
>> Don McKenzie <look@my.sig.com> wrote:
>> Don, in your sig you speak of an USB to RS232 Converter that works.
>> Following your link, I found the (usual?) FT232 converter, and the
>> driver link led to the standard FTDI driver.
>>
>> With a simple terminal software, talking to simple embedded devices, I
>> can crash these converters (or their driver), leading to a complete
>> system freeze (win98 etc.) or a kernel deadlock for driver and
>> communications software with a reboot as the only remedy (NT5, ie W2K
>> and XP).
>> Do you really offer a different solution?
Hi Don,
>no, my solution is the same, but as all my feedback from my customers
>has been from good to excellent
>(see the bottom of http://www.dontronics.com/usb_232.html)
>then that is all I have to work on.
Thats fine. And I can confirm that the FTDI based cables in most
operating conditions seem to be the most reliable I found. It's just a
special condition that deterministically and reproducible shows this
problem. I can't avoid this condition - sigh.
BTW, I didn't meant to insult or dispraise you or your products. It
was just a glimpse of hope that started my outburst.
Andreas
--
Anyone can land any aircraft. The skill is in landing it in a minimum
number of pieces.
Dan, U. S. Air Force, retired
>"Andreas Hadler" <Andreas.Hadler@t-online.de> wrote in message
>>
>> With a simple terminal software, talking to simple embedded devices, I
>> can crash these converters (or their driver), leading to a complete
>> system freeze (win98 etc.) or a kernel deadlock for driver and
>> communications software with a reboot as the only remedy (NT5, ie W2K
>> and XP).
>
>Would you be so kind and publish your findings here?
>I use the FT232 chips in a product and I certainly want to know about this
>'bug'.
First of all: I'm using FTDI's Windows VCP driver.
Just a rough sketch:
When the device starts to talk while data are continously send to the
device, there seems to be a lock-up in the sending direction. Closing
the comport in this situation leads to a freeze (win98 etc) or, on
NT5, to a process lock, so that neither driver nor terminal can be
terminated by the taskmanager.
The long version (even not with all details):
I'm the guy programming the terminal software. I'm using Win32-API
with overlapped IO, resembling the event driven Win3.1-communication
modell by a thread, that posts messages on the events resulting from
WaitCommEvent. The ports are configured (SetupComm) with 4096 Byte In-
and 4096 Byte OutQueue.
The devices are 3-wire connected, using plain 7-bit
ASCII-communication with XON/XOFF-handshake in both directions. I'm
using 19200 Baud in my test cases - the devices can accept a continous
data stream in this speed without resorting to handshake, and they can
answer with continous data streams.
Normally, communication is half-duplex - a user presses an attention
key, gets a prompt from the device, sends a command using keyboard
input, finishes by CR or LF, and the device gives an answer. The
device echoes each char received while in command reception mode and
discards chars received when its not in. Just the plain old terminal
operation. This mode works fine - the ftdi's are very responsive (I've
seen TX or RX-delays with other USB/232 converters) and seem to work
reliable.
When a device is ordered to accept a download, it switches echo mode
off and listens for data. The terminal software sends data read from a
file in 4096 Byte chunks. If the device recognizes an error condition
during receiption, it immediately sends an error message and stops
receiving, changing to terminal mode again. When this happens, things
are getting questionable on the PC.
Normally, I clean up the comport using
SetCommMask(,0) // no more events, terminate pending waits
PurgeComm // clear and abort
EscapeCommFunction( , SETXON)
CloseHandle // close the port
And start over again with opening and configuring the port.
This procedure works fine and has worked since long in lots of
installations with regular COM-Ports and PCI as well as PCMCIA cards
even with different serial port drivers.
Using the FTDI FT232BM based USB RS232 cable, CloseHandle never
returns. When breaking with the debugger, I see slghtly more threads
than expected in my process, some of them waiting in
ZwWaitForMultipleObjects (one of them is mine and supposed to do a
WaitForMultipleObjects), one in NtReplyWaitReceivePortEx, one in
NtDelayExecution, one in NtClose. But I'm not able to terminate the
process - neither with a debugger nor with the taskmanager, neither in
Release- nor in Debug-build, so a reboot is my only remedy. In rare,
really rare cases, even NT5 freezes, e.g. the taskmanager is not
accessible.
Even when I use a less rigoros error handling, e.g. just do the
PurgeComm and the EscapeCommFunction, the transmitter seems to be
dead. I'm still receiving, though.
If you want a detailled story, please contact me directly at rtw at
iep dot de.
Andreas
--
Have you not yet learned the lesson that if something seems dead easy,
it's probably because you haven't understood the problem?
- Andreas Andersson
Reply by Meindert Sprang●June 16, 20042004-06-16
"Andreas Hadler" <Andreas.Hadler@t-online.de> wrote in message
news:cgquc0d19gbl81rq6kl1s1veemccvucs5e@4ax.com...
> Don, in your sig you speak of an USB to RS232 Converter that works.
> Following your link, I found the (usual?) FT232 converter, and the
> driver link led to the standard FTDI driver.
>
> With a simple terminal software, talking to simple embedded devices, I
> can crash these converters (or their driver), leading to a complete
> system freeze (win98 etc.) or a kernel deadlock for driver and
> communications software with a reboot as the only remedy (NT5, ie W2K
> and XP).
Would you be so kind and publish your findings here?
I use the FT232 chips in a product and I certainly want to know about this
'bug'.
Meindert
Reply by Don McKenzie●June 16, 20042004-06-16
Andreas Hadler wrote:
>
> Don McKenzie <look@my.sig.com> wrote:
> Don, in your sig you speak of an USB to RS232 Converter that works.
> Following your link, I found the (usual?) FT232 converter, and the
> driver link led to the standard FTDI driver.
>
> With a simple terminal software, talking to simple embedded devices, I
> can crash these converters (or their driver), leading to a complete
> system freeze (win98 etc.) or a kernel deadlock for driver and
> communications software with a reboot as the only remedy (NT5, ie W2K
> and XP).
>
> I've reported this to FTDI about 3 Months ago, offering help to
> reproduce the problem, even by sending them my embedded device and the
> terminal software - to no avail. I got neither a notice that they are
> working on the problem, nor a single question concerning the detailled
> circumstances. On enquiry, I only got the information that they've not
> made any progress on this problem.
>
> Do you really offer a different solution?
>
Hi Andreas,
no, my solution is the same, but as all my feedback from my customers
has been from good to excellent
(see the bottom of http://www.dontronics.com/usb_232.html)
then that is all I have to work on.
I would suggest trying again, but send it to Keith when he returns. He
is normally very responsive.
Note that email addresses may have changed at FTDI. They had a bad case
of spam, and shifted their servers about 3 months ago, so you may have
caught them on the hop.
Don...
--
Don McKenzie
E-Mail Contact Page: http://www.e-dotcom.com/ecp.php?un=Dontronics
USB to RS232 Converter that works http://www.dontronics.com/usb_232.html
Don's Free Guide To Spam Reduction http://www.e-dotcom.com/spam_exp.php
Reply by db●June 15, 20042004-06-15
javaguy11111@yahoo.com (db) wrote in message news:<903bda3b.0406150344.23a0a905@posting.google.com>...
> I sent this message to FTDI, but have not received a reply. Maybe
> someone here can answer this question.
>
> I have built a board using the FT2232C where I am using the MPSSE mode
> for JTAG. The FT2232C is being interfaced to an LPC2119. Specifically
> I am using the bit commands 0x4E and 0x6E to send and receive data
> from a JTAG interface. I am noticing that when I use the 6E command to
> read data in, I am not seeing just a 0 or 1 being returned. I see
> values other than 0 or 1 coming back. Is this normal?
>
> If this is normal to see values other than 0 or 1 being returned, how
> do I know if I am getting a real error code 0xFA returned. Are the
> other GPIO pins being read when I am using the 6E command. Is there a
> way to tristate the unused pins in MPSSE mode?
>
> Basically I am running into a problem with seeing intermittent 0xFA
> being returned. If I were seeing only 0,1 and 0xFA then I would
> suspect I have done something wrong. However since I am seeing values
> other than 0,1 and 0xFA I can not be certain if I am getting a real
> error or not.
As luck would have, not two minutes after I posted this I received a
reply from FTDI. This is what was sent
"With the - Write 0x6E, Length, Byte1 - will read only the TDO/DI pin,
formatted back to the application as a byte of data in hex, therefore
it is
possible to obtain values other than 0x00, 0x01.
If you see 0xFA treaet it as an error."
This reply was from someone different than the person mentioned in
Don's reply.
So I will work on the assumption that I am doing something wrong.
Either on the board or my software.
When I get the error 0xFA, about 95% of the time it will be followed
by an FD and occasionally I will see a 7D. I do not see these codes
go out on my usb monitor program.
I did run the internal jtag loopback test on the FT2232C last night
and had no errors.
I will try looping back through the data register tonight and see if
the error appears there.
Reply by Andreas Hadler●June 15, 20042004-06-15
Don McKenzie <look@my.sig.com> wrote:
>db wrote:
>>
>> I sent this message to FTDI, but have not received a reply. Maybe
>> someone here can answer this question.
>
>Keith Dingwall is the man that would normallly answer this at FTDI,
>however he is on leave until the 28th of June.
>If you don't get an answer from this group, I would suggest you give
>keith a try later on.
>keith.dingwall at ftdichip.com
Don, in your sig you speak of an USB to RS232 Converter that works.
Following your link, I found the (usual?) FT232 converter, and the
driver link led to the standard FTDI driver.
With a simple terminal software, talking to simple embedded devices, I
can crash these converters (or their driver), leading to a complete
system freeze (win98 etc.) or a kernel deadlock for driver and
communications software with a reboot as the only remedy (NT5, ie W2K
and XP).
I've reported this to FTDI about 3 Months ago, offering help to
reproduce the problem, even by sending them my embedded device and the
terminal software - to no avail. I got neither a notice that they are
working on the problem, nor a single question concerning the detailled
circumstances. On enquiry, I only got the information that they've not
made any progress on this problem.
Do you really offer a different solution?
Andreas
--
A clever person solves a problem.
A wise person avoids it.
- Einstein
Reply by Don McKenzie●June 15, 20042004-06-15
db wrote:
>
> I sent this message to FTDI, but have not received a reply. Maybe
> someone here can answer this question.
>
> I have built a board using the FT2232C where I am using the MPSSE mode
> for JTAG. The FT2232C is being interfaced to an LPC2119. Specifically
> I am using the bit commands 0x4E and 0x6E to send and receive data
> from a JTAG interface. I am noticing that when I use the 6E command to
> read data in, I am not seeing just a 0 or 1 being returned. I see
> values other than 0 or 1 coming back. Is this normal?
>
> If this is normal to see values other than 0 or 1 being returned, how
> do I know if I am getting a real error code 0xFA returned. Are the
> other GPIO pins being read when I am using the 6E command. Is there a
> way to tristate the unused pins in MPSSE mode?
>
> Basically I am running into a problem with seeing intermittent 0xFA
> being returned. If I were seeing only 0,1 and 0xFA then I would
> suspect I have done something wrong. However since I am seeing values
> other than 0,1 and 0xFA I can not be certain if I am getting a real
> error or not.
I sent this message to FTDI, but have not received a reply. Maybe
someone here can answer this question.
I have built a board using the FT2232C where I am using the MPSSE mode
for JTAG. The FT2232C is being interfaced to an LPC2119. Specifically
I am using the bit commands 0x4E and 0x6E to send and receive data
from a JTAG interface. I am noticing that when I use the 6E command to
read data in, I am not seeing just a 0 or 1 being returned. I see
values other than 0 or 1 coming back. Is this normal?
If this is normal to see values other than 0 or 1 being returned, how
do I know if I am getting a real error code 0xFA returned. Are the
other GPIO pins being read when I am using the 6E command. Is there a
way to tristate the unused pins in MPSSE mode?
Basically I am running into a problem with seeing intermittent 0xFA
being returned. If I were seeing only 0,1 and 0xFA then I would
suspect I have done something wrong. However since I am seeing values
other than 0,1 and 0xFA I can not be certain if I am getting a real
error or not.