Other NXP ProductsのトピックRe: PTN3460 sometimes does not start properly

PTN3460 sometimes does not start properly

ulfhei — Sun, 08 Jan 2017 17:02:51 GMT

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.

Re: PTN3460 sometimes does not start properly

TomasVaverka — Tue, 10 Jan 2017 09:32:33 GMT

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

Re: PTN3460 sometimes does not start properly

ulfhei — Tue, 10 Jan 2017 10:26:42 GMT

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.

Re: PTN3460 sometimes does not start properly

TomasVaverka — Fri, 13 Jan 2017 11:54:37 GMT

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:

Is the Linux system working properly at low temp? What is the prove?
How many devices are on SMBUS? How many pull up resistors? Total value?
Please send us the system block diagram as how PTN3460 is connected to the CPU/GPU and SMBUS connection.
PTN3460 uses SMBUS for configuration and EDID setting only during system first power up. SMBUS is idle once PTN3460 is configured. PTN3460 does not use SMBUS once PTN3460 is in normal operation. PTN3460 uses AUX command for Display Port operation.
What customer is using SMBUS to communicate with PTN3460?
C0, C3 are not used by PTN3460 FW. The configuration table looks right on both cases.
What is exactly the failure symptom, no display at all or bad display?
Is the failure repeatable with many ICs? Have you tried to replace different ICs?
Can you tab into AUX lines and send us AUX command traces?
Send us Linux drm logs that shows AUX contact tries.

Best regards,

Tomas