Writing EEPROM on FT232R / FT245R

[Marius Kintel]

Hi,

Has anyone successfully managed to write to the EEPROM of FT232R or
FT245R chips.
I tried writing to the former using the latest git revisions of
libftdi and ftdi_eeprom but without success. Symptoms are as follows:
o Erase: Nothing happens.
o Write: The device appears to be erased instead of written.

In the README of ftdi_eeprom, it says that FT232BM/FT245BM is
supported, so this might just be missing support for the chips I want
to use.

If someone could verify/clarify this, I could take a look at
implementing support for this myself.
In case, some tips for how to best capture raw USB communication from
MProg under Windows would be very welcome.

Kind Regards,

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Jim Paris]

Post by Marius Kintel
Hi,
Has anyone successfully managed to write to the EEPROM of FT232R or
FT245R chips.
I tried writing to the former using the latest git revisions of libftdi
o Erase: Nothing happens.
o Write: The device appears to be erased instead of written.
In the README of ftdi_eeprom, it says that FT232BM/FT245BM is supported,
so this might just be missing support for the chips I want to use.
If someone could verify/clarify this, I could take a look at
implementing support for this myself.
In case, some tips for how to best capture raw USB communication from
MProg under Windows would be very welcome.

Hi Marius,

I traced MProg in the past and came up with the following patch. I
don't think it's correct -- since all it does is set the latency
timer(?) -- but it seemed to work for me. At some point I was going
to revisit this and try to figure out a more proper solution.

-jim

diff -urN libftdi-0.14-orig/src/ftdi.c libftdi-0.14/src/ftdi.c
--- libftdi-0.14-orig/src/ftdi.c 2008-10-01 17:53:51.000000000 -0400
+++ libftdi-0.14/src/ftdi.c 2008-10-01 17:54:01.000000000 -0400
@@ -1915,6 +1915,9 @@
unsigned short usb_val;
int i;

+ if (usb_control_msg(ftdi->usb_dev, 0x40, 0x09, 0x0077, i, NULL, 0, ftdi->usb_write_timeout) != 0)
+ ftdi_error_return(-1, "unable to start eeprom write");
+
for (i = 0; i < ftdi->eeprom_size/2; i++) {
usb_val = eeprom[i*2];
usb_val += eeprom[(i*2)+1] << 8;

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Post by Jim Paris
I traced MProg in the past and came up with the following patch. I
don't think it's correct -- since all it does is set the latency
timer(?) -- but it seemed to work for me. At some point I was going
to revisit this and try to figure out a more proper solution.

Why do you think this sets the latency timer?
Did anyone compile some document summarizing the current knowledge of
the FTDI USB protocols?

Anyway, I'll give it a spin and report back my experiences.

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Jim Paris]

Post by Marius Kintel

Post by Jim Paris
I traced MProg in the past and came up with the following patch. I
don't think it's correct -- since all it does is set the latency
timer(?) -- but it seemed to work for me. At some point I was going
to revisit this and try to figure out a more proper solution.

Why do you think this sets the latency timer?

Because it's the exact same thing that ftdi_set_latency_timer does..

Post by Marius Kintel
Did anyone compile some document summarizing the current knowledge of
the FTDI USB protocols?

Not that I'm aware, but the existing libftdi source code (and Linux
ftdi_sio module) are decent references.

-jim

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Post by Jim Paris

Post by Marius Kintel
Why do you think this sets the latency timer?

Because it's the exact same thing that ftdi_set_latency_timer does..

Ah, of course. I got confused by the parameter values vs. requests.

I did some USB tracing and verified this.
However, when I tested it, smth. went wrong and it appears that my
FT232R got badly corrupted:
o libusb reports this:
get_endpoints: an error occurred getting pipe information on pipe 1
Error: unable to claim usb device. Make sure ftdi_sio is unloaded!
o Both Mac OS X and Windows get a kernel panic when trying to use the
normals drivers with the chip.

ouch.

Any ideas how or if it's possible to recover from this?
When I start frying hardware I better slow down a bit before playing
further..

Cheers,

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Marius,

Post by Marius Kintel
Any ideas how or if it's possible to recover from this?
When I start frying hardware I better slow down a bit before playing
further..

Does the kernel still detect the device when you plug it in?

Try to erase the eeprom, then it should fall back to default values.

HTH,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Post by Thomas Jarosch
Does the kernel still detect the device when you plug it in?

I can read the entire device descriptor, both using libusb and USB
device probe tools to browse or list this information.
The mentioned problem occurs when claiming the device, where libusb
fails creating the endpoint list.

Post by Thomas Jarosch
Try to erase the eeprom, then it should fall back to default values.

With libusb/libftdi, this won't work since I cannot claim the device.
Under Windows, MProg requires the V2XX drivers to do this, which crash
upon device connection.

Technically, since I'm only doing control transfers to endpoint 0, I
shouldn't need to build an endpoint list. However, this is an integral
part of claiming a device using libusb, so I'm not sure if it's
possible to get away without doing it (by e.g. temporarily patching
libusb).

Any further ideas are very welcome :)

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Hi again,

Some updates for the archives:

o My FT232R was corrupted due to a failed EEPROM write, causing kernel
panics
under both Windows and Mac OS X (Linux not tested) when using the
FTDI drivers,
and causing libusb to fail claiming the device on Mac OS X (others
not tested).
This also caused MProg to not work since it requires drivers.
Device descriptors worked fine, so it's an EEPROM issue.

I fixed this now by patching libusb to force the claim to work even
though the endpoint properties couldn't be read. I did this on Mac OS
X, and didn't test this on other platforms.
With the patched libusb, I could again access the EEPROM, and
carefully reflash it.

Using a patched libftdi, I can now also write correctly to the EEPROM.

I'll test and clean up my libftdi patches and submit them here. It
would be cool if someone has got the time to take a look, verify and
merge them into the repository.

Cheers,

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Hi Marius,

Post by Marius Kintel
Using a patched libftdi, I can now also write correctly to the EEPROM.

Nice one!

Post by Marius Kintel
I'll test and clean up my libftdi patches and submit them here. It
would be cool if someone has got the time to take a look, verify and
merge them into the repository.

Sure, just send it :-)

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Hi again,

I'm attaching patches solving some issues:
o CMake build system improved for libftdi and implemented for
ftdi_eeprom
o Corrected writing to EEPROM (only tested on FT232R)
o Added ftdi_eeprom_decode() (the inverse of ftdi_eeprom_build())
o Cleaned up some inconsistent use of defines for libusb commands and
requests

libftdi:
0001-Added-FindUSB-cmake-macro.patch
0002-Also-install-.pc-files.patch
0003-Added-ftdi_eeprom_decode.patch
0004-Correct-writing-of-EEPROM.patch
0005-Cleaned-up-control-message-defines.patch
0006-Cleanup-of-decode-function.patch

ftdi_eeprom:
0001-Cmake-support.patch
0002-Added-code-to-test-decode-function.patch
0003-uncommented-decoding-and-debug-printing-of-eeprom-co.patch
0004-Adapted-to-new-decode-size-parameter-disable-debug.patch

I'm not experienced in using git, so I hope these patches make sense
(produced using git format-patch origin...master).

Cheers,

~/= Marius

--
We are Elektropeople for a better living.



--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Hello Marius,

Post by Marius Kintel
o CMake build system improved for libftdi and implemented for
ftdi_eeprom
o Corrected writing to EEPROM (only tested on FT232R)
o Added ftdi_eeprom_decode() (the inverse of ftdi_eeprom_build())
o Cleaned up some inconsistent use of defines for libusb commands and
requests

Thanks for your patches! Especially the EEPROM part looks very good.
I'll review and apply them till the end of the week.

One little thing caught my eye: The FindUSB macro is under
the BSD license while libftdi is licensed as LGPL
and ftdi_eeprom as GPL. Do you think it would be possible
to get a different license for those macros?

Post by Marius Kintel
I'm not experienced in using git, so I hope these patches make sense
(produced using git format-patch origin...master).

Looks good :-)

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Post by Thomas Jarosch
One little thing caught my eye: The FindUSB macro is under
the BSD license while libftdi is licensed as LGPL
and ftdi_eeprom as GPL. Do you think it would be possible
to get a different license for those macros?

We're not linking against the macro, so the license is not an issue.
Also, BSD is LGPL compatible and we can relicense BSD code under LGPL
if we need to.

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Post by Marius Kintel

Post by Thomas Jarosch
One little thing caught my eye: The FindUSB macro is under
the BSD license while libftdi is licensed as LGPL
and ftdi_eeprom as GPL. Do you think it would be possible
to get a different license for those macros?

We're not linking against the macro, so the license is not an issue.
Also, BSD is LGPL compatible and we can relicense BSD code under LGPL
if we need to.

Yes, that's true. Still we have to check if that macro
is licensed under the BSD license with advertising clause.
According to the macro code there should be a "COPYING-CMAKE-SCRIPTS"
file which we must include, too.

I quickly googled for "COPYING-CMAKE-SCRIPTS" and it seems
to contain an advertising clause if it's the one from KDE.
That something I would rather avoid in libftdi.

Also the header of the macro mentions the "freetype" library?

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Hi Thomas,

The COPYING-CMAKE-SCRIPTS attached (yes, it's from the KDE project).
It's true that this file has an advertisement clause.
However, we're not redistributing the macro in binary form. We're only
using it to generate makefiles. We're thus not bound by any other
aspect of this license than source code redistribution.

The reason I added it was that the original usb check was hardwired
into the cmake system, making it only build on default libusb
installations under Linux. This one should work across all supported
platforms.

~/= Marius

--
We are Elektropeople for a better living.



--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Hello Marius,

Post by Marius Kintel
The COPYING-CMAKE-SCRIPTS attached (yes, it's from the KDE project).
It's true that this file has an advertisement clause.
However, we're not redistributing the macro in binary form. We're only
using it to generate makefiles. We're thus not bound by any other aspect
of this license than source code redistribution.

Ok, makes sense.

Post by Marius Kintel
The reason I added it was that the original usb check was hardwired into
the cmake system, making it only build on default libusb installations
under Linux. This one should work across all supported platforms.

Another step forward killing libftdi's autoconf suite :-)

btw: As I'm still a cmake newbie, is there a preferred way
to install files in "/usr/share/doc/PACKAGE-VERSION"?

I started to apply your patches and right now I'm sick since yesterday.
Expect it to be somewhere next week till I'm finished with it, I've an upset
stomach and it's really annoying. Just heading to the doctor...

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Post by Thomas Jarosch
btw: As I'm still a cmake newbie, is there a preferred way
to install files in "/usr/share/doc/PACKAGE-VERSION"?

Me too, but these are some tips:
To set the install prefix, run cmake -DCMAKE_INSTALL_PREFIX=<prefix>
<srcdir>

In your case, /usr. I usually install this in a separate place to make
sure I can remove it cleanly (e.g. $HOME/install/ftdi). I also do out
of source builds to avoid having generated files mixed in with the
sources.

To add installation of docs, maybe smth. like this would work, but I
haven't tested it:

install(FILES ${CMAKE_SOURCE_DIR}/docfile.txt DESTINATION share/doc/
libftdi-${MAJOR_VERSION}.${MINOR_VERSION})

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Jim Paris]

Hi,

Post by Marius Kintel
o Corrected writing to EEPROM (only tested on FT232R)

I can verify that this works on FT232R here.

I found a document that describes the FT232R programming:
http://www.ftdichip.com/Documents/AppNotes/AN_105_FTDI_Device_Programming_Using_Vinculum_VNC1L(FT_000078).pdf

In section 4.3.3 "Writing to the EEPROM of an FTxxxR chip" it says
three things of interest:

- The latency timer must be set to 77ms for programming to work
(this is what you and I both determined by tracing MProg)

- Erasing an internal EEPROM is not supported (as you noted)

- The EEPROM is programmed in 32-bit words, so you need to write
two 16-bit values before an actual write is triggered.
This would affect us if we tried to write a single location,
but since we write the whole thing, it's not a problem.
(as they say, "Writing data to the EEPROM starting at the first
location and finishing at the last location, the conditions for
writing two words at a time in order are met")

Post by Marius Kintel
From c4d60f651ac565d2a155185a8672cca6e3a18423 Mon Sep 17 00:00:00 2001
Date: Mon, 2 Mar 2009 17:36:14 +0100
Subject: [PATCH 4/6] Correct writing of EEPROM
- unsigned short usb_val;
+ unsigned short usb_val, status;
int i;
+ /* These commands were traced while running MProg */
+ ftdi_usb_reset(ftdi);
+ ftdi_poll_modem_status(ftdi, &status);
+ ftdi_set_latency_timer(ftdi, 0x77);

ftdi_usb_reset and ftdi_poll_modem_status are unnecessary here

Post by Marius Kintel
From b8329ee90ab2018e71322f941284965691ac3161 Mon Sep 17 00:00:00 2001
Date: Mon, 2 Mar 2009 18:37:36 +0100
Subject: [PATCH 6/6] Cleanup of decode function

...

Post by Marius Kintel
+/**
+ Decode binary EEPROM image into an ftdi_eeprom structure.
+
+ \param eeprom Pointer to ftdi_eeprom which will be filled in.
+ \param output Buffer of \a size bytes of raw eeprom data
+ \param size size size of eeprom data in bytes
+
+ \retval 0: all fine
+ \retval -1: something went wrong
+
+ FIXME: How to pass size? How to handle size field in ftdi_eeprom?
+ FIXME: Strings are malloc'ed here and should be freed somewhere
+*/
+void ftdi_eeprom_decode(struct ftdi_eeprom *eeprom, unsigned char *buf, int size)

you return values but the function is void


-jim

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Marius Kintel]

Hi Jim,

Thanks for your comments :)
Cool - I wasn't aware of that one.

Post by Jim Paris

Post by Marius Kintel
+ /* These commands were traced while running MProg */
+ ftdi_usb_reset(ftdi);
+ ftdi_poll_modem_status(ftdi, &status);
+ ftdi_set_latency_timer(ftdi, 0x77);

ftdi_usb_reset and ftdi_poll_modem_status are unnecessary here

I suspected that, but MProg appears to send them so I was afraid
deviating from my traced communication could break smth.
Anyway, I'll give it a spin without those calls to verify that it
works at least with my setup.
I've also built myself an FT245R board now, so I can test with that
chip as well.
I also have some FT232BM chips lying around, but I need to design and
etch a board to be able to test it.

Post by Jim Paris
you return values but the function is void

True. It should be declared to return an int.
Thomas: Could fix this when and if you merge this function into libftdi?

~/= Marius

--
We are Elektropeople for a better living.





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Post by Marius Kintel

Post by Jim Paris
you return values but the function is void

True. It should be declared to return an int.
Thomas: Could fix this when and if you merge this function into libftdi?

Patches are all applied now, thanks.

Cheers,
Thomas (who is luckily almost back to normal)

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com

[Thomas Jarosch]

Hi Marius,

Post by Marius Kintel

Post by Jim Paris

Post by Marius Kintel
+ /* These commands were traced while running MProg */
+ ftdi_usb_reset(ftdi);
+ ftdi_poll_modem_status(ftdi, &status);
+ ftdi_set_latency_timer(ftdi, 0x77);

ftdi_usb_reset and ftdi_poll_modem_status are unnecessary here

I suspected that, but MProg appears to send them so I was afraid
deviating from my traced communication could break smth.
Anyway, I'll give it a spin without those calls to verify that it works
at least with my setup.
I've also built myself an FT245R board now, so I can test with that chip
as well.

Nice! Please let me know if I can remove the two other function calls.

Also I did another fix in the eeprom_decode code:
http://developer.intra2net.com/git/?p=libftdi;a=commitdiff;h=6335545d29051b1de8d2d482c25a3c1e2e4ff62c

Would be nice if you could verify if the code is still working for you :-)

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com