We are using the PTN3460 on an add on CPU board that has an Intel Braswell CPU, where it sometimes completely fails to answer to accesses via the eDP side after powerup. This is very temperature dependant, so the lower, the more often it happens, but still keeping within the 0 - 70C parameters.
Each time this happens, it is possible to see a small difference on 2 bytes on the SMBUS bus side, however, these bytes are not documented, and marked to be in a reserved region (0x99 - 0xD6) according to AN11128.
The bytes in question are 0xC0, that on successfull starts contains 0x04, and 0xC3, that on success contains 0x03.
On failed bootups, both these bytes instead contains 0x00.
It would be interesting to get confirmation if the normal values of these bytes (0x04, 0x03) are some sort of indication registers for a successful (e)DP connection, as it then might more point to the eDP transmitting side being the cuplrit somehow.
Hello Tomas,
thank you for the swift reply.
Test conditions when these failures have been found is a surrounding temperature at about 4-8C, and power up tests are performed with a Debian 8 (Jessie) OS.
The failures are very temperature dependent, and intermittent, from a few failures per 12 hours at 35 starts per hour at the above temperatures, to several failures per hour at lower temperatures.
If the environment temperature is lowered further, the failures become more frequent, and if lowered to -20C, the chip sometimes does not respond on the SMBUS as all, but that might be baecause it is then too far off spec.
We are aware that the chip is only 0-70C, so these lower temperatures are only used to make the fault show itself as fast as possible,
If the temperature is raised to about 30C, the problems do not appear.
This is an OK dump:
i2cdump -y 0 0x60
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 0c f4 1a 00 01 00 00 00 ........???.?...
10: 28 12 01 03 80 00 00 00 ee 00 00 00 00 00 00 00 (????...?.......
20: 00 00 00 af c0 00 45 40 01 01 01 01 01 01 01 01 ...??.E@????????
30: 01 01 01 01 01 01 00 0f 20 e0 30 58 19 20 18 48 ??????.? ?0X? ?H
40: 12 00 00 00 00 00 00 18 00 00 00 10 00 32 78 1e ?......?...?.2x?
50: 32 05 00 0a 20 20 20 20 20 20 00 00 00 fe 00 63 2?.? ...?..
60: 6f 6e 67 61 74 65 63 20 41 47 0a 20 00 00 00 0e ....... .:? ...?
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 d8 .............?.?
80: 00 23 0b 04 01 00 00 00 01 fe 00 00 08 00 0f 0c .#???...??..?.??
90: 07 ff 1d 0a 14 00 01 02 01 02 00 00 00 00 00 00 ?.???.????......
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 04 00 00 03 00 c0 00 00 00 00 00 00 00 00 00 00 ?..?.?..........
d0: 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 ........????????
e0: 09 0a 0b 0c 0d 0e 0f 10 01 00 00 00 12 34 56 78 ?????????...?4Vx
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
And this is a failed dump:
i2cdump -y 0 0x60
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 0c f4 1a 00 01 00 00 00 ........???.?...
10: 28 12 01 03 80 00 00 00 ee 00 00 00 00 00 00 00 (????...?.......
20: 00 00 00 af c0 00 45 40 01 01 01 01 01 01 01 01 ...??.E@????????
30: 01 01 01 01 01 01 00 0f 20 e0 30 58 19 20 18 48 ??????.? ?0X? ?H
40: 12 00 00 00 00 00 00 18 00 00 00 10 00 32 78 1e ?......?...?.2x?
50: 32 05 00 0a 20 20 20 20 20 20 00 00 00 fe 00 63 2?.? ...?..
60: 6f 6e 67 61 74 65 63 20 41 47 0a 20 00 00 00 0e ....... ..? ...?
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 d8 .............?.?
80: 00 23 0b 04 01 00 00 00 01 fe 00 00 08 00 0f 0c .#???...??..?.??
90: 07 ff 1d 0a 14 00 01 02 01 02 00 00 00 00 00 00 ?.???.????......
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 .....?..........
d0: 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 ........????????
e0: 09 0a 0b 0c 0d 0e 0f 10 01 00 00 00 12 34 56 78 ?????????...?4Vx
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
As you can see, the difference is in 0xC0 and 0xC3.
I have verified the startup conditions regarding reset signal, time to first access (~180ms, 2x90ms), rise times of both power supplies and the pullup/down resistors, and they are all correct.
I cannot replicate the actual fault symptoms by blocking the diff pairs on either the AUX or any of the two DP channels, so that is probably not the cause of the failures.
In the Linux drm logs i have, it looks like the chip is not responding to AUX contact tries, but it never goes further than that when it fails.
Hello Ulf,
It is difficult for us to duplicate this failure symptom, as we do not have Linux system, let alone Debian 8 (Jessie) OS.
You can send the chip back to us to perform a Failure Analysis at low temperature, or you can try a few more tests:
Best regards,
Tomas
Hello Ulf,
Your request is being reviewed by our experts on the PTN3460.
Meanwhile, could you please share more details on the test condition and both working and failed SMBus codes?
Best regards,
Tomas