FT4232H semi-randomly fails to read EEPROM on cold reboot
I have a very odd problem with FT4242H devices, which I hope someone
The FT4242H uses an external EEPROM for things like vendor/product
strings and serial number. Without the external EEPROM the
vendor/product strings reverts to defaults and there is no support for a
serial number (which is the thing I'm really interested in). Typically I
keep 4 separate devices conneced (so a total of 16 ports). On a cold
reboot only about half of the FT4242H devices will read the EEPROM
contents. The rest of them will just report defaults when examined with
udevadm info. When one of the devices, which failed to report a serial
number, is unplugged and plugged back in it will always succeed in
reading the EEPROM contents, and will report the stored serial number.
I've seen this issue turn up in both kernel 126.96.36.199 and 188.8.131.52.
The problem does not seem to be tied to particular devices. For example,
if I swap a working and a non-working board the problem usually does not
move with the board. If anything, specific USB ports seems to work
better than others, but that's not the full explanation either. So far
I've not been able to spot any significant difference between a
successful and failed read in dmesg or messages.
Is there anyone here who is familiar with this type of problem?
As a workaround I've tried to use udevadm trigger to simulate unplug +
re-plug without any success. The default product string is 'Quad RS232-HS'
so I've tried
udevadm trigger --verbose --attr-match=interface=Quad*
which seems to match only the devices that have failed to read the EEPROM.
Unfortunately no combination of remove, add or change has successfully simulated
a unplug + re-plug. Is this entirely the wrong approach, or what am I doing wrong?