In 2009 the datasheet was updated to recommend a change of the minimum value for CONFIG1 to 14h. This increases the PECI bit time which allows the system to handle the I2C interrupt without dropping PECI bytes, because the PECI bytes arrive at a slower pace which decreases the processing load on the MAX6621. Specifically, the longest I2C interrupt is due to the "GETMAXTEMP" I2C command (08h) which takes approximately 87us of CPU time compared to an available 39us between PECI bytes (when CONFIG1[15:8]=03h). Setting CONFIG1[15:8] to 14h increases the time between PECI bytes to 266us; that fixes the problem because the GETMAXTEMP command can now be processed in its entirety between two PECI bytes. This is not the default value for CONFIG1, so the customer has to configure the MAX6621 to do this.
Alternate workarounds for failing reads we identified at the time were:
-
Reading the register twice. This works if the time between two PECI reads is not a multiple of the time between two I2C reads. Since this is not under exact control of the user, we recommend changing CONFIG1 as permanent solution.
-
The frequency of the error can also decreased by:
-
Increasing the delay between PECI polls (CONFIG0 bits 2:0)
-
Not calling the GETMAXTEMP command (08h)
-
Reducing I2C clock rate
-
Please note that neither of these is necessary when setting CONFIG1[15:8] to 14h or greater. It may be worthwhile trying these alternate mitigations to see whether they make a difference.
Unfortunately, the MAX6621 does not support anything beyond PECI1. While the physical layer looks the same, there are many new network layer and command features in PECI 2 and PECI 3 that MAX6621 does not support (for example, assured write FCS, host ID, retry indication).
However, since MAX6621 is the system host (command originator), the items of concern are the ones where the processor (“client”) returns something that we don’t expect (for example, there are updates to client behavior in bus idle, sleep and reset states).