PK162-12 i2c linux odd values causing strange behaviour

[tony.mcconnell@ultra-date]

Hi,

I've got a couple of display modules (a PK162-12 and an LCD03 http://www.robot-electronics.co.uk/htm/Lcd03tech.htm).

In fact I've got another 13 PK162-12s that I haven't tested yet.

The boards are attached to the i2c bus of a Arcom VIPER SBC (an ARM PXA255). This board has 1k pull-up resistors from 3.3v to SCL and SDA.

The bus is passed through a level shifter board to raise the voltage to 5v. The board also contains an ADT7461 temperature sensor on the 3.3v bus.

There are no further pull-up resistors on the bus.

The board is running embedded Linux, with the 2.6.11-11 kernel.

I can read the registers on the ADT7461 fine (it's 22 deg C give or take 2 degrees).

Both the PK162-12 and the LCD03 work OK and show characters. However I'm having a problem in that when I display characters or send command that have odd numbered values (eg 'A', 'C', etc) I get informed by the Linux OS that writing has failed. This occurs both with the PK162-12 and the LCD03.

For example if I write the individual characters of the strings texString1 and textString2 as shown below:

char textString1[]="BADCFEHGJILKNMPORQTSVUXWZY 0123456789";
char textString2[]="ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789";

The 'write' system call fails giving a 'Connection refused' error when sending 'A', 'C', 'E', 'G', etc. The display actually does show the character, but the system call returns an error.

With the strings below:

char textString3[]="BDFHJLNPRTVXZ 02468";
char textString4[]="ACEGIKMOQSUWY 13579";

Writing all of textString3 in one go works fine, all characters are displayed.

Writing all of textString4 in one go fails with the display only showing one character 'A', and the write system call fails.

Even if you aren't running Linux, has anyone seen this kind of strange behaviour before?

[Raquel]

Hello tony,

Thank you for your post.

This problem that you encounter happens when both the PK162-12 and LCD03 are connected to your host controller? How about when only one at a time is connected?

With I2C, bit 0 is the read/write bit, this is the only thing I can think of that can be associated with odd numbered values like 'A' (0x41). Are you properly addressing the modules?

Best Regards,

[tony.mcconnell@ultra-date]

Hi Raquel,

the problem occurs when I've got the PK162-12 and the ADT7461. I can't remove the ADT7461 as its soldered onto the board. I've not attached the LCD03 and PK162-12 at the same time.

I believe I'm addressing the PK162-12 properly since I can see the characters output to the display; but then this is the first time I've used an i2c bus.

The LCD03 is 'register' driven, but exhibits the same behaviour.

Thanks

Tony

[Raquel]

Hi tony,

It sounds like the problem is on the Linux source code end. The PK162-12 is doing what it is told; it does not decipher the data it is sent, so it does not know the difference between 'B' and 'A'. Since it does display at least one 'A', this hints that it is not the module that causes the problem. Also, the fact that the LCD03 does the same thing, makes it even more point back to the code on the host controller. It'll probably be best to contact the author of the I2C driver you are using and hope that you will be able to get some answers.

A scope will give you a better idea on what is happening on the bus.

Please inform me as to what happens.

[tony.mcconnell@ultra-date]

Hi Raquel,

It's definitely something to do with the level shifter. Operations on the 3v3 side of the i2c work OK, can change the conversion rate on the ADT7461 by writing odd/even values to the register.

Operations on the 5v side fail on odd values. Actual failure appears to be no bus acknowledge is received.

When I find out what's wrong with the level shifter I'll post the results. Just in case this happens to anyone else ...

Thanks

Tony

[tony.mcconnell@ultra-date]

Hi

Hope you don't mind, but thought I'd post some more about the problems I'm having.

I

[Raquel]

Hi tony,

Does the waveform on the 5V side look the same as the 3V side? It would have been nice if you showed it as well. From the waveforms you sent, I can tell that you are sending 0xC6, then 0x00, then 0x04 for the good one, and for the bad one 0xC6, 0x00, 0x05 but then can't pull the signal low on the last bit, which means that the other end of SDA is trying to put out a high.

Another thing: I wonder if you can easily change things on your board; because I wonder if the Arcom VIPER SBC is +5V tolerant, then maybe there is no more need for the level shifters; and just pull up to +5V instead of +3V ( on SDA). Check the I2C pins of the uC.

[tony.mcconnell@ultra-date]

Hi Raquel,

the VIPER SBC is not 5v tolerant unfortunately (well, not for extended periods).

I'll try and get a trace on the 5v side. I wonder if the VIPER 1k pull-ups are too low a resistance for the other devices to pull to zero for the ACK?

Thanks

Tony

[Raquel]

Hi tony,

It is a good idea to play with the pull up resistors, since you are playing with quite a different situation than normal for your I2C (you have level shifting). But then when you send the address 0xC6, followed by 0x00, the LCD was able to ACK properly...

Can you please tell more about the level shifters you are using? I understand that the level shifter for the SCL is one-way, in that the VIPER is always output; but then the level shifter for the SDA will have to be some kind of 2 way since the LCD will have to ACK back and also output its data (control the bus via pulling low or letting go of it) when its being read.

[tony.mcconnell@ultra-date]

Hi Raquel,

the board is a prototype put together by a local electronics company. It uses an ST2378E level translator chip http://www.st.com/stonline/books/pdf/docs/9489.pdf.

Yes, the ACK situation is a bit weird. The master should release SDA after it transmits the last bit and the slave is responsible for holding SDA low for one SCL cycle. I don't understand how the slave manages to hold a released SDA low, but can't pull a high SDA to low.

It's a bit difficult for me to mess with terminating resistors as these are on the VIPER board - any more resistors I add across the bus will just reduce the overall resistance, I believe.

Thanks

Tony

[Raquel]

Hi tony,

When you write to the LCD with 0x00 and 0x04 data (the good trace), how do you know that the data gets written? Deos the cursor on the LCD03 turn off?

[tony.mcconnell@ultra-date]

Hi Raquel,

The LCD03 interprets 0x00 as the address of a register into which the 0x04 is written. The 0x04 turns off the cursor, the 0x05 (bad trace) turns on an underline cursor. The display does show the cursor being hidden and replaced.

If I write "0x42" 'B' it appears on the display without losing the ACK, if I write "0x41" 'A' it still appears on the display, but the ACK is not received at the master.

Thanks

Tony

[Raquel]

Hi tony,

The ACK for all the data you send is all low (ACK of course). So just like how the slave ACKs the address 0xC6, the register 0x00, and the even data, it should ACK the same to the odd data, because obviously, it accepts the data and action is performed accordingly.

It must be then, the master doing something funky when it sends odd data. To test this out, send a 0x41 (any odd byte - no address, no register) you should see that the 9th clock should have a high on SDA since the slave will not be acknowledging that data, check how this waveform looks like. It might have that funky thing at the 8th and 9th clock (as per the pdf you sent)

[tony.mcconnell@ultra-date]

Hi Raquel

When transmitting a ODD value onto the bus, the trace looks fine. However,
I did find this message when googling:

For a 5 volt system, a 1k pullup would be too low. In section 16.1 of the i2c spec (page 39), it says the minimum specified sink current is 3 ma.

This gives 5v/3ma = 1.67K as the lowest value you should use. For 100 KHz clock, you don't need the fastest rise time, so you could use a larger value.

If you have a 3 volt system, you could use 1K pullups. Figure 37 of the spec, below, has a graph that shows this.

http://www.semiconductors.philips.com/a ... TION_3.pdf

Maxim Semiconductor has a faq page that mentions the pullup resistor size: http://dbserv.maxim-ic.com/appnotes.cfm ... number=356

Hmm, the VIPER board has 1k pull-ups on it, so this is probably why the slave devices cannot pull 5v low enough to ACK?

Thanks

Tony

[Raquel]

Hi tony,

You said when transmitting an ODD value onto the bus, the trace looks fine..
Is the data on the 9th clock (ACK bit) high? It should be.

The slave ACKs the 0xC6 address and the 0x00 register byte; the ACK for the 0x05 data is the same (low). If it is hardware, I wonder why the slave has no problem ACKing the address and the register byte, but only has a problem with the odd value.