The original rev had two issues that were immediately noted by BSVi. First, the starting directory was hardcoded to c:temp with no error checking, which caused the program to bomb if that directory didn’t exist. Second, the device was only searching for FTDI interfaces with the labels FT232B or FT232R, whereas BSVi’s interface was custom and used his own ID string.
This new version allows for the user to enter a custom string for matching the FTDI interface, as well as the ability to continue if the c:temp directory is not found. Put yer custom string in the textbox right beneath the “Find All FTDI Interfaces” button.
Special thanks to BSVi for pointing out these issues, and keep em’ coming folks! Remember, some user’s don’t have the VB6 environment so without a bug-free exe they’re out of luck!
Openschemes_FT232_SVF_Player_v0.11
By BSVi October 28, 2011 - 10:08 pm
Hi. Thanks for quick fix. Yet another issue – On bare OS I’m getting messge “Richtx32.ocx is missing”. The workaround is to google for “Richtx32.ocx” and place it to application’s startup directory. But it’s better to include that library.
By openschemes October 29, 2011 - 7:20 am
That’s a good idea. Usually it’s not as easy as just putting the ocx in local directory. It will be included.
By BSVi October 29, 2011 - 2:17 am
Two more bugs:
1. My project is located on D disk, but I can’t switch to it. Workaround: in dirve selection cobmobox select C drive, then select D.
2. When I press “process SVF file” for second time, application crashes with “File already open” exception. When crashes, application doesnt releases FTDI chip and I have to disconnect and connect usb cable to run application again.
By openschemes October 29, 2011 - 7:24 am
1) This workaround sounds fine.
2) You should not attempt to re-open the file if it is already running in the single step. Stop the stepping first, then re-run. As for the crash and replug – yes, you are right. If the tool is crashed then the FTDI chip must be replugged to be recognized again.
By peet October 29, 2011 - 11:19 pm
Hi,
I’m very happy with your researches
Can I use this to programm a msp430 via jtag ?
regards
By openschemes October 30, 2011 - 2:33 pm
Good question. If you can convert your programming data to an SVF file, then your chances are good. We don’t have an msp430 here, so we don’t know if it uses the extra reset line (which is not used on the XC2 board we used here). But even if the tool does not work as-is, it’s probably not too hard to hack together a software version than can program the msp430.
By rz2k November 16, 2011 - 7:13 am
Hi,
I’m trying to programm my xc2x64a with ft232rl and always get this error: http://pastie.org/2872339
I’m using this schemtic http://a.yfrog.com/img618/5192/bntjm.jpg and this board http://a.yfrog.com/img741/5487/c8fmz.jpg
I’ve already tried to place 10uF between gnd and vcc and between 3v3 and gnd, also tried polarized 10uF. No luck.
also I’ve double checked all wiring and soledring and tried to switch to other pins, same result, fail on test.
also I’ve tried to use lower clock – on 57600 I have same error or Runtime error: 5 Invalid procedure call or argument. On onebyte version I’m getting same error + “IO error – dammit” sometimes.
Whats wrong and what should I do?
Thanks for your research and work.
Cheers.
By openschemes November 16, 2011 - 7:19 pm
Oh damn, so close! What it looks like is that there is a comms issue between the FT232 and the XC2. Short reads/writes such as device ID are working fine but during longer reads/writes there’s an issue.
You can see it during the 281 byte writes that begin at line 169/171. When the data from line 169 is written (at line 171), we don’t know what’s in the shift register buffer so we have to ignore the readout at line 172. But during the next write at line 179, the data we read back at 180 should be exactly what was written in at line 171. It’s not.
So where do we go from here? Let’s look at the first failed verify line down at 838. It’s best to paste the actual and expected output right next to each other, and we see something like:
READ:03C1BFFFEFFFF73FF3FFFFFFFFFFFEFFFFFE3E5FFFFFFEEEEEEFBFFEFFFFFFFFFFFE0FMASK:03ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
DATA:0306FFFFBFFFC3FF3FFFFFFFFFFFEFFFFFE32FFFFFFF777777DFFF7FFFFFFFFFFF0780
This will take more consideration, but it appears there is a one-bit shift offset. Look at the expected ..F73FF3 – we get ..FC3FF3. Like the data was one bit slow on the clock edge and everything slid one bit. Same reason the EEEE’s (1110, 1110, 1110,) turned into 7777′s (0111, 0111, 0111).
So the chip was flashed, but it’s not possible to tell whether it’s written properly and the readback is bad or the write was bad and the read is good. Does the CPLD function properly? That could tell us the answer there.
To solve the problem, you may need to use shorter wires connecting the FT232 board to the XC2 board. Especially the ground wire. And please ensure that your USB cable actually connects the ground shields of both sides. Nice cables do, cheap cables don’t. The PC has a lot of stray noise which will disturb comms if the grounds aren’t tied together. Next, you may want to try a 10k pullup resistor from 3.3V to the clock and data lines to make sure the edges are pretty fast.
And if it’s a read problem, there is a chance that it could be corrected in software. But that’s a last resort, and only if you’re handy with the VB6 debugger. It’s better to fix the problem than to digitally shift long reads in software. At any rate, we’ll get there – congratulations on your success so far!
By rz2k November 17, 2011 - 1:21 am
Thanks for answer!
I’ve noticed that results are pretty close to needed too, thanks for pointing to shifting issue.
my xc2 is ok, I can program it by lpt cable, but I’m srsly tired of using my old-old pc with lpt, so I’ve decided to try your work
Yesterday I’ve made another layout and board, here it is
layout:
http://a.yfrog.com/img878/142/bd1rq.jpg
all set up:
http://a.yfrog.com/img614/7492/24545227.jpg
Still same results, but now some progress, 2nd or 3rd tests are ok, on 4th or around test same fail. Wires are exactly 8 cm.
Now I will try shorter wires, probably just small pieces of copper from wires from CAT5 twistedpair.
Thanks again for answer, I will post about results later.
By rz2k November 17, 2011 - 2:13 am
heres results, same
1cm wires, shields are connected to gnd.
http://pastie.org/2876850
I’ll try 10k pullup later, if I’ll find 10k…
By openschemes November 18, 2011 - 5:34 pm
Wow, sorry to hear there are still problems. Looks intermittent, especially since it gets through a few lines of verification OK but then fails. The 10k value is nothing special, anything between about 4.7k and 47k should be a good pullup. The purpose is just to make the rising edges faster (the falling edges are already fast) during readout.
Give it a try, and lets get in touch over email to see if we can figure this thing out. Send us a message at ftdi at openschemes and we’ll take it from there.
By openschemes November 18, 2011 - 5:37 pm
Nice work on the board! It looks good, and that wiring should be fine. Did you make that board with photoresist or iron on?