search

sinara-hw / Kasli

Kasli is a powerful FPGA carrier, capable of controlling 12 Eurocard extension modules.
Other
16 stars 1 forks source link

I2C SDA 0.8V when pulled low by Si5324 #78

Closed hartytp closed 4 years ago

hartytp commented 4 years ago

https://chat.m-labs.hk/m-labs/pl/9anbfbwbw3yr8j7xctdsx6isxr

sbourdeauducq commented 4 years ago

Why not just configure it properly?

Why not just make hardware that is well-behaved by default, especially since the contention may cause permanent damage?

sbourdeauducq commented 4 years ago

Can't the incompatibility issue be resolved with ~3 lines of code that look at the hardware version and invert the pin?

hartytp commented 4 years ago

Removing IC22 is easier than programming FTDI chips

Removing IC22 would break all the USB I2C tooling which would be a big regression IMHO

hartytp commented 4 years ago

Another option is to just add a couple of current limiting resistors between the FTDI chip and IC22. That way we're guaranteed that programming errors can't cause hardware damage (which feels like something we should aim for) at close to 0 extra cost/complexity...

marmeladapk commented 4 years ago

@jordens

suspend_pull_downs doesn't help regardless if console is opened.

The EEPROM contents have no effect on the selected mode with the exception of selecting the TXDEN for RS485 mode when asynchronous serial interface has been selected in software. If the device is reset, then the 4 channels must be reconfigured into the required mode.

So programming FTDI cannot fix it by default unless there are other options to set in EEPROM (there aren't to my knowledge).

I don't have the layout in front of me, but is that something we can easily hack into the existing boards with a scalpel and some glue?

@hartytp It's possible but not easy. If you want to add inverter know, easier fix would be to lift 8th pin of IC22 (EN pin) and add inverter (transistor) on top of it + some wires to pulldown resistor nearby.

I still think the enable pin should be inverted in v2.1 to make the hardware friendlier.

I'm also for it. It will be a proper fix (and currently seems the only possible permanent one).

marmeladapk commented 4 years ago

Not sure if this is related to the original problem, but @hartytp's board that @DonaldKellett was using has developed what looks like a hardware failure with I2C_SW SCL and SDA now permanently stuck low.

@sbourdeauducq This looks like a hardware failure. Probably ESD. Let's hope that it's the voltage translator that's fried, not FPGA inputs.

jordens commented 4 years ago

Yes. There is no EEPROM fix. I went through the entire thing, including the not-yet exposed bits of libftdi. That pin is DTR and is an active low output. My proposal ist the following:

DCD is an input with a weak enough pull-up. This is forwards and backwards compatible, can be done in rework, doesn't need new chips, doesn't change the logic, and needs no version detection and special treatment in software.

hartytp commented 4 years ago

Any objections to pushing out a v2.1 release with minor fixes soon?

jordens commented 4 years ago

That seems much to early given that a lot of the board hasn't really been tested thoroughly yet. Little data/solutions on the fan, wr clock recovery, 4 sfp, smps noise, panel mechanics, just to name a few.

marmeladapk commented 4 years ago

I'll check @jordens proposal the next time I'll be in our lab.

@jordens would you have a moment to check if I2C from FTDI works as expected? Or maybe you have already checked it? (even without the fix for current problem)

jordens commented 4 years ago

If you fix the fundamentally broken ARTIQ I2C implementation it works fine. Don't ever actively drive SCL/SDA high (unless you want to do some risky high speed tricks), especially not in a multi-master topology. That may also be the root of a lot of other problems (including what prompted #46 and the issues with Banker and Fastino I2C). Unfortunately the switch reset polarity is now switched which requires a special treatment.

jordens commented 4 years ago

https://github.com/m-labs/artiq/pull/1484

marmeladapk commented 4 years ago

I checked that @jordens' solution works fine (though I didn't cut the trace yet, I made a non-permanent fix).

ARTIQ implementation and @jordens' bitbang kasli-i2c work fine. However pyftdi in MPSSE mode has problems. I checked that I can talk to other devices but muxes don't seem to react to changes in their registers.

I've seen this behaviour before and it was caused my simultaneous changes of SDA and SCL (I2C from misoc). Now it doesn't seem to be the case but I'm not sure if it's worth dwelling on this further since pyftdi in MPSSE mode has terrible timings and weird voltage levels (see screenshot). tek00037

sbourdeauducq commented 4 years ago

The I2C proxy bitstream route avoids all these problems at once.

jordens commented 4 years ago

The i2c mpsse didn't seem worth using. I added it to compare with bitbanging and it wasn't faster in the typical use cases. I wouldn't be surprised if pyftdi doesn't implenent i2c-mpsse correctly (iirc it's not a function of the mpsse but a use case).

pathfinder49 commented 3 years ago

Yes. There is no EEPROM fix. I went through the entire thing, including the not-yet exposed bits of libftdi. That pin is DTR and is an active low output. My proposal ist the following:

* Disconnect BDBUS4, pin 26 from its via

* Connect the via to BDBUS6, pin 28

* In I2C software always drive both BDBUS4 and 6.

DCD is an input with a weak enough pull-up. This is forwards and backwards compatible, can be done in rework, doesn't need new chips, doesn't change the logic, and needs no version detection and special treatment in software.

I've got an unpatched kasli 2.0.0. Is this the agreed way to fix this on existing boards? Is the software part of the fix included in artiq? Edit: looks like its been merged in.