FreeCalypso > hg > freecalypso-hwlab

comparison doc/FT232R-notes @ 173:df4bf4e06221

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc: several articles moved to other repositories
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 11 Sep 2023 06:51:05 +0000
parents 026dd69e4ebb
children
comparison
equal deleted inserted replaced
172:e75478dda304 173:df4bf4e06221
1 Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected 1 This article has moved; the new location is:
2 to ever have a blank EEPROM in normal usage: these chips have their EEPROM
3 built in, and FTDI probably ships them with this internal EEPROM already
4 programmed. I said "probably" because I have not yet had an occasion to build
5 my own FT232R-containing board where I would be getting completely pristine
6 "bare" chips from Digi-Key, thus I have no first-hand verified knowledge.
7 2
8 As an experiment, I have programmed "blank" (0xFFFF in every word) images into 3 https://www.freecalypso.org/hg/fc-usbser-tools/file/tip/doc/FT232R-notes
9 the two FT232R devices I have available for play at the moment (specifically
10 devices which I could afford to brick if things went badly), and FT232R behaves
11 the same way as FTDI's earlier chips with external EEPROMs: it runs with a fixed
12 default config when the EEPROM is invalid. But this configuration is NOT
13 recommended for production use - you should always have a valid EEPROM config
14 in your FT232R chip.
15
16 When our FreeCalypso fteeprom tools were first put together in 2019-04, I was
17 getting erratic behaviour: when I tried to program my own EEPROM config
18 generated with ftee-gen232r, the resulting EEPROM content became a bitwise AND
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.
26
27 Further investigation revealed that FT232R EEPROM write operations work
28 correctly only if they are preceded by this magic sequence:
29
30 ftdi_usb_reset(&ftdi);
31 ftdi_poll_modem_status(&ftdi, &modem_status);
32 ftdi_set_latency_timer(&ftdi, 0x77);
33
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...