simonharvey
New Member
Hello,
My name is Simon Harvey and I am a design engineer working for a small company called SCL Limited (located in Dunedin, New Zealand).
I have been given the task of designing a USB controlled waveform generator, which used a Spartan 3E FPGA. Most of the generator works, however there is a very annoying bug that we just have no idea of how to fix.
This bug prevents bidirectional data transfer from the FT245RL to the USB host, and occurrs reliably 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. I have a plan to redesign the USB interface using a chip from silicon labs however my boss does not yet know about this.
Any help would be greatly appreciated.
Kind regards
Simon Harvey
ps. The schematic for the FT245RL interface is shown below:
**broken link removed**
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.
My name is Simon Harvey and I am a design engineer working for a small company called SCL Limited (located in Dunedin, New Zealand).
I have been given the task of designing a USB controlled waveform generator, which used a Spartan 3E FPGA. Most of the generator works, however there is a very annoying bug that we just have no idea of how to fix.
This bug prevents bidirectional data transfer from the FT245RL to the USB host, and occurrs reliably 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. I have a plan to redesign the USB interface using a chip from silicon labs however my boss does not yet know about this.
Any help would be greatly appreciated.
Kind regards
Simon Harvey
ps. The schematic for the FT245RL interface is shown below:
**broken link removed**
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.
