Matrix Orbital Corp

I'm having trouble getting I2C to work with my LK204-25, rev1.23 and an Atmel ATmega16 microcontroller.

The mega16 has built-in I2C (although they call it two-wire interface), so I'm using that facility with the sample code from the mega16 manual.

My test program just writes a start bit, the address (0x5c), and then 0x21 (should be a ! character), then a stop bit. The program delays about a second or so, and then loops back.

No matter what data I send, the display always shows the top left character of the Matrix Orbital logo from the startup screen. This happens regardless of bitrate or what data value I send. I tried sending all characters (0-255), and every value shows the garbage character. I've tried different addresses as well, and no other address displays anything.

I've tried using different pull up resistors (10k, 4k7, and the internal pull-ups on the mega16), and I get the same results.

I can't send any commands either. I tried sending 'backlight off', and the display shows two of the graphic characters. If I try to send again, only one additional character is displayed. (The backlight remains on)

Everything works smoothly over RS232.

Is there anything I have to do to enable I2C on this revision of the LK204-25? Any other ideas? I've read every post on I2C, and none were very helpful to me. Also, the link about I2C on ping.be from the manual is 404'd.

Hi Adam,

Thank you for posting on the forum.

You do not need to do any modifications on the board to communicate to the display via I2C.

Communicating to Matrix Orbital units via I2C is a little different than the standard way. The following link will describe a little bit of detail on how to communicate with the unit via I2C at http://www.lcdforums.com/forums/viewtopic.php?t=910 .

I also seen a similar issue with another processor. Please refer to http://www.lcdforums.com/forums/viewtopic.php?t=910 for detail.

I hope this information is useful to you. Keep me posted on.

Best Regards,

That link doesn't help very much.

I know all about the addressing. The addressing in the mega16 works similarly. It interprets the adddress as an 8-bit number, with the high 7 bits being the actual address, and the LSB as read/write.

The only question would be if 0x5c is the 'matrix orbital address' or the 7-bit 'real' address. I tried using 0xB8, and I get nothing on the display. My guess is that 0x5c is the 8-bit address (SLA+R/W)

I also realize that the Matrix Orbital displays don't do a proper ACK for the data, which is fine. However, the display doesn't even seem to be ACK'ing the slave address. Actually, after some debugging, I found that it returns an ACK after the first transfer, but subsequent transfers are not acknowledged.

It'd be one thing if I was getting garbage characters, but getting the same character every time, no matter what data I send seems very strange.

What character are you getting on the display?

It's the top left character of the matrix orbital logo on the startup screen.

Hi Adam,

Can you set up a program that will loop through every possible address and let me know if communication is established with the display.

I think I tried looping the addresses before. 0x5c appears to be the only address that shows anything at all. I know I tried several addresses, but I'm not sure that I looped through them all.

I'll try again this afternoon and let you know.

Bad news...

I tried looping through all the addresses, and only one character gets displayed. So that means 0x5C is the address (which would make sense, since that's what it's jumpered for).

I hooked it up to a scope to look at SCL and SDA. The clock waveform was horrible, (shark fin instead of nice square wave), but I think that's due to the capacitance of the scope probes. I turned the bitrate way down (It was dead on 100K) to about 10 or 11 K). The waveforms look better, but I stil get the same results, so it's definitely bitrate independent.

I also checked to make sure the START and STOP bits were being sent correctly. (They are)

Now I just need to look in between the START and STOP bits. : ) I'll let you know if I find anything.

Update:
Didn't find anything unusual. I did verify on the scope that the display is ACK'ing the address for the first transfer, but sending a NACK for all subsequent transfers. This shouldn't be affecting my code at all, since I'm ignoring the ACKs (or lack thereof), but it might give you guys a clue as to what's happening.

Do you guys have any verfication that your displays work with Atmel's TWI?
For now, I'm just using serial instead of I2C. Future projects will need the UART for other things, so I'd like get it working with I2C.

I ordered an I2C EEPROM, so I will be able to determine if the problem is on the AVR side or the display side.[/b]

Adam,

Keep me posted...If you would like, I can send you an example code of us bit bashing with a PIC16F877A to the display. What this code does is run a loop of I2C addresses and displays the address on the module in decimal. You can reach me at myero@matrixorbital.ca

I had the wild idea that maybe my little wall wart power supply was too wimpy to power both my development board and the display. (An easy counterpoint to this is that the display works fine with the backlight on over RS232, but I needed something new to try)

I hooked up the display via serial and I2C, and had the AVR send a 'backlight off' command over serial, then ascii 0-9 (0x30-0x39). After that, the AVR would send a 'backlight on' command so I could see what happened.

I found out more than I expected. The power supply is fine (which I figured), but I found something strange. I didn't get the regular graphic character from the logo that I had been getting, but 10 Fs ("FFFFFFFFFF").

Incidentally, F is 0x46, the last part of the backlight off command. My code only sends the backlight off command once, so the 'random' character is actually the last character received over serial. If I send a character over serial in between the I2C characters, the displayed character changes to the last character. (of course, there's an extra one displayed)

I took out the backlight commands, and just sent a ! (0x21) over serial before all the I2C stuff. I got ten !'s. If I add a clear screen (0xFE 0x58) I get X's. (0x58) It's not coming over serial, because if I change the I2C address I'm sending to, the characters don't appear.

So the characters I was seeing before were whatever was in the particluar register where received serial chars are stored in the on-board PIC.

I bet you're scratching your head on this one just as much as I am.