Display with PTN3460I sometimes not work

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Display with PTN3460I sometimes not work

768 Views
michael_spaeth
Contributor II

Hello,

we have the problem that some of our devices (WIN10 embedded) arbitrarily the internal display on the PTN3460I stays dark and is not found in WIN. If I make an update of the graphics driver (with external monitor possible), then the previously not found internal display works without restarting. Does anyone have a similar problem or can I give tips on what to look for?

During the investigation, I wanted to read the register contents of the PTN3460I and have a strange behavior here. We operate the PTN3460I on an Intel Atom E3800 CPU. The I2C interface is controlled by a dedicated board controller.

From this, initially only register 0x84 (EDID ROM emulation control) is written. If I now read back all register contents, the value 0x00 is in register 0x81 (LVDS interface control 1). The default value according to the Programming Guide (AN11606) should be 0x0B. All other register contents are correct. Even if I explicitly write 0x0B into the register, I read out 0x00 afterwards. If I write 0xFF into the register, I will read 0xC7 afterwards. What is going wrong here?

Please help me!

Thanks in advance,

Michael

 

4 Replies

624 Views
JozefKozon
NXP TechSupport
NXP TechSupport

Hello Michael,

I have asked for help an application engineer. For his feedback to your questions please see the description.

DESCRIPTION

Hello, we have the problem that some of our devices (WIN10 embedded) arbitrarily the internal display on the PTN3460I stays dark and is not found in WIN. If I make an update of the graphics driver (with external monitor possible), then the previously not found internal display works without restarting. Does anyone have a similar problem or can I give tips on what to look for?

Eric:> We didn’t receive such issue report from any customer before, and we have no idea what is differences between two version of graphics driver. If customer can get the major differences list between two graphics driver from Intel, then we can look into it to see whether the changes will affect to PTN3460i behaviors.

 

During the investigation, I wanted to read the register contents of the PTN3460I and have a strange behavior here. We operate the PTN3460I on an Intel Atom E3800 CPU. The I2C interface is controlled by a dedicated board controller. From this, initially only register 0x84 (EDID ROM emulation control) is written. If I now read back all register contents, the value 0x00 is in register 0x81 (LVDS interface control 1). The default value according to the Programming Guide (AN11606) should be 0x0B. All other register contents are correct. Even if I explicitly write 0x0B into the register, I read out 0x00 afterwards. If I write 0xFF into the register, I will read 0xC7 afterwards. What is going wrong here? Please help me!

Eric:> Some bits in register 0x81 are depending on CFG pin settings and some bits are user programmable.

  • Bit 6 (user programmable).
  • Bit 5:4 (PTN3460I will read in CFG2 pin setting and overwritten setting in the bit 5:4).
  • Bit 3 (PTN3460I will read in CFG1 pin setting and overwritten setting in the bit 3).
  • Bit 2 (user programmable).
  • Bit 1:0 (PTN3460I will read in CFG1 pin setting and overwritten setting in the bit 1:0, but it is user programmable).

 

If customer had CFG1 pin = 0 and CFG2 pin = 0 in application, then register 0x81 = 0x00 will be the default value.

 

  • Register 0x81 details in AN11606.

 AN11606a.jpg

AN11606b.jpg

  • CFG1 and CFG2 pins setting in PTN3460I datasheet.CFG1andCGF2.pngBest regards,Jozef

624 Views
michael_spaeth
Contributor II

Hi Jozef,
thank you for the reply and the detailed explanation of the register contents.

Again to my problem that the display stays dark. There are no two versions of the graphics driver. It is sufficient if the same driver is reinstalled and re-initialized to my understanding the PTN3460I.

My investigation has also shown that in case of failure, the chip can not be addressed by I2C. PTN3460I first needs a reset and then can be communicated again. The external Reset Pin (RST_N) is open in our circuit (floating). According to the data sheet, the PTN3460I should also be able to be operated without an external reset. If I connect the reset pin to the "CarrierBoard-Reset" output of the CPU module (it will be held down for a short time when the device starts up), the failure does not seem to occur. I think we keep all timings from the data sheet at the start up. Is there a problem if the PTN3460I is ready and the initialization of Windows or the BIOS comes later? Maybe you or the application engineer will come up with something that might explain our behavior.

Best regards,

Michael

0 Kudos

624 Views
JozefKozon
NXP TechSupport
NXP TechSupport

Hi Michael,

I have received an update from the application engineer. Could you please provide feedback to his questions?

DESCRIPTION

It looks like for any reason that PTN3460I was not resetting properly when issue was occurred, so that I2C interface of PTN3460I was not working.

 

It should not be an issue in application if the PTN3460I is ready and the initialization of Windows or the BIOS comes later.

 

I have two questions.

 

  1. Does customer have the optional cap on board? If yes, can customer solder it on board and test it again?

OptionlCap.png

2. Does customer use PD_N pin in application? If yes, please ask customer to follow below timing chart for PD_N pin control.

PD_Npin.png

Best Regards,

Jozef

0 Kudos

624 Views
michael_spaeth
Contributor II

Hi Jozef,

unfortunately we do not have the optional capacitor on the board. I've soldered this and it seems like this fixes the bug. It is a bit annoying that an optional capacitor is not that optional. Nevertheless many thanks for the fast and competent help!

Best Regards, Michael