# HG changeset patch # User Mychaela Falconia # Date 1600303337 0 # Node ID 4e13c90c1405f110a881a4413cd8f9a3f4fe0865 # Parent bd85e03602590d843d56bbea5e2d6abf522f012a eeproms/dumps/FT232R-notes: update for current understanding diff -r bd85e0360259 -r 4e13c90c1405 eeproms/dumps/FT232R-notes --- a/eeproms/dumps/FT232R-notes Wed Sep 16 23:43:36 2020 +0000 +++ b/eeproms/dumps/FT232R-notes Thu Sep 17 00:42:17 2020 +0000 @@ -1,31 +1,42 @@ 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. +built in, and FTDI probably ships them with this internal EEPROM already +programmed. I said "probably" because I have not yet had an occasion to build +my own FT232R-containing board where I would be getting completely pristine +"bare" chips from Digi-Key, thus I have no first-hand verified knowledge. + +As an experiment, I have programmed "blank" (0xFFFF in every word) images into +the two FT232R devices I have available for play at the moment (specifically +devices which I could afford to brick if things went badly), and FT232R behaves +the same way as FTDI's earlier chips with external EEPROMs: it runs with a fixed +default config when the EEPROM is invalid. But this configuration is NOT +recommended for production use - you should always have a valid EEPROM config +in your FT232R chip. -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. +When our FreeCalypso fteeprom tools were first put together in 2019-04, I was +getting erratic behaviour: 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 was doing this experiment on a no-name FT232RL +adapter from ebay, thus my first thought was that the FT232RL chip was bad, a +less-than-perfect clone rather than genuine FTDI. But then I bought a UB232R +module from Digi-Key (presumably containing a genuine FT232RQ chip), and it +behaved the same way. + +Further investigation revealed that FT232R EEPROM write operations work +correctly only if they are preceded by this magic sequence: -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. + ftdi_usb_reset(&ftdi); + ftdi_poll_modem_status(&ftdi, &modem_status); + ftdi_set_latency_timer(&ftdi, 0x77); -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. +I can see how FTDI could have reasonably implemented a sort of safety lock on +their EEPROM write operations, allowing them only if a special unlock sequence +has been given - but it completely baffles me why they are doing some sort of +OTP emulation in the absence of the right magic sequence, as opposed to +disabling EEPROM writes altogether. It is worth noting that this magic sequence +is NOT needed for programming external EEPROMs behind FT2232x chips - were FTDI +folks being deliberately malicious in designing their FT232R chip to simulate +appearance of being bricked when it is programmed with older (or third-party) +software tools that don't know the new magic sequence? Who knows...