Hello All - The CP2112 works beautifully in my application involving a Smart Battery and Smart Battery Charger, with one exception. First, I am using the interface specification (AN495), and my SMBus Configuration is set to its defaults, except the Auto Send Read is enabled. So no timeouts, and no limits on retries. Communicating with these SMBus devices consists of sending a Data Write Read Request and then handling the Data Read Response interrupt, etc. What I notice is that occasionally, a command to an SMBus device does not return a response for over a second, and the way I have been getting past this is to simply timeout after waiting for 1 second, then send a Cancel Transfer command (0x17) and then continue on, no problem. But further investigation on reading the Transfer Status register immediately after the 1-second timeout reveals 'Complete with error' (Status0: 0x03), 'Arbitration Lost' (Status1: 0x02), 1 retry (Status 2: 1), and 0 received bytes (Status3: 0). So the question is, why just one retry if 'Retry Time' is set to 'No Limit'? I checked the SMBus with a logic analyzer and during these events the SMBCLK line never reaches the clock low timeout of 25ms (SMBus Spec V3.1), so all devices seem to be on good behavior. Any insight would be greatly appreciated. Thanks!
Could you explain more about in which scenario this issue happens:
In SMbus system, arbitration can be lost for various reasons: another device on the bus illegally tampers with SDA or SCL, or environmental noise is enough to cause false rising or falling edges.
Normally, in case of arbitration lost happens, the CP2112 ignores the erroneous data transmission, and continues with the next transmission.
Hello Ha - Not including the SMBus Host (CP2112), there are two devices, each of which can be a master and a slave. These are the Smart Battery Charger and the Smart Battery itself. I've attached a diagram from the Smart Battery Spec that represents our SMBus configuration. I should note that if I remove the charger from the bus, the arbitration lost event does not occur.
When you say "continues with the next transmission", to me this is not the same as trying the *same* command again and again until it succeeds, which is what "no limit on retries" means, I believe. Instead, what I see is that when 'arbitration lost' occurs, the CP2112 tries the same command only once more and then it seems to wait indefinitely for a Data Read Response interrupt, I wait for a second and then issue the transfer status which tells me that arbitration was lost and the number of retries was 1. Have I misunderstood your meaning of "continues with the next transmission"?
CP2112 has control register to indicate status as well as to send SMBus START and STOP signal. When arbitration lost occurs, there are cases where a transfer can be aborted (failed transfer will not be rescheduled, i.e: retry once).
1) Lost arbitration while attempting a repeated START and start bit in control register set to '0'
2) Lost arbitration due to a detected STOP and start bit of control register set to '0'
The phenomenon you observe seems to correspond to case 1.
If possible, could you provide oscilloscope /logic analyzer data of SMBus signal?
Packet Error Checking is only optional in SMBus Specification, CP2112 doesn't implement it.
Thank you Ha. I should have scope/analyzer data to share by end of this week.