1. Does your master device support clock stretching?
2. Since i2c operation is based on interrupts, can you ensure that i2c has the highest priority so that clock stretching doesn't happen?
When an I2C write is performed from the master, the I2C slave generates an interrupt when the slave addresses match.
In I2C ISR, it judges whether it is Read or Write, calculates the remaining amount of the buffer, and returns the first ACK.
The clock stretch continues until this process is completed. (First waveform of b)
Therefore, I2C interrupts should have high priority.
The data ACK is automatically processed until the RX_FIFO is full because the Auto data ACK is set in the ISR.
So the data ACK is returned immediately. (Last waveform of b)
If the host CPU does not support clock stretching, consider using EZ-I2C with clock stretching disabled.
(It needs to change the host's I2C protocol to match EZ-I2C.)
The master device is MB96F6B6R.
With reference to the hardware manual, there was a sentence that clock stretch was not supported when CLKP1 was 6MHz or higher.
This time, I am using it with CLKP1 = 4MHz setting.
The bit rate is assumed to be 100kbps.
・ CLKMC = 8MHz
・ CLKPLL = CLKMC 2 multiplication
・ CLKS1 = CLKPLL
・ CLKP1 = CLKS1 / 4 = 4MHz
・ ICCR1 NSF = 1, CS4: 0 = 2
→ SCL frequency = 4MHz / 2 * 12 + 17 = 97.56kHz
Is clock stretching effective in this case?
From the operation, it seems that it does not support clock stretch.
The interrupt priority setting of PSOC4 was 3.
I tried changing the priority to the highest 0, but there is no change in behavior. (SCL stretch occurs when connected to a PC).
I have many opportunities to use EZI2C and have little experience with I2CHW.
In summary, is the following understanding correct?
If the I2C Master does not support clock stretching
EZI2C(not use clock stretching) is the only component that uses I2C slave in PSoC4.
I2C HW components cannot be supported.
If the higher priority has no effect, it is not affected by other process.
This is probably due to the ISR processing speed.
I checked the waveforms of I2CHW and EZ-I2C.
Even if you are using EZ-I2C, if clock stretching is enabled, the time from receiving a Slave Address to returning an ACK is about the same.
- I2CHW Write Access (The master is a BCP on PC)
- EZ-I2C Write Access with stretch enable (The master is a BCP on PC)
When disabled, clock stretch will not occur
- EZ-I2C Write Access with stretch disable
I2CHW can't disable clock stretch with component option.
But I2CHW can set the Slave Address Ack to auto-send by setting the following register.
SCB_I2C_CTRL_REG | = SCB_I2C_CTRL_S_READY_ADDR_ACK;
#define WR_BUFFER_SIZE (8u) #define RD_BUFFER_SIZE (8u) uint8 SlaveWriteBuf[WR_BUFFER_SIZE]; uint8 SlaveReadBuf[RD_BUFFER_SIZE]; I2CS_Start(); I2CS_I2CSlaveInitWriteBuf(SlaveWriteBuf, WR_BUFFER_SIZE); I2CS_I2CSlaveInitReadBuf(SlaveReadBuf, RD_BUFFER_SIZE); /* Auto-ACk*/ I2CS_I2C_CTRL_REG |= I2CS_I2C_CTRL_S_READY_ADDR_ACK;
With this setting, Ack is returned immediately like Auto Data Ack, so stretch does not occur.
- I2CHW Write Access with S_READY_ADDR_ACK
If you use this setting, please test it before using it.
Thank you for your great support.
Changing the I2CHW component to an EZI2C component did not change the situation.
・ Uses EzI2C
・ Disable clock stretch
・ EzI2C interrupt priority 0 (High priority)
I2C Master : MB96F6B6R <=> I2C Slave : PSoC4S "I2CHW"
I2C Master : MB96F6B6R <=> I2C Slave : PSoC4S "EZI2C"
I2C Master : PC Emulator <=> I2C Slave : PSoC4S "I2CHW"
I2C Master : PC Emulator <=> I2C Slave : PSoC4S "EZI2C"
I2C Master : MB96F6B6R <=> I2C Slave : PSoC1 CY8C22345-24PVXA
I don't understand the difference between PSoC1 and PSoC4S due to I2C Slave.
I checked the I2C application note of PSoC1.(AN50987)
"Clock Stretching and Interrupt Latency" chapter has the following description:
PSoC1 devices will stretch the clock a majority of the time for I2C bus speeds of 100 kHz or greater.
The ISR code in the EzI2Cs and I2CHW UMs contain 150 to 300 CPU instruction cycles.
With a 24-MHz CPU clock, the ISR takes approximately 6 to 13μs to execute.
The SCL line is released at the end of the ISR code.
According to this description, PSoC1 seems to have clock stretch as well as PSoC4.
It doesn't seem to make much difference in I2C functionality between I2C of PSoC1 and PSoC4.
I recommend comparing the waveforms of PSoC1 and PSoC4 and checking the error status of MB96F6B6R.
(I think the difference in waveform is just the clock stretch of each byte ...)
Thank you for your great support.
Send a pseudo-address signal to my PSoC4S
ACK was returned without any problem.
I think that it's probably a problem that depends on the environment you're evaluating.
In an environment where problems occur, interrupt delays are unlikely because problems occur even if the contents of main.c are emptied.
In other words, it is estimated that the address signal cannot be recognized by PSoC4S in the hardware environment where the problematic PSoC4S is installed.
Make sure to check the evaluation environment.
I will confirm for the environment and report any updates.
I have found a problem and will report it.
It used XRES pin of PSoC to reset the I2C bus.
The XRES pin of PSoC1 is high active with an internal pull-down.
Therefore, XRES was fixed to low on the I2C Master side.
However, the XRES pin of PSoC4S is low active with an internal pull-up.
Therefore, XRES remained low and the reset was not released.
PSoC4S was not able to recognize the I2C address.
Since the PC emulator does not use the XRES terminal, it seems that communication was possible normally.
Care must be taken when replacing PSoC 1 that uses the XRES pin.