# HG changeset patch # User Mychaela Falconia # Date 1600395818 0 # Node ID 026dd69e4ebbe78b4709d672863eda726d67c4ca # Parent f0b0970fbe2ec91473bae5992caef3b3fb22ee59 FT232R-notes article moved to doc directory diff -r f0b0970fbe2e -r 026dd69e4ebb doc/FT232R-notes --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/FT232R-notes Fri Sep 18 02:23:38 2020 +0000 @@ -0,0 +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 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. + +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: + + ftdi_usb_reset(&ftdi); + ftdi_poll_modem_status(&ftdi, &modem_status); + ftdi_set_latency_timer(&ftdi, 0x77); + +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... diff -r f0b0970fbe2e -r 026dd69e4ebb eeproms/dumps/FT232R-notes --- a/eeproms/dumps/FT232R-notes Thu Sep 17 04:18:46 2020 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,42 +0,0 @@ -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 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. - -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: - - ftdi_usb_reset(&ftdi); - ftdi_poll_modem_status(&ftdi, &modem_status); - ftdi_set_latency_timer(&ftdi, 0x77); - -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...