FT245BM problem: missing/corrupt data

Have you asked the technical support of FTDI? Their support is very good.

Meindert

Yes, we did. But they are gone for the weekend. And we have a tight deadline :<

How long is your USB cable? Do you have capacitors at the USB connector? Is your FT245 TST pin connected to GND?

Best regards Tsvetan

--- PCB prototypes for $26 at

PCB any volume assembly Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430

I've had problems with resetting or turning off my project with HyperTerminal running to the USB module. HyperTerminal locks up, no comms, and refuses to shut down. My laptop is unable to shut it down from the control panel, and the laptop itself is unable to fully shut down - I have to pull the power plug and the battery.

I reckon their FT245BM chip and software needs more work to become robust...

Really? When evaluating USB/232 chips, I just showed them, how I can lock up their FT232-VCP-driver. Easily. Each time I try. Gave them some Portmon-logfiles. Offered to give them a sample program.

Guess, what happens? They told me to try their newest (beta-)driver.

Same procedure again. Guess, what happens? They thanked for the problem report.

This was about 1,5 years ago. Their driver, which isn't beta anymore, still locks up.

If you call this "very good support", it's one, I can easily live without.

I ended with a silabs chip. No hazzles, responsive and honest support.

Andreas

--
A clever person solves a problem.
A wise person avoids it.
- Einstein

With a FT232, I experienced lock-ups also. I was able to continue working by

1) disconnect the USB device. 2) wait some seconds, about half a minute, IIRC. 3) shut down the locked application with the task manager.

Still annoying, but no show stopper.

If I tried to shut down the application before disconnecting and waiting, I ended with the same problem as you. Unrecoverable lock-up.

Andreas

--
There's no time to stop for gas, we're already late.
- Karin Donker

We were having tons of disconnects and driver lockups with the FT245BM and FT232BM chips when connected to USB 2.0.

We adding 47pF caps to ground on USBDP/USBDM, and a 470nF cap connecting USB shield to ground. Testing in our office this eliminated 100% of our problems. In the field it eliminated 90% of the problems, as our products are used in an environment prone to static. We then went up to 100pF caps on USBDP/USBDM, this eliminated 99% of our problems.

The FTDI documentation, at the time we were doing our design, didn't clearly mention the need for these caps. Only the most recent commercial products using the FT232/245 have any of these caps, and most still don't have the

470nF cap connecting USB shield to ground.

When we initially contacted FTDI support they acted like we probably had a flaw in our hardware design. I pointed out that we were using the DLP245PB module which would fail even without the rest of our design attached. I was also able to reproduce the error on a US232B/LC the evaluation USB-to-Serial converter that they sell. Then they recommended that we add the caps mentioned above. Neither the US232B/LC or the DLP245PB module, have the caps.

Regards, Ron Belknap

Ron snipped-for-privacy@hotmail.com

Well, I never really had problems with the chips and drivers. Only once when a laptop locked up when going into sleep while a virtual serial port was opened. A new driver solved it. But I had a few questions about odd baudrates aswered very quickly. Also they helped me well when I wanted a special version of the OS X driver with special baudrate behaviour on certain PID and all that. No problem, all could be done and was done in no time. So in that, my experience with FDTI is good.

Mmmm.... I thought about changing to that one too.

Meindert

Cable is about 3 feet long. No capacitors on the USB connector TST pin is connected to ground

USB

Where exactly did you add the caps on USBDP/USBDM?

Between the IC and the resistor or between the resistor and the USB connector?

Bertolt

Between the resistor and the USB connector.

[snip FTDI not admitting or fixing hardware]

Thanks for the tip off.

I hate it when tech support people fob us off with the usual excuses.

I recall a stepper/servo motor controller chip feature refusing to work, and their techies taking weeks to get round to talking to their software guys before they confessed they'd run out of ROM and not implemented it. Nobody had do

I politely but firmly read them the riot act...

Anyway, on my to do list: add capacitor work-arounds, and look for more robust chips.

Anybody know any products similar to FTDI USB modules, but without the problems?

TIA, K.

You've seen Meindert and me mentioning silabs (the artist formerly known as cygnal :-)? Their USB/232 worked for me.

Andreas

--

Learn from the mistakes of others. You won't live long enough to make
all of them yourself.

That's a serial port interface, and I don't have a serial port. Seems a pointless bottleneck in my application.

The module I use is a FIFO interface: just hurl bytes at it and use a pair of handshake lines, very fast.

K.

Here is the response from FTDI:

The data corruption/missing data will occur because at power up, the device connected to FIFO could toggle the RD/WR lines, this causes the internal buffer pointers to advance or load garbage data. To synchronise the FIFO do something like the following:

1) Send a character repeatedly to the FIFO (say 'A'). 2) The device connected to the FIFO should echo this character back to the FIFO 3) When the FIFO starts receiving 'A's it then sends an 'AB' 4) Again the external device should then echo back the 'AB' 5) When the FIFO receives the 'AB' your external device is synchronised with the FIFO.

The synchronisation of the FIFO is particularly needed if the external device powers up after the FT245 device.

If you can power up the micro before the FT245 or exactly at the same time you may be able to avoid the problem. Essentially you need to ensure the RX/WR pins are not toggled when you are not attempting to read or write data.

The FTDI system is extremely sensitive and injecting a simple 4vpp 500ns transient onto a USB line causes their system to de-enumerate.

Total cable disconnection and reconnection/re-enumeration is req'd to re-establish.

Their gargabe is not robust at all. I lost thousands of dollars and months fixing their sh**.

I have a galvanic/opto isolation design which is working so far on problem hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an industrial environment.

I am willing to give anyone interested this design which took me months of stress and experimentation to design.

I am interested... Regards Rocky

schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...

Strange, i can't remember any problems with PWREN#. If i remember correctly i had no pullup on PWREN#.

What i had where multiple edgs on RD/WR while (RESET# == high) and (PWREN# == high). These where NOT caused by the uC but definitely by the FT245. I could also see them on the scope with RD/WR floationg and even with pull-ups to VCC_USB on RD/WR.

If my memory serves me right part of the problem is that RD/WR are pulled-up (by the FT245) before they are pulled-down because the "pull-down option" is set in the EEPROM.

You can see it here:

From my point of view there are multiple design flaws in the FT245:

- IOs should not be pulled-up until the EEPROM is read and the "pull-down option" is evaluated.

- IMHO it does not make any sense to power PWREN# from VCC_IO. It would be much better if VCC_IO could be switched with PWREN#.

- the FIFO should be reset on (or shortly after) the falling edge on PWREN#.

Bertolt

I'm interested in your design. Please email me.

Regards,

John Strupat