UCD90160: an NACK issue with a combined command

Hi

Please see my reply here. 

The NACK is from host. Do your host support clock stretching?

Hi Yihe,

How do we know this NACK is from host? The host supports clock stretching and we've tested this function in many other devices.

HI

Please provide capture of the previous command before the problem happen.

Regards

Yihe

Hi Yihe,

Customer reproduce this issue by performing below loop commands.
i2cset -y -f 8 0x34 0x03 0x54; i2cget -y -f 8 0x34 0x80; i2cset -y -f 8 0x34 0x03 0x54;

However, if they run below 2 commands alone, they can't reproduce this issue.
i2cset -y -f 8 0x34 0x03 0x54
i2cget -y -f 8 0x34 0x80

Here are more details from customer side.

• Customer can perform command i2cset -y -f 8 0x34 0x03 0x54 from COMe board and BMC board I2C masters without any error but actually the read back data was unexpected.

root@localhost:~# i2cget -y -f 8 0x34 0x03
0xff # expect 0x54

Can 0x34 register be written?

• When customer performed the command i2cget -y -f 8 0x34 0x80 from the BMC board, it failed but they got 0xff from COMe board.

Can 0x80 register be read?

Regards,
Hailiang

Hi

command 0x3 is write only and you can not perform

i2cget  -y -f 0x34 0x03 // this is invalid

0x80 command is readable. 

Regards

Yihe

Hi Yihe，

By changing i2cset -y -f 8 0x34 0x03 0x54 to i2cset -y -f 8 0x34 0x03, this issue is fixed. 

However, according to the PMBUS specification, 0x19 register capability whose bit 7 presents supporting PEC(packet error checking).  

After checking UCD device 0x19 register (value 0xb0), it supports PEC function, so we need to add an extra PEC byte as the last byte in the transaction.

Therefore, we still need to root cause this issue, please help for this.

Hi

UCD supports PEC. I need see the waveform before the failing case to understand better.

Please provide it.

Regards

Yihe

Hi Yihe,

Here are the waveforms.

Waveform 1: i2cset -y -f 8 0x34 0x03 0x54; 

Waveform 2/3: i2cget -y -f 8 0x34 0x80 (return value is 0xff); 

waveform 4: i2cset -y -f 8 0x34 0x03 0x54 (NACK); i2cset -y -f 8 0x34 0x03 0x54 (this is a retry and get ACK)

Regards,
Hailiang

Hi Yihe,

I see your reply is about the waveform of i2cget -y -f 8 0x34 0x80.  Yes, it has the stop and start signal, but I think it's caused by the NACK in the previous clock.

I wonder why there's an NACK of i2cget -y -f 8 0x34 0x80.

If I perform i2cget -y -f 8 0x34 0x80 dependently as below, it won't have such an issue. This issue only happens with the combined commands.

Regards，
Hailiang

Hi

Please see my comments

Regards

Yihe

Hi Yihe，

It seems that some comments cannot be displayed properly.

Hi

The missing comments are not important.

Please focus on the why NACK does not abort the transaction instead host continues to operate.

Regards

Yihe 

Hi

we found that reading 0x80 can sometimes return ACK but sometimes NAK.  After checking the UCD device datasheet, 0x80 register is not supported. Is that the reason why we got ACK and NAK randomly? 

Could you confirm that is fine or not?

By the way,

In the Linux PMBUS core driver, if kernel option CONFIG_DEBUG_FS is enabled, it read registers 0x7f and 0x80. 

If you can confirm above situation is fine, I'll regard it as a small limitation of PMBUS core driver.

Thanks and best regards.

Hi Yihe，

Do you think writing an unsupported command will randomly get NACKs and ACKs?

Regards，

Hailiang

Hi

I need see the waveform to understand this better.

Regards

Yihe

Hi Yihe,

What waveform do you need? Previously, a customer shared the waveform of getting NACK and ACK after writing the 0X80 command.

Getting NACK

Hailiang Zhang said:

I see your reply is about the waveform of i2cget -y -f 8 0x34 0x80.  Yes, it has the stop and start signal, but I think it's caused by the NACK in the previous clock.

Getting ACK

Hailiang Zhang said:

If I perform i2cget -y -f 8 0x34 0x80 dependently as below, it won't have such an issue. This issue only happens with the combined commands.

Thanks

Hailiang

HI

I mean waveform from 0x80 command not the 0x34.

Regards

Yihe 

Hi Yihe,

I think the 0x34 is the device address. 0x80 is the command. 

Regards,
Hailiang