BitHead

Yippee! Everyone can relax their brains... bad chip - bad chip - bad chip !!! And best of all... NOT AN ORANGE PI PROBLEM !! :-) Because I have 8 of these things on the pcb - and they only have two select-able addresses - I needed to route SCL and SDA through a dual 4:1 analog switch. An analog switch that worked just fine - nice low RDS-ON figures, unless... You hurt it while using a hot-air solder re-work wand (because it is a TSSOP and soldering those little legs one at a time is solder-bridge-sucky) - or maybe it got zapped - or who knows - but that was it. Plopped in a 74VHC4052 and all was well. Still can't explain why the Arduino @ 100kHz looked/worked fine - no hint of lows trying to be 'more than low'. Maybe the higher clock rate was doing some capacitive coupling/charging of neighboring internal FETs? Anyhow - thanks for letting me flail/vent here - and may you never have cause to remember that you've seen this sort of thing before. :-)

Picture of wiring :-) Not a lot to see - just a bundle of 8 wires between headers that plug into my PCB and the OPI GPIO header. Wires that work just fine when plugged into the Arduino instead of the OPI. 4.7K does pull up that mid-level 'low' voltage just enough for it to read as 'high', the ACKs become NACKs and it 'read error's out. Removing them completely - the mid-level thing remains, lows read as 0's but the rise time is too slow - and it error's out. 20K pulls up enough to make the clock rise time OK but of course, the mid-level thing is still there. The minimum specs for clock low/high times are 1.3uS/0.6uS - I'm seeing 1.5uS/1.0uS - so that's not it. And remember - this does not happen when I plug it into the ATmega328 - it looks great there. You just made me add a ground jumper - sorry, no change. :-( Thanks for thinking on it - but I think I'm going to have to hope it's happened to someone else, and that 'that someone' figured it out, and that 'that someone' reads this, and that 'that someone' takes time to spill the beans. :-) I could be waiting awhile - life is short - I ordered a RPI . Will try that - have a 2nd opinion soon. PS. I just looked at my scope pics again - that 'good ACK' was bugging me - until I thought... 'ACKs are for receiving data - and that's what the master is doing there - a Read. It has no problem making SDA go low - so that's why it looks good there.

Yup - replying to myself - that post was getting lengthy - going off bottom of screen, so... I found a hard-coded register that isn't reset to all 0's - like a lot of them seem to be - that fooled me into thinking SDA was being strongly held at 1/2Vcc. It isn't. Here we see a read of the Mfr.ID at 0x7E = 0x5449. High's are getting pulled up fine. It's like the Low's have a floor that is not ground. I would like to think that it's the device, but it works fine when I simply un-plug it from the OPI and plug it into the Arduino thing - scope probes and grounds don't get touched - it works and signals look great there. So I'm back to wondering if internal pull-ups are ON/crossed - I2C port config bits not right?

Yes - I'm here flailing about for clues (like person who can't swim in deep end of pool :-) ). I know, this is more of an Orange Pi/ I2C_sunxi thing, but OPI and Armbian go together, so... I have an oscilloscope that shows I2C-0 putting out clock bits with my LDC1314's '2A' address data just fine - up to the ninth clock. On the ninth clock - which follows clocks for bits 6,5,4,3,2,1,0,R/W - and should be where the slave responds with the ACK/NACK bit, the SDA line goes to 1/2Vcc - like the master is fighting the slave. It's like the device is trying its best to pull it low for an ACK, but the Master (OPI pin PA12) is not letting go. I have a picture - result of issuing 'i2cdetect -q 0 0x2A 0x2A' ... It gets worse. When attempting a read of a register, it will hang at that 1/2Vcc level - like it latched up - for the duration of the subsequent read clock cycles. That level is just squeaking in as a '0' (below 2V) - so it sees the ACK as an ACK, until it gets the data - which reads as 0's when it really is 1's. Like this... ( 010 1010 R ?, ???? ???? 0, ?????11? 1) I just installed all software for I2C three days ago - should be up-to-date. I know you're thinking it ... WTF? Why is the master not releasing SDA after the 8th clock? Just thought more about what I was seeing... and now I'm really confused'. SDA does begin to rise just before the ACK bit - at exactly the same relative time as the preceding bits - and plateaus off at 1/2Vcc. There's no 'little-glitch' suggesting slave is attempting to assert a low, but can't. But neither does the data rise for the 1's. It's like the slave SDA pin is going into some sort of latch-up condition. Really? A condition where it latches up with the open-collector transistor turned on so weakly that it equals the pull-up resistor? Which, by the way, I varied from 4.7K to 20K. The 4.7K nudged the ACK up to a 'NACK' and 20K failed due to slow rise times - but the mid-level thing remained. So, I might have to say 'Excuse me - never mind." This might not be the right forum for this issue (cough-cough-Texas Instruments-cough-cough). Oh- forgot to mention... this LDC1314 works wonderfully with a little Arduino-clone (ATmega328(8MHz) - and it's SDA ands SCL waveforms are crisp and proper. I keep switching back and forth from Arduino(works great) to the OPI (fails miserably) hoping to get a clue - but there is this... The Arduino's I2C bus speed is 100kHz. The OPI is 400kHz. But... "So what?". It's rated for 400kHz and the timing/edges look good at 400kHz. And it's not like it's flaky - it fails quite consistently. Oh - here's another thing - there are EIGHT of these chips on my PC board - they all behave equally good and bad. It's not a 'just that chip' thing. So, maybe this IS the right forum?!? May you now be as confused as I. Have a nice day and be glad you're not me. :-)