Matrix Orbital Corp

Hi Raquel. Nope, we did not change the slave before, and the reset pins are both jumped during the testing and scope capturing. The slave address we're using is 0x50.

Thanks.

Yu-Chen Shih

Hmm, I can not make why the display would not ACK. Is it possible for a picture of the back of the display?

Hi Raquel. Here's the pictures of the PCB board behind the LCD. Hope you can find the problem soon.





Thanks.

Yu-Chen Shih

Your board looks good. Do you have the SCL and SDA lines right on pins 2 and 3 of the connector? Please see figure 8 of this
manual

I am really bothered as well as to why this display does not ACK, do you have another display you can try?

Oh, I looked at your waveforms again, and your START looks awefully close to SCL going low. Please see page 142 (START) of the datasheet

Hi Raquel. My friend changed the codes a bit, and right now the LCD is responding with ACKs and we are sending data over. However, they are not displayed on the LCD.

Also, instead of 0x50, my friend used 0xA0, which is 0x50 shifted by one bit and the LCD ACKs. He also ued idleI2C() to produce the timing we wanted.

We had the code set up like this, and everything sends:

unsigned char I2CBUFF[6]={0xA0,0xFE,0x70,0x0A,0x0A,0x00};

StartI2C();
IdleI2C();
WriteI2C(I2CBUFF[0]);
IdleI2C();
WriteI2C(I2CBUFF[1]);
IdleI2C();
WriteI2C(I2CBUFF[2]);
IdleI2C();
WriteI2C(I2CBUFF[3]);
IdleI2C();
WriteI2C(I2CBUFF[4]);
StopI2C();

The newest scope capture is shown below. It only shows the start of the data transmission, but all of the bytes we want to send are sent:



The problem I guess right now is that the pixel we want to display on the screen isn't been displayed. I hope we can get this problem solved soon.

Thanks.

Yu-Chen Shih

Hello,

With the last capture posted, the display still does not ACK. ACK is a low on the 9th clock pulse. If you look at your capture, the 9th clock has a high which is a NAK (not ACK). Please try again the 0x50 address.

It is good to see that START is now defined very well, none of the high frequency clock pulses as per the other captures, and the low going SDA happens while SCL is still high.

Hello,

I was wondering if you did solve the problem. We got the same problem here with I2C... The display just doesn't ACK!

Our scope gives us the same output as above.

We have a different board. VK204-25 rev 2.0.

• Jumpers etc are connected like indicated in the manual. We have measured the I2C signals going into the ATMega chip.
  We used the default settings jumper
  Sending to address 0x50

Hi guys. After testing to making sure that things work, we finally came up with the code for C18 that successfully sends data to the LCD via I2C. The code is listed below:

#include "p18f252.h"
#include "i2c.h"
#include <stdlib.h>

#pragma config WDT = OFF
#pragma config OSC = HS

unsigned char I2CBUFF[6]={0x50,0xFE,0x70,0x0A,0x0A,0x00};

void main(void)
{
VisualInitialization();


OpenI2C(MASTER, SLEW_OFF);// Initialize I2C module
SSPADD = 9; //set baud rate to be Fosc/(4*(SSPADD+1)) kHz on Fosc =
4 MHz


StartI2C();
IdleI2C();
putsI2C(I2CBUFF);
StopI2C();

while(1) {}

}

The thing we did to solve the problem is adding adding an idle function right after the start function. We have also modified our putsI2C function to accept 0x00 as an input instead of having to end each array with the null value.

Thanks Raquel, for your help for these past few days.

As for bsecker, I'm not too sure what you're programming with, but if you have something similar to our idleI2C function that adds an idle state or something, you can try that out and see if it fixes your problem.

Thanks all.

Yu-Chen Shih

Hello Yu-Chen Shih,

I am happy to hear that you have solved your problem. I hope that bsecker will find the solution for his problem as well.

What we find with working with I2C: Make sure you follow the datasheet for your microcontroller. Different microcontrollers have different I2C features, also different compilers also offer different libraries. One needs to make sure that the I2C specs are followed. We have tested the displays for I2C, and many customers have developed I2C master implementation on their own, and things are working fine. But of course, I need to mention there have been quirks on I2C implementatino on our end. Please see the PCN sectionthat might apply to you.

Thanks,