diff eeproms/dumps/FT232R-notes @ 48:af70c59654ed

EEPROM dumps moved into eeproms/dumps and properly annotated
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 22 Apr 2019 21:36:48 +0000
parents
children 4e13c90c1405
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/eeproms/dumps/FT232R-notes	Mon Apr 22 21:36:48 2019 +0000
@@ -0,0 +1,31 @@
+Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected
+to ever have a blank EEPROM in normal usage: these chips have their EEPROM
+built in, and FTDI ships them with this internal EEPROM already programmed.
+It may be possible to create a "blank" EEPROM by explicitly programming 0xFFFF
+into every word, but it would be an unnatural scenario, and I (Mother Mychaela)
+do not currently have an FT232R device on which I can experiment: I don't have
+an FT232R device which is not valuable and which is not already bricked.
+
+I have read out the EEPROM content from the two specimen I did have available:
+FT232R-specimen1 came from a no-name ebay-sourced FT232RL breakout board;
+FT232R-specimen2 came from George UberWaves' "FTDI Professional" USB-serial
+cable with OsmocomBB branding.  Specimen 2 is probably a genuine FT232RL chip
+(I remember George telling me that he went out of his way to procure genuine
+FTDI chips after having been burned by FTDI's Winblows drivers screwing around
+with close-but-not-perfect clones), but specimen 1 is suspected to be one of
+those less-than-perfect clones: the serial number string was programmed to
+"00000000", whereas FTDI supposedly program true per-unit serial numbers.
+
+The only diffs between FT232R-specimen1 and FT232R-specimen2 are the just-
+mentioned serial number string (specimen 2 has it set to "A9031HG6", which looks
+like a real per-unit serial number), two non-understood "garbage" words after
+the last string, and of course the checksum.
+
+The unit that was specimen 1 (the suspected fake) is now bricked: when I tried
+to program my own EEPROM config generated with ftee-gen232r, the resulting
+EEPROM content became a bitwise AND between the previous image and the new one,
+as if the "EEPROM" is not really an erasable memory, but one of OTP kind where
+ones can be turned into zeros, but not the other way around.  I am not willing
+to experiment on the specimen 2 chip because it is part of a valuable cable
+assembly which I don't want to risk bricking, so I will need to order more
+sacrificial hardware and wait for it to arrive before I can experiment further.