t(TIMEOUT) specification for UCD9240 says 35us

Yes, both the UCD9220 and UCD9240 datasheets are incorrect in the specification of the t(timeout) as 35us max, you are correct that it should be 35ms.

I will have this added to the errata sheet for these devices, the newer controllers have already been corrected (not sure why it wasn't flowed back to the UCD9220/40).

Is there a particular reason you are using the UCD9240 over the UCD9246 or UCD9248?

Thanks for confirming this Brad. Only reason for the 9240 is that it one of our older boards; the newer boards are using the 9248.

Now if you don't mind I rather need to dig further into this and ask you for further confirmation or guidance relating to TIMEOUT. I am able to communicate reliably with the 9240 and 9248 devices but I need to consider how to recover from a situation in which my PMBus master has been forced to truncate a transaction.

In my experiment I have emulated this by starting a read PAGE command but suddenly stopping after I have read the 3rd bit of the PAGE register. You will appreciate that this bit has the value '0' and hence at the point of stopping the 9240 is activley driving the DATA line Low. My master releases both CLK and DATA at its end of the bus and as such the CLK line is observed (on a scope) to be at '1' but DATA is firmly held Low by the 9240.

I then get the master to drive CLK Low for 35ms (again seen on the scope and duration confirmed) but the 9240 is not releasing the DATA line which therefore remains Low. Of course this makes it impossible to communicate with anything attached to the PMBus let alone the specific 9240. I had expected to see the 9240 release the DATA line some point after 25ms but no later than 35ms to be compliant with the SMBus specification.

However, as I played about some more I found that I could get the DATA line to go High.... From the emulated truncation point I apply a 35ms Low pulse to CLK but DATA=0 (as described above). I then apply a second 35ms Low pulse to CLK but again DATA=0. Then as I apply a third Low pulse to CLK the DATA line almost immediately goes High.

With the DATA line is available to me again I ask the 9240 for its DEVICE_ID but it doesn't respond. But when I ask it for a second time it does and everything is back to normal.

One way or another TIMEOUT doesn't seem to be as direct or easy as I was expecting from reading the SMBus specification. Whilst it is nice to have managed to 'unlock' my PMBus during my experiments I'm not feeling very comfortable because my scheme may only work given the specific nature of my predictable truncation test.  I would be very grateful if you could tell me the exact rules that the TI devices (not just 9240) implement with regards to TIMEOUT and ideally direct me to where this information is published.

A few more experiments later and I can see that the 35ms Low on CLK has nothing to do with 'unlocking' my PMBus. All I'm really doing is supplying more clock pulses that are resulting in the 9240 proceeding with the PAGE command that was truncated. I even see the correct PAGE value continue to come out of the 9240 and then the DATA line goes High from the ACK bit position onwards as I continue to apply more CLK pulses. If I then issue a Stop(P) then this effectively completes the transaction and everything works as it should after that.

So this implies that the 9240 is completely ignoring a 35ms Low on the CLK line and that can't be right.

Sorry, I had forgotten that there is an errata which states that a timeout during a read command will hang the bus because your initial question was just about the specification limit for the timeout.

The timeout does work during write commands.

I do find your results interesting and will be following up with someone more knowledable in the subject, I'll try to get back to you shortly.

Thanks for getting back to me Brad and it will be interested to see what else you can find out. You said "...there is an errata that states..." but where would I find that? I have the UCD9240 Data Sheet Errata (SLUZ022 - May 2009) but I don't see it in there. Could it be that all PMBus errata are somewhere else?