What do different I2C errors mean?

Timeout on I2C Write BUSY

I2C device not responding

Timeout on I2C Write Transmit Mode 2

I'm currently having a hell of a time talking to my I2C digipots - which were working. But the same part that was working is now not working.... I remember having a horrible time making it work before. In both cases, it was like the SPI problem - i was just checking everything over and over and over.

After powercycling the part, it goes to Timeout on I2C Write BUSY. Calling setup makes it go back to timeout on write transmit.

>for (i=0x28;i<120;i++) { try {I2C2.writeTo(i,0);} catch (err) {console.log("not "+i+err.msg);}}
not 40Timeout on I2C Write BUSY
not 41Timeout on I2C Write BUSY
not 42Timeout on I2C Write BUSY
not 43Timeout on I2C Write BUSY
not 44Timeout on I2C Write BUSY
Execution Interrupted.
>I2C2.setup({scl:B10,sda:B11});
=undefined
>for (i=0x28;i<120;i++) { try {I2C2.writeTo(i,0);} catch (err) {console.log("not "+i+err.msg);}}
not 40Timeout on I2C Write Transmit Mode 2
not 41Timeout on I2C Write Transmit Mode 2
not 42Timeout on I2C Write Transmit Mode 2
not 43Timeout on I2C Write Transmit Mode 2
not 44Timeout on I2C Write Transmit Mode 2
not 45Timeout on I2C Write Transmit Mode 2
Execution Interrupted.
> 

Occasionally, I've gotten I2C device not responding. But I have not seen any pattern in when I get that behavior.

10k resistors are connected between +3.3v and scl and between +3.3v and sda, and all 3 address pins, as well as the not-connected pin are grounded.

Any ideas?

I'm not sure to be honest. Are you running something other than 1v69? I did change something for I2C repeated start in trunk, and that may have broken something...

When something normal happens (like the start bit times out) it usually just says I2C device not responding. Other errors are things that I'd hope wouldn't usually happen, although they imply that it's got past the stage of responding to the start bit.

It comes straight from this code - check out the WAIT_UNTIL macros: https://github.com/espruino/Espruino/blob/master/targets/stm32/jshardware.c#L2171

This is a clean v69 released flash - nothing special. I thought the v69 released version had 2250 jsvars now though? But I just reflashed and that's what I have.

>process.env
={
      "VERSION":"1v69",
      "BUILD_DATE":"Jul 29 2014",
      "BUILD_TIME":"16:29:45",
      "GIT_COMMIT":"b2386d6f0c48ac3970ba76e4e3dd4a6a48623469",
      "BOARD":"ESPRUINOBOARD",
      "CHIP":"STM32F103RCT6",
      "CHIP_FAMILY":"STM32F1",
      "FLASH":262144,"RAM":49152,
      "SERIAL":"33ffd305-41573033-33720843",
      "CONSOLE":"USB"
    }
>process.memory
=function () { [native code] }
>process.memory()
={"free":1754,"usage":46,"total":1800,"history":24,"stackEndAddress":536909768,"flash_start":134217728,"flash_binary_end":134438392,"flash_code_start":134443008,"flash_length":262144}
> 

I get the same error even if I disconnect the SDA and SCL lines....

No... 1v69 doesn't have the smaller variables in it. I fixed a bunch of stuff for 1v69 so I wanted to make a build that was pretty reliable. The small variables build is going to have a few bugs I'm sure :)

I'm not sure then - if removing the cables makes no difference I'd say there must be some kind of wiring problem? Do normal I2C devices still work?

It's working now. I had the SDA and SCL backwards.... But what makes no sense is that I tried swapping SDA and SCL at least half a dozen times last night.

This is the same kind of madness that I had to deal with last time I was working with this part. Hours of rechecking simple things, then finally something I've checked before fixes it.

@DrAzzy, I noticed the same thing when working with serial. I would spend hours swapping Rx and tx on both the Espruino and the device I'm communicating with. I would unplug the Espruino from USB and plug it back in. I would also try resaving the code. Then finally, like magic, serial communication works. Why do you think that happens?

No clue - it happens to me frequently though - you just check everything over and over, and then try something you already tried, and it fixes it.

I don't get it - but I'm pretty sure it's a wetware problem, because once I get it working, the problem (almost) never comes back, so I generally have to assume that I was doing something wrong.

That said, there's at least one component (MCP4xxx series) I've worked with that'll hang if you send it bogus commands and won't work again until it's powercycled - that sort of behavior would be a real bitch to debug - that might well be what was causing my problems in this case. Apparently the Constant Crash 3000 is like that too - hangs until reset if you look at it wrong.