Closed theedge456 closed 4 years ago
Can you test this with a known good I2C chip, like a 24C02 or similar generic EEPROM?
On 14/11/2020 19:00, whitequark wrote:
Can you test this with a known good I2C chip, like a 24C02 or similar generic EEPROM?
According to the TRM, the 24LCxx family address is 0b1010. Using this address leads to the same result, writing either in RAM or scratchpad. The dongle is driven by this chip[1]. I failed something...
My bad, the address is above 127. I received a response from the eeprom at 0xa2.
Ok. What if you do the same on your original dongle? Also, you might want to scan write addresses only (i<128
, i2c_start(i<<1)
). If you scan read address you need to read a dummy byte afterwards.
On 16/11/2020 12:26, whitequark wrote:
Ok. What if you do the same on your original dongle? Also, you might want to scan write addresses only (
i<128
,i2c_start(i<<1)
). Using (i<128
,i2c_start(i<<1)
) on the dongle shows no 00 anywhere. Saving I2CS & _ID0 and I2CS & _ID1 at the beginning of the main shows: ID1=1 and ID0=0 Does it means that the address in on 16-bits ?
Yes, that seems to imply that the dongle has loaded its firmware from a EEPROM at the unshifted address 0b1010001.
Adding i2c_cancel=false
leads to consistent results. All is 0x00 but the EEPROM (0x51).
I would have expected to see the demodulator.
Is it possible that it is dormant ?
Sure. I don't see what that has to do with libfx2 though.
You're right
Hello, First, thanks for making this API available. It helped a lot. I have an old DVB-T dongle derived from the FX2LP connected to an i2c device. To know what address it is using, I'm using the following code:
The problem is that the dump shows 00 for every element. Any hint ?
-- Fabien