FP245RL interfacing problems

[simonharvey]

ft245r close error

Hello,

My name is Simon Harvey and I am a design engineer working for a company called SCL Limited (down here in Dunedin, New Zealand).

I have been given the extreme joy of designing a USB controlled waveform generator, which used a Spartan 3E FPGA. Most of the genarator works flawlessly however there is a very annoying bug that we just have no idea of how to fix.

This bug is due to the reliability of FT245RL data IO after a specific power up sequence:
1. If we plug the generator into the USB host and then turn the generator on we get perfect IO.
2. however, if we power up the generator before plugging it into the USB host then we get IO errors.

Is there anybody out here who has seen this error before?

We have done alot of testing to try and find the source of the error, the tests that we have done include:
1. We thought that it was a problem with the reset circuit (ie. with R18 & R19 somehow messing up with the on board POR) however removing these dosent get rid of the problem.
2. We have also tried powering up the FT245R and the FPGA individually, ie. resetting the FPGA once it goes into the error state but that dosen't seem to do anything as well.
3. Even when the waveform generator powers up correctly, If we send a command to the device (via the FTDI supplied library to FT_CyclePort or FT_ResetPort and then if we restart the test application the IO error arises even though we haven't unplugged-plugged in the device (the FPGA state remains unmodified).

This could very well be an interaction between the FPGA and the FT245R however we just don't know what it could be. As I have mentioned we have done alot of testing however we just cant seem to figure it out (I even have plans to redesign the USB interface using a chip from silicon labs) but we just don't know.

Any help would be greatly appreciated.

Kind regards
Simon Harvey

ps. The schematic for the FT245RL interface is shown below:

In it the data and RD# and WR lines go via 100R resistors to the input pins of a Spartan 3E FPGA. The rest are connected directly to the FPGA.

 

[Holger]

ft245rl connection problem

I am German. sorry for my broken English.
Here a Link to a similar Projekt:
https://www.emsp.tu-berlin.de/lehre...en/videosignalgenerator-mit-usb-schnittstelle

I had a General Connect Problem with my new MsVista and Dell Laptop Inspirion , with the FTDI-POR-Boot-Connectinon. The modern USB(Typ2) Host-Transceivers a soooo sensetive. The 1Kz Freuency isn very stable(is scrolls on Scope ).
(spikes ect.) The Host idle USB-Data Needles a not so sharp, as in the older
Tower PCs. Older PC have Ferrit-Coiles an pF-Caps on Helper-Boards, i found out.
I have a 245BM Interface.
With the 245BM type you can Scope the SCLK at the Ext.EEProm Pin at
POR. After this the MS-Vista Driver at Host sends a Data-Burst.
If this is ok, the Protocoll ist stable.

The FTDI Errata says for trouble with Connections an long Cables. 47pF
I have done a 47pF from +D Line to GND.and the same with the -D Line.
Look that the VCC is good bufferd Buffer with Caps.
With a Scope you can look at the +D,-D Line at the USB.
You can see 1Khz sharp Needles, in Idle Bus Mode state.
If you do swith an ie. a Halogen(Mag.Coil) Lamp near the USB-BUS, the Host Protocoll brakes emediate down. ( very very sensitive Thing)
But with a POR it is back again.
Hot Running connect or Hot Plugin is not easy.
I think if you make a test with the hand reset, you can check out more, by Scope.
I design a Atmega-Protocoll Watch-Dog , an a LED-Live-Blinker of the Protocoll.
So I can see if my POReset is ok and the Protocoll ist Running good in condition.
I think the Problem ist the bad Reset-Curcit, with the Voltage-Devider.
First Scope-Check the +D and -D Line.
Do connect a Dymmy Load. Check the VCC smoothnes, and the GROUND
connections.
Till later Good Luck.
Holger

 

[Scoperd]

ft245rl eeprom reset

Simon,

We have had similar problems with a 232 type device as processor ports were powering the usb device when disconnected which seemed to hold it in a brown out state under similar conditions you have described.

we got round these by

1) powering the device from the usb bus (with ferrite supression),

2)all connections from the usb device and the processor should be high impedance inputs until the circuit "recognises" that the usb is connected, we did it by measuring the 3.3voltage in an analogue to digital or monitor the pwren line.

3) Reset connected to the 3.3v line with vccio set at 3.3v.

This seem to correct the problem.

Hope this helps

Regards

 

[dsPIC24F]

ft245 idle data lines

This seems like a power-up reset issue, why not design a power-up sequency circuit to secure one get the advantage than the other whenever two power are connected.