eblot / pyftdi

FTDI device driver written in pure Python
Other
509 stars 213 forks source link

FT232RL eeprom write issue #267

Open webgeek1234 opened 3 years ago

webgeek1234 commented 3 years ago

I have a few identical XYGStudy ft232rl adapters, specifically purchased for the available cbus pins to use in gpio mode. I was able to use ftconf to set the cbus pins to gpio and write the eeprom. Everything worked fine at that point. Then I tried to change the product name to have a human readable differentiation between the adapters and apparently something broke. The adapters no longer enumerate with a product name or a serial and can only be accessed by index 1. And if multiple are plugged in, ftdi_urls lists them as 1, 2, 3; but ftconf will only access index 1 and will randomly pick one of the adapters to operate on.

These commands were run in order without changing attached hardware.

# ftdi_urls.py 
Available interfaces:
  ftdi://ftdi:232:1/1                
  ftdi://ftdi:232:2/1                
  ftdi://ftdi:232:3/1
  # ftconf.py -x ftdi://ftdi:232:2/1

Error: No such device
# ftconf.py -x ftdi://ftdi:232:1/1
000000   00 40 03 04 01 60 00 00 a0 2d 08 00 00 00 18 0a   .@...`...-......
000010   22 28 4a 12 aa aa 05 00 0a 03 46 00 54 00 44 00   "(J.......F.T.D.
000020   49 00 28 03 46 00 54 00 32 00 33 00 32 00 52 00   I.(.F.T.2.3.2.R.
000030   20 00 55 00 53 00 42 00 20 00 55 00 41 00 52 00    .U.S.B. .U.A.R.
000040   54 00 20 00 52 00 65 00 79 00 12 03 41 00 42 00   T. .R.e.y...A.B.
000050   30 00 4b 00 52 00 59 00 35 00 54 00 00 00 00 00   0.K.R.Y.5.T.....
000060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 ac 5a   ...............Z
# ftconf.py -x ftdi://ftdi:232:1/1
000000   00 40 03 04 01 60 00 00 a0 2d 08 00 00 00 18 0a   .@...`...-......
000010   22 0e 30 12 aa aa 05 00 0a 03 46 00 54 00 44 00   ".0.......F.T.D.
000020   49 00 0e 03 46 00 54 00 32 00 33 00 32 00 52 00   I...F.T.2.3.2.R.
000030   12 03 41 00 42 00 30 00 4b 00 52 00 4d 00 31 00   ..A.B.0.K.R.M.1.
000040   41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   A...............
000050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 e1 8b   ................

I tried to reset the product name and serial with only one adapter plugged in at a time. The command used was:

ftconf.py --serial-number=AB0KRM1A --product="FT232R" -u ftdi://ftdi:232:1/1

It appears that the eeprom does get written, but the issue persists. Product name and serial do not get read in device enumeration. I am uncertain if something bogus is being written to the eeprom and the device firmware is failing to read it or what. Or if something I'm passing ftconf is wrong.

OS: Fedora 34 x86_64 Pyfdti version: 0.52.9-2 from the package repo

webgeek1234 commented 3 years ago

I believe I found the issue with the resulting eeprom. The string offsets in 0x0E, 0x10, and 0x12 are being written as absolute offsets. However, I note in the libftdi code (1) that the string offset has 0x80 added to it. And flashing these devices with ftdi_eeprom does result in properly detected manufacturer, product, and serial.

(1) http://developer.intra2net.com/git/?p=libftdi;a=blob;f=src/ftdi.c;h=f5b70188f91fc1d4c329d891698ec74566ebeb94;hb=5c2c58e03ea999534e8cb64906c8ae8b15536c30#l3064

eblot commented 3 years ago

Note: I should definitely remove this index thing which is a design error that is 15 year old :)

Thanks for the bug report, I'll try to have a look at it.

ghost commented 1 year ago

Experiencing this with a clone, but I am not sure they don't support USB string desc changes.

dkitzman commented 1 year ago

Is there any update on this? The current release has problems programming the usb descriptors for both the FT-X and FT232R chips that I'm trying to use. I tracked down the error for the FT-X to be related to the mirroring bug, and the FT232R's issue is this 0x80 offset problem. I've verified that the eeprom regression branch resolves the problem for me, at least.