We do not see any issues with the code. Can you share the following?
1. PSoC Creator project archive file. We would like to see the component settings.
2. Bus Transaction while the issue occurs. Is the PSoC device NACKing the read?
A minor comment. Instead of using the internal global variable I2C_curStatus , you can use the I2C_GetActivity() directly to return the status and clear the status in a single function.
Thank you for taking a look at my issue. I have attached the archive file. For the bus transaction, is this data displayed anywhere through the PSoC creator software, or are you looking for an oscilloscope readout?
I have tried running this program through the BridgeController and I have noticed that Read commands (r 8 x p) will read the value in the buffer, but further write commands will no longer change the LED brightness. The signal is still acknowledging, however. See picture. I send three "increase" commands, followed by a "read", then another "increase". After the read the LED no longer increases in brightness. See attached photo.
The issue is with the if condition that is checking the status of EZI2C activity. The EZI2C status sets multiple bits based on the different events. For example, I2C_STATUS_WRITE1 and I2C_STATUS_ERR can happen at the same time. Therefore the right way to identify different events is to check for each bit in the return of I2C_GetActivity()
if((I2C_GetActivity() & I2C_STATUS_WRITE1) != 0)
//write event occurred.
if((I2C_GetActivity() & I2C_STATUS_ERR ) != 0)
//I2C error occurred.
What was happening in your case?
When a read event occurred, the read bit in the status was set. This read bit is set as long as the I2C_GetActivity() is called. In your firmware you are never checking for this bit using I2C_GetActivity(), therefore it is never cleared. When a write event happens, both the read and write bit will be set and this is why the current status variable would never be I2C_STATUS_WRITE1 alone. That is why you should check for individual bits by using the snippet above. Please avoid using internal global variables such as I2C_curStatus. Use the wrapper function (I2C_GetActivity() for more reliability.
The other thing to do is use the Bridge Control panel to sends commands while acting as an I2C master to make sure that you understand the total behavior of the slave.
I have written extensively about using BCP on my website https://iotexpert.com/?s=bridge+control+panel