FT2232C and MPSSE

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.

Reply to
db
Loading thread data ...

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
 Click to see the full signature
Reply to
Don McKenzie

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.
 Click to see the full signature
Reply to
Andreas Hadler

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 to
db

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

formatting link
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
 Click to see the full signature
Reply to
Don McKenzie

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 to
Meindert Sprang

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?
 Click to see the full signature
Reply to
Andreas Hadler

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.
 Click to see the full signature
Reply to
Andreas Hadler

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
 Click to see the full signature
Reply to
Don McKenzie

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
 Click to see the full signature
Reply to
Andreas Hadler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.