PK162-12 i2c linux odd values causing strange behaviour

[tony.mcconnell@ultra-date]

Hi Raquel,

sorry, I must have been confused by what you asked.

I transmitted an odd byte onto the bus that wasn't acknowledged since it wasn't recognised by any slave. The waveform for that looked ok, so the master isn't sending strange stuff onto the bus.

I have got some traces in excel (managed to get an excel plugin for my scope) which show the 5v and 3v3 side but these are at work; I can post these on monday if you are interested.

Basically, they show a similar form on both sides; the 5v side shows a much greater drop to zero on acknowledge than the 3v3 side shows.

I think I'll try using one of the Phillips level translator/buffers http://www.semiconductors.philips.com/pip/PCA9512D.html instead of the ST2378E if I can get hold of one.

There's also an application note by Phillips that specifically mentions bus level translation albeit briefly: http://www.semiconductors.philips.com/a ... 7011_1.pdf

Thanks

Tony

[Raquel]

Hi tony,

How is your project, any progress?

[tony.mcconnell@ultra-date]

Hi Raquel,

no progress yet. I'm waiting for the postman to deliver some Phillips buffer and translation chips. Hopefully will have some conclusions close of play Wednesday.

I *will* remember to post the scope traces tomorrow.

Thanks

Tony

[tony.mcconnell@ultra-date]

Hi Raquel,

Trace as promised. Trace is of 0xc6 0x00 0x05

Thanks

Tony

[Raquel]

Hi tony,

The waveform on the 5V side will pass the test on your I2C, such that the last bit will not register a high at all. Its the 3.3V waveform that screws the translation and therefore it is understandable that Linux will complain that there is a NAK though there should have been an ACK (and there is on the 5V side). So then the level translation has something to do with this.

Please let me know how the Philips part turns out. It'll be good for people out there who have the same system as yours (mixed 3.3V and 5V).

[tony.mcconnell@ultra-date]

Hello,

I have ended up using a TI PCA9306, a dual bidirectional level translator, which also serves to isolate the capacitance of the 3v3 and 5v sides. That is, it's possible to have another 400pF on the 5v side which can only be a good thing.

This successfully translates the ACK pull-down on the 5v to the 3v side.

I think that the ST2378E problem may be due to the fact that it's an 8 channel device and the unused channels may have to be grounded - they are floating at the mo. This upsets some of these chips, apparently. I'll try that just to see if it corrects the problem - grounding of the unused channels isn't mentioned in the spec sheet for it though but maybe that's because it's supposed to be obvious?

The problem may not be apparent on the PCA9306 as it's a 2 channel device and both are used ...

Anyway, I can now display ODD characters as well as EVEN ones - very useful.

There is another way of shifting that uses a couple of MOSFETs described in the Philips application note:

http://www.google.com/url?sa=D&q=http:/ ... n97055.pdf

This is quite an easy thing to produce on a bit of stripboard, and also works with the PK162-12.

I'm now having trouble with another device that contains an embedded ST24C64-W EEPROM (2.7-5.5v operating range). This cannot pull down on either the 5v or 3v side correctly for ACK.

Removing the EEPROM from the device and attaching directly to either 3v or 5v allows me to read / write to it correctly - so the EEPROM functions correctly.

The embedded device contains in-series 1k resistors on the SCL and SDA lines, as well as 10k pull up resistors to its supply voltage. Maybe the extra pull-ups are pushing the current above the amount it can sink?

The translator I'm using converts SCL/SDA at 3.3v 3mA (3.3v 1k pull-ups) to 5v 3mA (5v 1k8 pull-ups).

Thanks

Tony