FreeCalypso > hg > freecalypso-hwlab

comparison eeproms/dumps/FT232R-notes @ 76:4e13c90c1405

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
eeproms/dumps/FT232R-notes: update for current understanding
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 17 Sep 2020 00:42:17 +0000
parents af70c59654ed
children
comparison
equal deleted inserted replaced
75:bd85e0360259 76:4e13c90c1405
1 Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected 1 Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected
2 to ever have a blank EEPROM in normal usage: these chips have their EEPROM 2 to ever have a blank EEPROM in normal usage: these chips have their EEPROM
3 built in, and FTDI ships them with this internal EEPROM already programmed. 3 built in, and FTDI probably ships them with this internal EEPROM already
4 It may be possible to create a "blank" EEPROM by explicitly programming 0xFFFF 4 programmed. I said "probably" because I have not yet had an occasion to build
5 into every word, but it would be an unnatural scenario, and I (Mother Mychaela) 5 my own FT232R-containing board where I would be getting completely pristine
6 do not currently have an FT232R device on which I can experiment: I don't have 6 "bare" chips from Digi-Key, thus I have no first-hand verified knowledge.
7 an FT232R device which is not valuable and which is not already bricked.
8 7
9 I have read out the EEPROM content from the two specimen I did have available: 8 As an experiment, I have programmed "blank" (0xFFFF in every word) images into
10 FT232R-specimen1 came from a no-name ebay-sourced FT232RL breakout board; 9 the two FT232R devices I have available for play at the moment (specifically
11 FT232R-specimen2 came from George UberWaves' "FTDI Professional" USB-serial 10 devices which I could afford to brick if things went badly), and FT232R behaves
12 cable with OsmocomBB branding. Specimen 2 is probably a genuine FT232RL chip 11 the same way as FTDI's earlier chips with external EEPROMs: it runs with a fixed
13 (I remember George telling me that he went out of his way to procure genuine 12 default config when the EEPROM is invalid. But this configuration is NOT
14 FTDI chips after having been burned by FTDI's Winblows drivers screwing around 13 recommended for production use - you should always have a valid EEPROM config
15 with close-but-not-perfect clones), but specimen 1 is suspected to be one of 14 in your FT232R chip.
16 those less-than-perfect clones: the serial number string was programmed to
17 "00000000", whereas FTDI supposedly program true per-unit serial numbers.
18 15
19 The only diffs between FT232R-specimen1 and FT232R-specimen2 are the just- 16 When our FreeCalypso fteeprom tools were first put together in 2019-04, I was
20 mentioned serial number string (specimen 2 has it set to "A9031HG6", which looks 17 getting erratic behaviour: when I tried to program my own EEPROM config
21 like a real per-unit serial number), two non-understood "garbage" words after 18 generated with ftee-gen232r, the resulting EEPROM content became a bitwise AND
22 the last string, and of course the checksum. 19 between the previous image and the new one, as if the "EEPROM" is not really an
20 erasable memory, but one of OTP kind where ones can be turned into zeros, but
21 not the other way around. I was doing this experiment on a no-name FT232RL
22 adapter from ebay, thus my first thought was that the FT232RL chip was bad, a
23 less-than-perfect clone rather than genuine FTDI. But then I bought a UB232R
24 module from Digi-Key (presumably containing a genuine FT232RQ chip), and it
25 behaved the same way.
23 26
24 The unit that was specimen 1 (the suspected fake) is now bricked: when I tried 27 Further investigation revealed that FT232R EEPROM write operations work
25 to program my own EEPROM config generated with ftee-gen232r, the resulting 28 correctly only if they are preceded by this magic sequence:
26 EEPROM content became a bitwise AND between the previous image and the new one, 29
27 as if the "EEPROM" is not really an erasable memory, but one of OTP kind where 30 ftdi_usb_reset(&ftdi);
28 ones can be turned into zeros, but not the other way around. I am not willing 31 ftdi_poll_modem_status(&ftdi, &modem_status);
29 to experiment on the specimen 2 chip because it is part of a valuable cable 32 ftdi_set_latency_timer(&ftdi, 0x77);
30 assembly which I don't want to risk bricking, so I will need to order more 33
31 sacrificial hardware and wait for it to arrive before I can experiment further. 34 I can see how FTDI could have reasonably implemented a sort of safety lock on
35 their EEPROM write operations, allowing them only if a special unlock sequence
36 has been given - but it completely baffles me why they are doing some sort of
37 OTP emulation in the absence of the right magic sequence, as opposed to
38 disabling EEPROM writes altogether. It is worth noting that this magic sequence
39 is NOT needed for programming external EEPROMs behind FT2232x chips - were FTDI
40 folks being deliberately malicious in designing their FT232R chip to simulate
41 appearance of being bricked when it is programmed with older (or third-party)
42 software tools that don't know the new magic sequence? Who knows...