LM75 not accessible via I2C

[HarryMakes]

I am using kasli_i2c to flash a Fastino v1.0 (looks like rc3) via a Kasli. I was able to flash the EEPROM and read it back, but the script failed when it tries to access LM75 temperature sensor using the slave address 0x48 (according to the schematics). Using debug level logging it gives the following output:

## eeprom.dump()
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xe0 A
DEBUG:i2c_bitbang:W 0x8 A
DEBUG:i2c_bitbang:P
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xe2 A
DEBUG:i2c_bitbang:W 0x0 A
DEBUG:i2c_bitbang:P
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xa0 A
DEBUG:i2c_bitbang:W 0x0 A
DEBUG:i2c_bitbang:R
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xa1 A
DEBUG:i2c_bitbang:R 0x8 A
...
DEBUG:i2c_bitbang:P
INFO:__main__:Sinara eeprom valid Sinara(name='Fastino', board=18, data_rev=0, major=1, minor=0, variant=0, port=0, vendor=3, vendor_data=b'\xff\xff\xff\xff\xff\xff\xff\xff', project_data=b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff', user_data=b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff', board_data=b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff', eui48=b'\x80\x1f\x12]f\\')
## temp1.report()
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0x90 N
DEBUG:i2c_bitbang:P
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xe0 A
DEBUG:i2c_bitbang:W 0x0 A
DEBUG:i2c_bitbang:P
DEBUG:i2c_bitbang:S
DEBUG:i2c_bitbang:W 0xe2 A
DEBUG:i2c_bitbang:W 0x0 A
DEBUG:i2c_bitbang:P
Traceback (most recent call last):
  File "flash_fastino.py", line 115, in <module>
    b.report()
  File "flash_fastino.py", line 39, in report
    self.temp1.report()
  File "/home/harry/Git/kasli-i2c/chips.py", line 367, in report
    self.get_config(), self.get_temperature(),
  File "/home/harry/Git/kasli-i2c/chips.py", line 360, in get_config
    cfg = self.bus.read_many(self.addr, 0x01, 1)[0]
  File "/home/harry/Git/kasli-i2c/i2c_bitbang.py", line 239, in read_many
    raise I2CNACK("Address Write NACK", addr)
pyftdi.i2c.I2cNackError: [Errno Address Write NACK] 72

It showed that the sensor doesn't seem to respond to I2C frames using the correct address (0b1001000 << 1 == 0x90). I am using pyftdi version 0.42.2.

[marmeladapk]

Did you switch the I2C mux on Kasli first?

[pathfinder49]

Have you had a look at #48? This also discusses issues preventing i2c access to LM75.

[HarryMakes]

As per @pathfinder49's comment regarding fixes for the I2C, I removed the pull-down resister R48 and successfully fixed the flashing via I2C problem (however, the FPGA must be re-configured by power-cycling, as the kasli_i2c flashing script would result in CDONE assertion timeout).

As my current work does not include fixing the LM75 on the v1.0 board I have (with certain re-work that addresses other issues that are unrelated to I2C), I do not plan to adopt the solutions raised in #48 (e.g. connecting the P3V3_MP and P3V3MP together) for now. I believe #48 has provided the solution for my LM75 issue. Therefore, I am now closing this issue.

[pathfinder49]

Glad that worked :smile: Just for completeness, connecting the P3V3MP and P3V3_MP nets is a seperate issue (#47). Without the connection PWR_EN is floated. This leads to unspecified behaviour of most voltage regulators (P/N12V0A have a spererate enable mechanism.)

[HarryMakes]

I see, so there were unwanted behaviours on the regulators (because PWR_EN was supposed to enable them but it was floating in v1.0?), and connecting the two nets is the solution for it - is that right?

And to conclude, the solution to the I2C issue (including both SPI and LM75) is to replace all P3V3 supplies with P3V3_MP in the I2C-SPI bridge (IC10), in addition to lowering the pull-down resistor - is that also correct? (I don't fully understand how the 2nd solution suggested by gkasprow was meant to fix the I2C - weren't the EEM0_I2C's SCL and SDA pins already directly connected to IC10 in v1.0? IC10 is the I2C extender, right?)

[pathfinder49]

I see, so there were unwanted behaviours on the regulators (because PWR_EN was supposed to enable them but it was floating in v1.0?), and connecting the two nets is the solution for it - is that right?

Indeed

weren't the EEM0_I2C's SCL and SDA pins already directly connected to IC10 in v1.0?

They were not. This is a circular dependency.

The solution to the I2C issue (including both SPI and LM75) is to replace all P3V3 supplies with P3V3_MP in the I2C-SPI bridge (IC10), in addition to lowering the pull-down resistor

These are the changes that were made for V1.1. I'm not aware of anyone attempting to modify a V1.0 board in this way.