I use a lot of I2C LCDs, in both 16x2 and 20x4. I recently started having a problem that really has me stumped. With any LCD, I can eventually get into a state where the LCD seems to be driving the SDA line, and the only way I can clear it is to disconnect power from the LCD. In years of using these things, I've never seen this happen, yet I can now reproduce it pretty regularly.
The question is: Does anyone know how the I2C "backpack" can possibly be put into this state? All the LCDs use either the Philips/NXP PCF8574AT or PCF8574AT (the only difference between the two is the I2C address, which is 0x38-0x3f for the AT, and 0x20-0x27 for the T). I'm driving them with I2C1 on a Due.
I don't believe there is any problem with the display itself, as it occurs with displays I've used for years with no problems. It's not the specific Due board, because I've tried several, and all act the same. I believe it's likely something in my firmware, but it's a bloody huge application (250K of object code), and I don't know where to start looking. The LCD code is only called from one place in the code, and it is not in an interrupt context (though there are LOTS of interrupt running). The LCD code has not been touched in months, but I only started seeing this problem a few weeks ago.
RayLivingston:
I use a lot of I2C LCDs, in both 16x2 and 20x4. I recently started having a problem that really has me stumped. With any LCD, I can eventually get into a state where the LCD seems to be driving the SDA line, and the only way I can clear it is to disconnect power from the LCD. In years of using these things, I've never seen this happen, yet I can now reproduce it pretty regularly.
The question is: Does anyone know how the I2C "backpack" can possibly be put into this state? All the LCDs use either the Philips/NXP PCF8574AT or PCF8574AT (the only difference between the two is the I2C address, which is 0x38-0x3f for the AT, and 0x20-0x27 for the T). I'm driving them with I2C1 on a Due.
I don't believe there is any problem with the display itself, as it occurs with displays I've used for years with no problems. It's not the specific Due board, because I've tried several, and all act the same. I believe it's likely something in my firmware, but it's a bloody huge application (250K of object code), and I don't know where to start looking. The LCD code is only called from one place in the code, and it is not in an interrupt context (though there are LOTS of interrupt running). The LCD code has not been touched in months, but I only started seeing this problem a few weeks ago.
Any ideas?
Regards,
Ray L.
Majority of LCD modules used by hobbyists are "hardwired" for R/W signal set to "write", however PCF chip is bidirectional.
Any possibility that the common I2C library has code to enable "read" and somewhere in your code it is accidentally enabled?
I have used the read mode to retrieve data from the LCD, but never while using I2C "backpack", only directly.
I would try to write to I2C pack to set the R/W (back) to write to see if the SDA goes back to "write from host" again before turning off the LCD power.
Of course you know that Hitachi power-up sequence reset lots of stuff and probably also reads the input to R/W pin during such reset (or later?).
Minor OT question - how does PCF chip interacts with LCD while it is being powered up.
Vaclav:
Majority of LCD modules used by hobbyists are "hardwired" for R/W signal set to "write", however PCF chip is bidirectional.
Any possibility that the common I2C library has code to enable "read" and somewhere in your code it is accidentally enabled?
I have used the read mode to retrieve data from the LCD, but never while using I2C "backpack", only directly.
I would try to write to I2C pack to set the R/W (back) to write to see if the SDA goes back to "write from host" again before turning off the LCD power.
Of course you know that Hitachi power-up sequence reset lots of stuff and probably also reads the input to R/W pin during such reset (or later?).
Minor OT question - how does PCF chip interacts with LCD while it is being powered up.
There are no read operations anywhere in the library - it's entirely write-only.
Usually devices get put into that state due to your doing something they don't like on the I2C bus.
Well, yeah. But WHAT? What could I possibly be doing that could cause the LCD it pull the SDA pin permanently low? Seems to me that should be pretty much impossible, unless there is a bug in the I2C I/F of the NXP Chip.
Funny thing is, I spent many years designing chips, and used many I2C interfaces. Philips/NXP designed I2C back in the '70s. By far, the WORST I2C logic I ever saw was in a chip marketed by Philips/NXP. It had several really blatant, very serious bugs, and I had to explain to their engineers what they had done wrong. I knew exactly what they had done, without seeing their logic, by the way it behaved. After denying, for months, the problem even existed, they finally looked into it, and found exactly what I had described to them. They pulled the chip off the market shorlty after that.
I have a theory as to what is happening: I suspect noise and/or marginal signal levels are making the NXP chip think a read is being requested when it's really not. This is the only way I can see that it can drive the SDA line for more than one clock cycle. Once in this state, since the Master (i.e. - Due) did not actually request a read, the only way to recover is either reset the NXP chip, or send at least 9 SCL pulses to let the NXP chip complete the read and release the SDA line.
I see no obvious way to make the TWI hardware do the clock togging, so I think it has to be done in software. The Wire pins are assigned Arduino digital I/O pin numbers, but the Wire1 pins appear not to be so defined. They are, however, mapped to SAM pins 9 and 71, which are mapped to Arduino pins 70 and 71. Oddly, Wire is mapped to TWI1, while Wire1 is mapped to TWI0. Anyway, I should be able to use digitalWrite(71) to toggle SCL1 once I detect this lockup has happened, which will let me recover without a power cycle.
While this gives me a way to recover from the hang, I still have to figure out why this is happening at all. Next step is looking carefully at signal levels, and making sure they meet the requirements for both the SAM and the NXP chip.