AM5728: PMIC POWERGOOD problem, ref design TI_AM572x_PM_RevA3a

If you haven't seen it, this is related to your question:

e2e.ti.com/.../3266.should-i-use-powerhold-or-pwron-to-turn-on-the-pmic

GPIO_7 functions as POWERHOLD on the TPS6590378. However, POWERHOLD is expected to be high to turn on the device. You're seeing it low? Are you getting a voltage out of LDO_VRTC?

How are the BOOT pins strapped?

PMIC_POWERGOOD (TP5) is low. LDO_VRTC is high.

BOOT pins are:

0: low

1: high

2, 3, 4: low

5: high

6, 7: low

8: high

9, 10, 11, 12, 13, 14: low

15: high

On the SPL and u-boot side, I'm seeing what I THINK are a bunch of timeouts on the I2C bus between the A15 and the PMIC:

I did some "static tracing" in the SPL and I'm wondering from all of the MMC messages I'm seeing if the A15 cannot send messages to the PMIC to "tune" or configure the rail which powers MMC1??  Please see below.

SPL Messages:

Timed out in wait_for_bb: status=1000

Timed out in wait_for_bb: status=1000

Trying to boot from MMC1

Timed out in wait_for_bb: status=1000

tps65903x: could not set LDO1 voltage.

** Unable to use mmc 0:1 for loading the env **

Using default environment

U-Boot Messages:

CPU  : DRA752-GP ES2.0

Model: TI AM572x EVM Rev A3

Board: Am572x Custom HW GW SCU REV

DRAM:  2 GiB

MMC:   Timed out in wait_for_bb: status=1000

Timed out in wait_for_bb: status=1000

OMAP SD/MMC: 0, OMAP SD/MMC: 1

Timed out in wait_for_bb: status=1000

tps65903x: could not set LDO1 voltage.

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

failed to set signal voltage

Card did not respond to voltage select!

** Bad device mmc 0 **

Using default environment

Timed out in wait_for_bb: status=1000

ti_i2c_eeprom_init failed 1

setup_board_eeprom_env: am57xx_custom_hw_gw_scu_reva1

Timed out in wait_for_bb: status=1000

Timed out in wait_for_bb: status=1000

Timed out in wait_for_bb: status=1000

SCSI:  SATA link 0 timeout.

AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode

flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst

scanning bus for devices...

Found 0 device(s).

Net:   <ethaddr> not set. Validating first E-fuse MAC

cpsw

Press SPACE to abort autoboot in 2 seconds

WARNING: Could not determine device tree to use

usb_boot is currently disabled

scsi_boot is currently disabled

Timed out in wait_for_bb: status=1000

tps65903x: could not set LDO1 voltage.

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

failed to set signal voltage

Card did not respond to voltage select!

Timed out in wait_for_bb: status=1000

tps65903x: could not set LDO1 voltage.

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

Timed out in wait_for_bb: status=1000

ERROR: read error from device: fdf35918 register: 0x50!

at drivers/power/pmic/palmas.c:40/palmas_read()

failed to set signal voltage

Card did not respond to voltage select!

CACHE: Misaligned operation at range [fffbb310, fffbbb10]

** First descriptor is NOT a primary desc on 1:1 **

switch to partitions #0, OK

mmc1(part 0) is current device

CACHE: Misaligned operation at range [fffbb310, fffbbb10]

** First descriptor is NOT a primary desc on 1:1 **

Scanning mmc device 1

Checking for: /uEnv.txt ...

** No partition table - mmc 1 **

Checking for: /boot/uEnv.txt ...

** No partition table - mmc 1 **

** No partition table - mmc 1 **

** No partition table - mmc 1 **

** No partition table - mmc 1 **

** No partition table - mmc 1 **

** No partition table - mmc 1 **

** No partition table - mmc 1 **

Laura,

Do you have a pull-up connected on the POWERGOOD pin? This pin is open-drain, and will need a 1.8V pull-up supply (suggested VRTC) before you can see a high level on the pin.

By default, only SMPS12 is monitored by POWERGOOD, so that is the key rail to see if POWERGOOD should be high. Its default is 1.15V, so if you are seeing that voltage, POWERGOOD should be set high.

Regards,
Karl

There is not a pull-up on the POWERGOOD pin because this is an output - it's not pulled up on the reference design either and our previous version of the board's POWERGOOD was high without a pull-up.
SMPS12 is measuring at 1.15V on my board, but POWERGOOD is still 0V.

Does it matter that POWERGOOD is low? Does the PMIC use this value internally? If the POWERGOOD value doesn't prevent any function of the PMIC, I'm happy to ignore this issue and move on to the I2C issue we are seeing with the PMIC timing out when we try to boot up.

POWERGOOD is open-drain only, so it has no capability to drive a high voltage. So I don't think it can be set high without a pull-up.

But in any case, it is not used internally, and can be safely ignored as long as the system doesn't depend on the POWERGOOD status. Its only function is to indicate to the system if there was a power fault. The PMIC operation will not be affected if the POWERGOOD output is low.

Regards,
Karl

Regarding the PMIC model, we placed the TPS6590378 PMIC instead of the TPS6590376 PMIC.  

Does the XXXX378 have a different I2C address than the XXXX376?  That might explain some of the protocol problems in the console log...

Thanks!

Jeff

Jeff,

They have the same I2C address - actually, the only change is to the power-down sequence. The DDR disable was moved earlier in the sequence, and the second sequence slot was extended from 500us to 1ms. So I wouldn't expect any functional difference in your system because of the change from '0376 to '0378.

I'm not very familiar with the software side, but I don't see anything in that log that looks like a specific error, only lack of communication. Have you tried scoping the I2C lines to see if you're getting a valid I2C packet? That might hint if it's a software issue or hardware/PMIC issue.

Regards,
Karl

Hey thanks Karl! There appears to be an issue with the voltages on the I2C bus... 3.3V for SCL and only 1.8V for SDA. They should both probably be 0..3.3V..

We aren't able to boot all the way into Linux because of I2C timeout errors when the second bootloader loads.

We found that the I2C1 SDA line is at 1.2V, and the SCL line is 3.3V. Both signals have 2.2K pull-up resistors to 3.3V - this part of the circuit is the same as the reference design and no changes were made to the routing of these nets. Could the PMIC be holding the SDA voltage down? Has anybody seen something similar with the TPS6590378?