• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

CFA533 I2C Intermittently Working


New member

We are using the I2C CFA533 and while we have it "working" we are running into some problems that the datasheet isn't too clear about so hopeuflly you can help us.

We are running the device off 5V and 5V I2c with 4K pullups on both the clock and data line. We generate the Clock via an FPGA, and its fastest setting is 60 kHz.

Basically what we are seeing is that the packets we send down don't always get properly handled. Basically it might take us 2 or 3 times to send the "clear LCD" command before it works. So we know the packet is "right" but it isn't always getting there properly. In looking on the scope it appears that the LCD is NACKing us at various times during our transfer of the data packet. When it doesn't happen, the command is processed and the action performed.


Our questions....

Do we have to read the read buffer after sending a command packet? Is this a requirement, or just a way to check that the packet was actually properly sent.

The datasheet says that a NACK can occur "upon receiving the last byte for which storage is available". What size is the write buffer and how could a 4 byte packet like "clear lcd" actually over flow it.

Is there a way to flush / clear this buffer?

As I mentioned before our clock is roughly 60 kHz. The datasheet says 50 kHz or 100kHz. Is this an absolute requirement, or does the LCD not care as long as the clock is less than 100 kHz??

I think that is all the questions I have right now. We have an aardvark on order to try that out, but I was hoping you might have some insight / clarifications to the datasheet.


Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

CF Tech

It is not a requirement to read the return buffer before sending the next command.

The buffer is big enough to take a command 31 with 16 characters (total payload of 18 bytes), so the clear LCD payload of 0 bytes should not be an issue.

The buffer clears/resets once a command is executed. It is not a ring buffer--think of it as a linear buffer that is reset to index 0 at the I2C START.

The I2C speed should not be critical. Is your I2C master hardware or a software implementation?

About the only weird thing in the I2C for the 533 is that it needs time to process the commands once you send them over. As a test, try spacing your commands by 250mS and see if none are dropped then.
USB LCD Displays - Graphic and Character LCDs with a Keypad


New member
Thank you for the reply. I will try spacing out the commands to see if that makes a difference.

Our I2C implementation is a hardware one inside an FPGA so we can varying all the parameters if necessary. The code itself is over 4 years old and has been tested on many different I2C devices. We are just curious if there is some feature we don't currently support that we need to.

Along those lines I wanted to ask if you support I2C clock stretching?

CF Tech

In theory the I2C in the CFA-533 is a full slave hardware implementation, and should support clock stretching. I do not know if the application inside the CFA-533 processor ever does stretch the clock, but I assume it could.


New member
CF Tech,

Thank you again for your help. I believe that we have it working now. Here is what we found.

1. Yes we needed to pause 250mS to 500 mS between commands. That was one problem.

2. The CFA-533 does appear to do clock stretching. Our code tristates the clock and only drives it low. After we send the 8 bits of data, we release the clock to go high and then drive low one more time for the "ACK". Our code was hard coded for this time wise and didn't support clock stretching where the CFA 533 would keep the clock low, missing the 9th clock transition, and the data was still high at the point in time where we were sampling it, so it appeared to us as a "NACK" not an "ACK". If we had just waiting another 20 mS or so we would have been fine and this is why sometimes it was working cuz the CFA533 must release it earlier sometimes.

Thank you so much for your help!

CF Tech

The 250 mS was only a debug value. Most commands take much less time than that.

The next rev of the data sheet will have maximum command execution times for each command. Most should complete very quickly. If you want to e-mail support@crystalfontz.com and request the CFA-533 I2C command timings, they can send you a table.