[attachimg=3]I don't think this will do any good but I'd try too. The USB chip can use either the EEPROM or the PC method, yours is likely using the PC option. Can you get access to the EEPROM contents anywhere- this will be the next problem, a blank eeprom won't do much for you.
Hrm, maybe I'm misunderstanding what's going on here then? My sense is that the EEPROM is just being used to store various configuration values, and that when the USB controller attempts to read/write to the hard-coded addresses it can't because the EEPROM isn't present. For instance the driver just has a bunch of constants like this:
COEFF_C1_ADDR = 0x80
"""The address of the string containing coefficient C1"""
COEFF_C2_ADDR = 0xA0
"""The address of the string containing coefficient C2"""
COEFF_C3_ADDR = 0xC0
"""The address of the string containing coefficient C3"""
COEFF_C4_ADDR = 0xE0
"""The address of the string containing coefficient C4"""
And then attempts to read values from these addresses via something like this:
ctrl_transfer(StellarNet._IN_DEVICE, StellarNet.COEFF_C1_ADDR , 0, 0, 2)
So there's no firmware stored in the EEPROM, just data (I think?).
I've actually soldered a blank EEPROM in, but it doesn't seem that the board can read/write to it. I've attached a zipfile of pulseview recording of an attempt to read/write from the EEPROM. Looks like a lot of failures of the master/slave to respond? Anyone have some suggested reading that would help me puzzle out exactly what's happening here? Lots of this:
[attach=2]