Announcements

Equip yourself to optimize PSoc4 MCUs for Evs at the EV Webinar. Click here to register.

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

PSoC™ 4 Forum Discussions

MaMi_1205306
Level 7
Level 7
500 replies posted 50 solutions authored 25 likes received

Dear Sirs and Madams,

We are using the I2CHW Slave component of PSoC4S.

I2C Master and I2C communication is not working properly.

(a)

I2C HW component version : v40

I2C Address : 8

Data rate : 100kbps

I2C Master : Other CPU on the host side

This is the waveform at the time of Master transmission.

The slave does not return an ACK.

pastedImage_0.png

Waveform when I2C Master is changed to PC emulator and tried

(b)

I2C HW component version : v40

I2C Address : 8

Data rate : 100kbps

I2C Master : PC emulator

Delayed fall of ACK, delayed SCL.

However, the communication is successful.

pastedImage_1.png

Continuing from the continuous waveform above,

An ACK is output immediately on the data line.

pastedImage_4.png

Is there something wrong with the usage of I2CHW in PSoC4S?

"Byte mode”, "Accept General call address", "Enable wakeup from Deep Sleep Mode" are not checked.

Do you know how to get around this problem?

Regards,

0 Likes
1 Solution

Omori-san,

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.

Thank you,

View solution in original post

0 Likes
8 Replies
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi MaMi_1205306​,

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?

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi MaMi_1205306,

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.)

Thanks

Omoi

0 Likes

Bragadeesh-san,

Omoi-san,

(1)

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.

(MN704-00011-2v0-J p624)

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.

(2)

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.

Regards,

0 Likes

Hi MaMi_1205306,

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)

 I2C_Write.PNG

  • EZ-I2C Write Access with stretch enable (The master is a BCP on PC)

 EZI2C_Write.PNG

When disabled, clock stretch will not occur

  • EZ-I2C Write Access with stretch disable

 EZI2C_Write_Auto.PNG

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

 I2C_Write_Auto.PNG

If you use this setting, please test it before using it.

Thanks

Omoi

Hi, All

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)

[NG]

I2C Master : MB96F6B6R <=>  I2C Slave : PSoC4S "I2CHW"

I2C Master : MB96F6B6R <=>  I2C Slave : PSoC4S "EZI2C"

[OK]

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.

Regards,

0 Likes
HiOm_1802421
Level 5
Level 5
50 replies posted 50 questions asked 25 replies posted

Hi MaMi_1205306,

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 ...)

Regards,

Omoi

0 Likes

Omori-san,

Thank you for your great support.

Send a pseudo-address signal to my PSoC4S

ACK was returned without any problem.

pastedImage_5.png

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.

Regards,

0 Likes

Omori-san,

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.

Thank you,

0 Likes