FT2232C and MPSSE

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: FT2232C and MPSSE
Quoted text here. Click to load it

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...
 


--
Don McKenzie
E-Mail Contact Page:      http://www.e-dotcom.com/ecp.php?un=Dontronics

We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE

Quoted text here. Click to load it


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.
We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE
Quoted text here. Click to load it


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

We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE
Quoted text here. Click to load it
 
Quoted text here. Click to load it

Hi Don,


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.
We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE

Quoted text here. Click to load it

If you get any results Andreas, I am more than happy to post your
findings on my pages for the benefit of all.

I wish the internet was around in the days when I was doing all of my
heavy R&D engineer-ology. :-)

Don...


--
Don McKenzie
E-Mail Contact Page:      http://www.e-dotcom.com/ecp.php?un=Dontronics

We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE
Quoted text here. Click to load it

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



Re: FT2232C and MPSSE

Quoted text here. Click to load it

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?
We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE

Quoted text here. Click to load it

<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
We've slightly trimmed the long signature. Click to see the full one.
Re: FT2232C and MPSSE
snipped-for-privacy@yahoo.com (db) wrote in message
Quoted text here. Click to load it

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.

Site Timeline