You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was re-burning a 256 eeprom that was written by the board manufacturer (adafruit FT232H) as a 128 eeprom. This meant that the string descriptors were in the wrong location and lsusb was not reporting the manufacturer or serial number (and also ftdi_urls.py). I used ftconf to read the original eeprom (forced to 128byte) and using the resulting values to re-burn to a 256 size.
I found that the default 0xff fill on clearing meant areas in the configuration bit are had many original 0x00 converted to 0xff. I changed the eeprom_clear call to use 0x00. This meant that the original and new bit areas was the same.
Not sure if the default of filling with 0xff is a good idea as it may be setting bits that should stay unset.
So this may cause an issue or not.
BTW this re-burning the eeprom has worked perfectly, with all descriptors now available and no decode/encode errors.
Attached the hex output for the original 128bit, the generated 256bit (fill with 0xff), and the used generated 256bit (fill with 0x00) images
I was re-burning a 256 eeprom that was written by the board manufacturer (adafruit FT232H) as a 128 eeprom. This meant that the string descriptors were in the wrong location and lsusb was not reporting the manufacturer or serial number (and also ftdi_urls.py). I used ftconf to read the original eeprom (forced to 128byte) and using the resulting values to re-burn to a 256 size.
I found that the default 0xff fill on clearing meant areas in the configuration bit are had many original 0x00 converted to 0xff. I changed the eeprom_clear call to use 0x00. This meant that the original and new bit areas was the same.
Not sure if the default of filling with 0xff is a good idea as it may be setting bits that should stay unset.
So this may cause an issue or not.
BTW this re-burning the eeprom has worked perfectly, with all descriptors now available and no decode/encode errors.
Attached the hex output for the original 128bit, the generated 256bit (fill with 0xff), and the used generated 256bit (fill with 0x00) images
Love this work. Thanks.
Cheers
John Floyd
EE128-hex.txt
EE256-hex-with-0xff.txt
EE256-hex-final.txt
The text was updated successfully, but these errors were encountered: