Since a number of users have been experiencing tveeprom "Huh no eeprom present" messages, I've been trying to learn about the i2c bus on the HVR-1600.
First, the Serial EEPROM chip on my HVR-1600 is U3 in the upper corner of the card. It appears to be an ATMEL 24C02BN. The ATMEL 24C02 2 kbit (256 * 8) Serial EEPROM datasheet is here: http://www.atmel.com/dyn/resources/prod_documents/doc5126.pdf Also, the latest I2C spec, with a page or two of NXP (Phillips) marketing tacked to the front, is here: http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf The HVR's EEPROM is wired up with all the lower address bits grounded, so its I2C address is 1010000 (0x50 or 0xA0 depending on your perspective). The SDA and SCL line on pins 5 & 6 go to test points TP10 & TP11 on the card and then clearly over to SDA & SCL pins 1 & 2 of the CS5345, which is also on the same I2C bus. I note that the cx18 driver relies on i2c-algo-bit to get things done. It seems to use delays to meet the bits on the bus when they should be there. The cx18-i2c.c file claims to set the cx23418's I2C master clock to 100 kHz, the .udelay specified is 10 microseconds or one cycle of a 100 kHz clock, and the .timeout for slow devices is specified as 200 jiffies. I have never (knock on wood) had apparent I2C problems with my HVR-1600 in my setup. So can anyone with tveeprom "Huh, ...?" problems do any of the following: 1. Put a capturing oscilloscope or logic analyzer on the HVR's TP10 (data) and TP11 clock to record what's going on on the I2C bus. (All four pins on the left side of the U3 EEPROM should be tied to ground for a known ground point.) 2. Compile the i2c-algo-bit module with DEBUG enabled and set the module option for i2c-algo-bit i2c-debug=3, to view what phase of the I2C transaction causes i2c-algo-bit to fail with -EREMOTEIO (-121). 3. Remove the conditional reset of the I2C block in the CX23418 by changing the cx18-i2c.c:init_cx18_i2c() to force the code inside this if statement to always be executed: if (read_reg(CX18_REG_I2C_2_WR) != 0x0003c02f) { /* Reset/Unreset I2C hardware block */ write_reg(0x10000000, 0xc71004); /* Clock select 220MHz */ write_reg(0x10001000, 0xc71024); /* Clock Enable */ } I was also thinking that porting forward, to cx18, the ivtv "newi2c" customized i2c bit banging algorithm, that polls for SDA/SCL state changes instead of using delays, may help. Any thoughts/comments? I can't test any ideas to fix the problem, since I can't reproduce it. -Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
