FTDI driver installation problems

Why don't you send these question to Mr keith dingwall from FTDI ? He's really helpful and has accumulated quite a lot of knowledge ?

Rene

It makes life a whole lot easier if you use the eeprom and prorogram a product ID (PID) into it (FTDI will allocate you one if you ask them). You just need to update the driver .INF files (described in th ehelp files of FTDI's MPROG eeprom-programming utility). That way it will always look for a driver for your specific PID and ignore any previously installed drivers.

Mike Harrison wrote in news: snipped-for-privacy@4ax.com:

That's the plan, and in fact I laid out the board with a spot for the EEPROM on it. But the documentation (and other comments I googled on this newsgroup) say that it should work without one. So the idea was to start with the least number of variables in the equation.

But I may have to install an EEPROM just to see if I can force the driver to load... jmk

Stef Mientki wrote in news:99227$429b603b$83aef479$ snipped-for-privacy@news2.tudelft.nl:

Long term, probably will. But for now the VCP driver allows us to continue to use the PC-based host program with no changes (just tell it to use a different serial port).

There is nothing wring with the stability of the VCP drivers. We use the chips and the VCP drivers in a commercial product for 3 years and we've never had any reported problems. One good thing to do is strip out any PnP enumerator stuff from the INF files. Makes Windoze behave more nicely when any data is present on the FTDI chip when Windoze starts.

Meindert

At what baudrate are you using them ? (we use 115kB en 230kB) Stef

Meindert

For test purposes, I have been using Procomm Plus. Straight terminal program, just to display the data being sent over the line from the device. If I let everything settle down between the host and the device, then set Procomm Plus to serial port 3 (the "VCP" port), then tell the device to start sending data - works fine. But if I then turn off the device (the FTDI chip is self powered, which means it goes off as well) and back on, not only does Procomm Plus appear to lock up, but Win98 comes up with an internal error that won't go away without a reboot. Haven't tried it under Win2K or XP yet.

One thing I suspect is that the driver is not happy if the device starts sending data (or trying to) before all the enumeration is completed. I will try your suggestion of stripping out any extraneous stuff in the INF file. Also, as has been suggested, now adding the EEPROM may help.

That is a problem of Procomm, which doesn''t handle the disappearing port properly and Win98 might also crash for the same reason. Win2K and XP handle this much better, at least without a crash.

That indeed points into the PnP direction. In our application, navigation instruments are connected to our device, constantly sending data, which is sent continuously to the FTDI chip, also when Windows starts. This has never been a problem.

Strip every line that has "serenum" in it.

Meindert