You are here

I2C Slave not respecting NACK and STOP? | Cypress Semiconductor

I2C Slave not respecting NACK and STOP?

Summary: 4 Replies, Latest post by SpiderKenny on 28 Jun 2013 02:39 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
user_189995688's picture
138 posts

I have an I2C Component in my design, using Fixed Function block at 100kHz speed.
It is set in slave mode and initialized with a buffer of 250 Bytes.
The bytes in the buffer are all initialized with the values 0 to 249 to make debugging easier.

When my master (an external processor) READS from the slave it reads only 240 bytes from the buffer. The reads are all present and correct, and the master NACKs the last byte and performs a proper I2C Stop sequence.

In my Creator project I poll using I2C_SlaveStatus() and look for the I2C_SSTAT_RD_CMPLT flag.
In my handler when I see I2C_SSTAT_RD_CMPLT I reset the buffer using I2C_SlaveClearReadBuf();

The problem is that this flag doesn't get set after each read from the master, it only gets set after every 4 or 5 reads, and the slave continues reading through the buffer instead. (Returning 0xff once it overflows).

I have used a logic analyzer to look at the data and it decodes it as valid I2C with the correct timings and sequences.
Attached are 2 screen shots from my logic analyzer showing the end of the 1st 240 byte read and the start of the next read (which should have reset to the start of the buffer).

Any ideas as to why this should be behaving like this?
I cannot attach the whole project as large parts of it are under NDA to my client.
I will try to make a smaller project with just the I2C to show the problem.

user_1377889's picture
9241 posts

This sounds very strange and althoug I've done some designs with I2C I've never seen something similar.

I'm afraid you have to break down your project to the pure I2C-communication.

Ah... try to use I2C_SlaveClearReadStatus() instead



user_189995688's picture
138 posts

 Hi Bob


Thanks for the reply.

Turns out it was the slew rate on the microchip PIC that the PSoC was trying to chat to. In the logic analyzer it looked great, but on the oscilloscope I soon saw a problem. The PSoC wasn't actually seeing the stop sequence. What looked nice and square on the logic analyzer were actually well rounded peaks on the 'scope. The pull ups are 4.7K and cannot be changed at this time.

Anyway, what I did was switch them round - the PSoC is now master, the PIC is slave, so the PSoC is driving the bus and it works great. I've even been able to get better throughput. Clock stretching works a treat also! Ka-ching!

This particular board has loads of I2C on it - 4 Audio processors, 2 NVRAM and the PIC all on I2C buses. The PIC does Ethernet offloading for me. Since I2C SLAVE on the pic has to be interrupt driven it even makes the ethernet throughput a bit better - we are not blocked while doing I2C writes and reads for as long as we were in master mode.


user_78878863's picture
2551 posts

In case you want/need to swap master and slave again, you might use a I2C bus buffer to get better signals. E.g. one from Linear Technologies:

user_189995688's picture
138 posts

 Thanks thats a good bit of advice.

In this case the board already exists (in their 1,000's) so a change to the PCB was not possible.

Log in to post new comments.