I2C Nacking Address unless sample project is used

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
KevinE
Level 3
Level 3
10 sign-ins 10 replies posted 5 sign-ins

I am working with CY8CKIT-059 and need help discerning the differences between my custom project and one of the projects provided under "Find code example..." dialogue. 

I have a device that is acting as an I2C Master and is connected to the CY8CKIT-059 acting as an I2C slave. 

If I use the sample project: "DelSig_I2CS" I can  successfully perform a Write operation from the external device and the CY8CKIT-059 running the sample project can successfully ACK the address and receive the 2 bytes being written to it.  No issues here, I2C slave is working as expected. 

However when I generate a new project, and reuse the code from the sample I2C project and set up the I2C peripheral in the same way the sample project has it configured, the CY8CKIT-059 NACKs the address and no data is received. 

Perhaps I am not setting up the custom project in the same way, but I think I have checked everything. 

What are some probable causes as to why the CY8CKIT-059 would NACK when being addressed?

I will attach both projects: DelSig_I2CS is working just fine with no issues and "Roadrunner2_Eval which I believe is setup in the same way. 

In general, both projects have the same code:

At this point Delays are being used to have a line of code to attach breakpoints to. 

I2CS_Start();

/* Set up slave read data buffer */
I2CS_SlaveInitReadBuf((uint8 *) sample_segment, RD_BUFFER_SIZE);
I2CS_SlaveInitWriteBuf((uint8 *) sample_segment, RD_BUFFER_SIZE);

/* Enable global interrupts - needed for I2C operation */
CyGlobalIntEnable;

Enter Main Loop:

/* Check if the slave buffer has been Written */
if(I2CM_SlaveStatus() & I2CM_SSTAT_WR_CMPLT)
{
     byteCount = I2CM_SlaveGetWriteBufSize();
     I2CM_SlaveClearWriteStatus();
     I2CM_SlaveClearWriteBuf();

/* If both bytes of the read buffer have been read */
if(byteCount == I2C_BUFFER_SIZE)
{
     CyDelay(1);
     return 1;
}
else /* Wrong number of bytes read - place error handling code here */
{
     CyDelay(1);
}


/* Check if the slave buffer has been read */
if(I2CM_SlaveStatus() & I2CM_SSTAT_RD_CMPLT)
{
     byteCount = I2CM_SlaveGetReadBufSize();
     I2CM_SlaveClearReadStatus();
     I2CM_SlaveClearReadBuf();

/* If both bytes of the read buffer have been read */
if(byteCount == I2C_BUFFER_SIZE)
{
     CyDelay(1);
     return 1;
}
else /* Wrong number of bytes read - place error handling code here */
{
     CyDelay(1);
}




 

0 Likes
1 Solution
KevinE
Level 3
Level 3
10 sign-ins 10 replies posted 5 sign-ins

So oddly enough, I think I may have found the issue. 

Looking at the clock scheme, I had arbitrarily set the master clock to be 67MHz

In doing so, I noticed the I2C schematic configuration shows 99.7 kbps when I have the speed set to 100 under data rate. 

KevinE_0-1639089680191.png

 


I messed around with the clock speed a bit and finally ended up on 64MHz

Now when I look at the I2C schematic configuration, setting 100 to the data rate allows the actual data rate to read at 100. 

KevinE_1-1639089749403.png



And this appears to have solved my issue. My guess is that when using "odd" clock values, it causes the I2C peripheral to have a "non - standard" speed and maybe even lends to the need for the extended ACK wait time. 

View solution in original post

0 Likes
8 Replies