@pra, this is great! We’ve seen issues w/ the MCP23017 on both the Core and Photon for 6mo using the previous i2c implementation. We’ve had to put many workarounds, including Wire.reset(), but I’m glad this addresses the root cause. Thanks so much!
I received my Photon’s today in the post, I’ll see if I can try it out this evening.
So I flashed the photon and still am getting issues with locked device and before it locked, I was getting corrupted data.
When I flashed the firmware, the photon didn't reboot by itself, so I rebooted it myself. Hope that's ok.
ok, it might have been that pressing the reset button on the photon doesn’t read the firmware in, I pulled the power and re-did it. It looks like it’s running more stable now.
Will report in the next hour or so.
1 Like
Ok, so it was all hopeful but after 30 minutes, it seems the screen is corrupted again 
Anyone else having issues?
@anlek, I have one of those displays. If you share you code I can give it a test with the latest develop branch code 
I'll try a different display (I got a few here).
However I also found this conversation:
Hey @Anlek, that’s my thread. I’m still having issues with my adafruit i2c display. I’m trying to check the firmware to see if I can use @mdma’s patch. I installed the patch using dfutil, but the display still goes FUBAR after some period of time, so I thought maybe I wasn’t on 0.4.5 yet.
There was another thread about i2c displays here: I2C LCD display getting corrupted [SOLVED]
where @BulldogLowell suggested increasing the displays in the i2c library. I’m not sure that will work with the adafruit library though. That’ll be my next thing to try 
@jrubins, Glad to see someone else is having the same issues as me!
What version of the display are you using? I’m using the PI HAT version, are you doing the same?
My corruption took longer and longer to happen but it still happened. I’m going to try a different display tonight to see if maybe that’s the issue. Will report back tomorrow.
@anlek It’s always good to know that you aren’t crazy…or that if you are, at least you have company 
I’m using this lcd display http://www.adafruit.com/products/772 not a piHat, but it looks like it uses similar technology.
Agreed! It looks like both use the MCP23017 chip.
Anyone else have an display with MCP23017 that isn’t getting these issues?
BTW, are you using pullup resistors on your i2c lines?
Yes I am. I don’t recall the values but I believe 4.7K. I’ll check and verify though.
@BulldogLowell you helped out on this thread
Can you help @Anlek and me out? We are talking about the Adafruit RGBLCD library.
There are a couple places with delayMicroseconds() calls like the lcd_i2c library. Is it likely to be one of these places?
void Adafruit_RGBLCDShield::pulseEnable(void) {
_digitalWrite(_enable_pin, LOW);
delayMicroseconds(1); //up to 2? JR
_digitalWrite(_enable_pin, HIGH);
delayMicroseconds(1); // enable pulse must be >450ns
_digitalWrite(_enable_pin, LOW);
delayMicroseconds(100); // commands need > 37us to settle
}
void Adafruit_RGBLCDShield::write4bits(uint8_t value) {
if (_i2cAddr != 255) {
uint16_t out = 0;
out = _i2c.readGPIOAB();
// speed up for i2c since its sluggish
for (int i = 0; i < 4; i++) {
out &= ~(1 << _data_pins[i]);
out |= ((value >> i) & 0x1) << _data_pins[i];
}
// make sure enable is low
out &= ~(1 << _enable_pin);
_i2c.writeGPIOAB(out);
// pulse enable
delayMicroseconds(1);
out |= (1 << _enable_pin);
_i2c.writeGPIOAB(out);
delayMicroseconds(1);
out &= ~(1 << _enable_pin);
_i2c.writeGPIOAB(out);
delayMicroseconds(100);
} else {
for (int i = 0; i < 4; i++) {
_pinMode(_data_pins[i], OUTPUT);
_digitalWrite(_data_pins[i], (value >> i) & 0x01);
}
pulseEnable();
}
}
Thanks,
JR
I don’t feel a 1 microsecond delay is going to have much effect between I2C transactions that are taking 180 - 270 microseconds to complete. Try doing a Wire.setSpeed() to 400 KHz or even 1.7 MHz (1700000) and see whether that has any affect. Put it before any Wire.begin() is done. I checked and the MCP23017 part Adafruit is using is 1.7 MHz capable. It may be that Arduino defaults to 400 KHz and on the photon at 100 KHz the enable is being set for too long.
Interesting … I bumped the setSpeed down to 20khz and that did not help. Maybe I should try faster, not slower.
I’ll give it a shot when I get home.
No dice, increasing the speed increases the instability.
I really have not had the time to look into this on the Photon.
Maybe now that autumn has come I may have some time to tinkker.
I can say, while we were able to get the library to work… I’m not sure that we fully understand the root cause of the issue or why that band-aid solution actually worked!
Thanks for the reply, @BulldogLowell . I looked at the section of code I highlighted above and just changed all the delay microseconds to 2. Too early to tell yet, but the display didn’t crap out overnight, which is much longer than it has gone before. The backlight did turn off, but that is probably addressable in code. @anlek maybe you want to give that a try or import my edited library from https://github.com/jrubinstein/Adafruit_RGBLCDShield and see if it works for you?