pca9450b pmic_on_req held LOW by imx8 nano ultralite

[zingere]

i have a custom board using factory-new imx8 nano ultralite powered by the PCA9450B PMIC

PMIC_ON_REQ is connected directly to the MCU with an external 10K pull up. I am noticing that the OMIC_ON_REQ signal is held low (0V) even with the 10k pull up. This it is causing the PMIC to be stuck in SNVS power mode (only the 1V8 and 0V8 rails are powered) and not entering RUN.

The datasheet for the iMX8 says the PMIC_ON_REQ   Default Pin Function is "snvsmix.PMIC_ON_REQ" and the Input/Output status is "Open-drain, output high, with PU". So i am very confused as to why this signal is being held low.

If i cut the trace to the MCU, when i apply power the pull up correctly causes the PMIC_ON_REQ signal at the PMIC to be HIGH (1.8V) and the PMIC enters RUN mode and all the rails power up correctly.

I am wondering what is causing the imx8 to hold the signal LOW even with the external pull up, especially given the datasheets description of the mcu pin.

Thank you!

[JosephAtNXP]

Hi,

Thank you for your interest in NXP Semiconductor products,

Have you gone through chapter 4 Avoiding board bring-up problems of IMX8MNHDG? There could be a reset cause that holds the line asserted.

Regards

[zingere]

Yes I have looked at the HDG. It does not cover my issue. There is no issue with the reset or power on sequence if i cut the trace to the PMIC_ON_REQ pin on the iMX8. With the trace cut, PMIC power up sequence is valid, reset is released, and we are able to JTAG connect to the board and read back the board target info.

For some reason the iMX8 PMIC_ON_REQ pin is holding that signal low and this is particular signal is not mentioned in the board bring up in the HDG.

Any other thoughts?

[JosephAtNXP]

Hi,

Could you remove the pull-up, as per PCA9450B datasheet, pull-up is not needed.

Could you share the relevant schematics?

What is the status of POR_B in your board?

HDG states that it's used by the processor to assert PMIC_ON_REQ and requires a pull-up.

Regards

[zingere]

Here are the relevant schematic sheets. The schematic follows the schematic in the PCA4950 app note. No pull up on PMIC_ON_REQ. POR_B has external pull up.

The datasheet does not say anything about pull up resistor on the PMIC_ON_REQ. Can you tell me what page of the datasheet says not to put a pull up resistor on that signal? Or did you mean app note where there is the reference schematic?

I found other notes researching online that a valid design is attaching an external pull up to PMIC_ON_REQ signal (permanently setting it HIGH) and permanently pulling PMIC_STBY_REQ to LOW if i do not want the MCU to be able to control the power modes of the PMIC. 

My schematic has an external pull up resistor on POR_B. I am away from the lab so I do not have the board in front of me, but i think POR_B signal is ok because when i attach an external pull up resistor to the PMIC_ON_REQ signal, the PMIC enters run (all rails power up correctly) and the firmware developer is able to connect to the iMX8 over JTAG and read back the target data. The firmware developer is also able to flash firmware to the eMMC.

So my issue remains that the iMX8 PMIC_ON_REQ pin is holding the signal LOW (even with the external pull up). When i cut the trace to the iMX8, the added external pull-up pulls the signal high and the PMIC enters run.

Is there something in the ROM of the iMX8 that could cause this? I am confused by this behavior because the imx8 datasheets says the default function and state of the PMIC_ON_REQ pin is open-drain output set to HIGH state

[JosephAtNXP · Accepted solution]

Hi,

Yes, actually the BootROM can be a reason for PMIC_ON_REQ not being asserted, it waits for SNVS supplies, then delays for an amount of time, also it depends on the processor control inputs.

Please review:

1. Pull ONOFF to LDO1 (1V8 instead of 0V8).

2. PMIC outputs clock source to processor.

3. Processor oscillator has a valid clock.

4. SNVS supplies are valid.

Regards

[zingere]

Pulling up ONOFF to 1V8 instead of 0V8 fixed it!

That was an error in the design.

thank you very much!