Going from PF0100NPEP to PF0100NPAEP

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

Going from PF0100NPEP to PF0100NPAEP

770 Views
camillegiaux
Contributor I

Hello, 

A few years ago we designed a system based on the IMX6 processor. Voltages for this design are controlled by a PMIC (PF0100NPEP up to now). The PMIC configuration is done through an I²C interface (thanks to a programmed microcontroller). This system was used in the past years. 

We are now manufacturing new cards with the new PMIC version (PF0100NPAEP), the previous one being obsolete. These new PCBs work nicely but for an issue during booting. When booting we observe two different behaviors:

- If the card was not recently (recently is a maximum of around 4 seconds) plugged in, the card will not boot. 

- If the card was plugged recently, the card will boot. 

By observing different signals on the card during power-up we deduced that PMIC is in cause. More precisely signal VSNVS (and associated PWRON) do not behave correctly.

The associated circuitry (or the rest of the PCB) should not be in cause since we were able to obtain good results by changing the NPAEP back to NPEP on one of the new cards.

The program used in the PIC to configure PMIC (by I²C) was not modified during the tests. 

Recordings of the measured VSNVS signal are in attachment in three different cases: 

- When PCB is not booting (with NPAEP version): signal takes the wanted value (3V) for a short time and then goes back to 1V. 

- When PCB is booting (with NPAEP version): we see an unwanted step at around 2.6V but the final value is what is expected. 

- When (new) PCB is booting with an old NPEP version we still had in stock. We were able to replace NPAEP with NPEP version. This card behaves as expected. 

We were not able when going through the PMIC datasheet and errata to find what change which occurred between NPEP and NPAEP version could cause this type of behavior. 

Would you have any idea of what could cause this behavior ? Any idea on what we could do to solve this ? 

Thanks

Camille

Labels (2)
0 Kudos
4 Replies

592 Views
igorpadykov
NXP Employee
NXP Employee

Hi Camille

VSNVS signal at 1V may be caused by floating LICELL, so

recommended to connect LICELL pin to VIN or use valid coincell. Behaviour

is described in sect.6.4.7 VSNVS LDO/switch MMPF0100 datasheet

http://www.nxp.com/assets/documents/data/en/data-sheets/MMPF0100.pdf 

Workarounds described in errata for old version are not needed for MMPF0100A.

http://cache.freescale.com/files/analog/doc/errata/MMPF0100ER.pdf 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

592 Views
camillegiaux
Contributor I

Hello Igor, 

Thank you for your answer. 

For what regards LICELL pin I double checked the circuit. We indeed had a small problem here. 

This one is solved now and the different steps taken by VSNVS do not appear anymore (we go directly from 0 to 3V when we boot correctly). 

However PCB still sometimes doesn't boot (same behavior as before) and VSNVS net still takes the weird shape when we do not boot (NPAEP_no_boot.jpg of my initial post). 

I've already checked workarounds which are not applicable and none of them are implement on our PCB. 

Any over clue ? 

We are now suspecting a timing error during power up/configuration (linked to software on the associated PIC). Any idea in this direction ? Do you know if some timings changed between versions ? 

Again, thank you, 

Regards, 

Camille

0 Kudos

592 Views
igorpadykov
NXP Employee
NXP Employee

Hi Camille

could you confirm that had connecting LICELL pin to VIN or use valid coincell.solved problem

and and VSNVS goes directly to 3V?

Best regards
igor

0 Kudos

592 Views
camillegiaux
Contributor I

Hi Igor, 

I can now confirm that VSNVS goes directly to 3V. 

In the mean time we found our mistake. Errata number 19 was taken care of in a different way as mentioned in the errata document. I missed it before. When this workaround is removed, we don't have anymore problem.  

Everything work nicely for this card. 

I will go threw our other designs using PMIC now. 

Again, thank you for your answers. 

Best regards,

Camille

0 Kudos