TPS659038-Q1: TPS659038 + AM5728 failure after a SMPS12 DVS Register write

Jorge,

Hi, The TPS659038-Q1 device loads the default voltages from OTP memory and the voltages only change if the system writes the SMPS12_VOLTGE register or the SMPS12_FORCE register are written on the DVS page or page 1 of the register map.

Can you clarify the I2C address, register address, and data you are sending to the PMIC device to change the voltage?

Also, does the behavior go away when you reset power (VCC1)?

Thanks,

Nastasha

Hello,

The abnormal behavior is permanent after reset or power off. TPS659038 appears to be permanently "damaged". We have reproduced the problem (damaging a pmic in each case), the simplest sequence is:

1. Writing an anomalous value in the register SMPS12_VOLTAGE . For example 0x29.  The system reboots

2. Regulation drivers at startup read abnormal values and try to write 0 in the registry SMPS12_CTRL or values below the minimum in the registry SMPS12_VOLTAGE .

3. After any of these writes the system reboots after initialization. And so indefinitely. 

Notes:
- Writing to registers is performed through i2c bus 0, address 0x58 (page 1 of the register map).

- We have patched startup drivers,  mfd/palmas.c and regulator/palmas-regulator.c among others. Reads are very different from a pmic 'damaged' that from a pmic ok.  Also, they seem to change erratically

- Silicon Revision is 1.3 (read from register DESIGNREV in page 3).

Thank you for the support

Regards,

Jorge,

Writing 0x29 into register 0x23 and I2C address 0x58 should not create any issue. This should set the SMPS12 voltage to 0.85V.

Can you scope the I2C lines and check that this is the actual register and data information being sent to the device? Can you also scope SMPS12 and RESET_OUT to see if they look stable?

Writing 0x0 to SMPS12_CTRL would turn off the rail. This wouldn't damage the device either.

Is the software possibly resetting the device when the processor loses power from the SMPS12 rail?

Thanks,

nastasha

Hello Natasha,

I wonder where the behaviour of my card comes from.

The behaviour is as follows:

- My cards ( TPS659038 + AM5728 Phytec phyCORE-AM57x SOM) work well under normal circunstances. That means that at start up time the register values downloaded from the OTP memory look fine.

- We have experienced by many tests, that our board needs a minimun voltage of 0.96volt at SMPS12_VOLTAGE in order to work propertly (The minimum voltage for the register is 0.85volt but it is not enough for our boards). With values from 0.85 to 0.96 our system reboots. (We do not consider that a big issue)

However.....

- As soon as an incorrect value is written to SMPS12_VOLTAGE, let's say 0x28 our system reboots and something remains persistently because in following power ups (and remains forever) the register voltage values read from PMIC does not show good voltage. It shows a low voltage and drivers try to set the minimum value of 0x29 (0.85volt) at SMPS12_VOLTAGE which is less than 0.96volt and our card reboots entering in an endless loop.

The easy solution of modifying the minimum value from 0.85volt to 0.96volt is an option that we are aware of.

However we want to get to the heart of the problem in order to fully understand the PMIC and our real question is:

"what happen when writing an invalid value to SMPS12_VOLTAGE register and why the voltage values read at startup differs from the ones read before the bad write?" (After that bad write to SMPS12_VOLTAGE, the voltage value read at startup is lower than the minimum and drivers try to set a good value = 0.85 volt)

We are not sure if the OTP stored values can change so that a bad value is loaded at start-up....

Regards,

Jorge,

The OTP default settings cannot be changed. I still don't think the writes to the PMIC are invalid. These should not cause the PMIC to reset. I think this is related to the software drivers or the under voltage event on the processor. I am looping in the AM572x team to help understand what may cause this continual reset in the bootloader or processor device.

Thanks,

Nastasha

Hello Natasha,

As you said, I don't think neither that the PMIC resets itself. It has to do with the software drivers. In fact this happens at the time the kernel is loaded (bootloader is OK). We know that for sure and that is not what I want to investigate. My question is about waht changes inside the system (PMIC + AM)

1) we never see this issue if we don't write a value less than 0x2D (0.96 volt) in SMPS12_VOLTAGE  (because at start up all voltage values are OK and drivers do not need to adjust any PMIC register value)

2) We see this issue every time we power up the device after a write of less than 0x2D (0.96 volt) in SMPS12_VOLTAGE

That is why something persistent remains after that register write.

If OTP cannot be changed. What could be affecting the voltage read in SMPS12_VOLTAGE at start-up so that the drivers try to adjust the voltage?

Regards,

Jorge,

I may not understand the background of your question.

SMPS12 usually supplies the vdd_mpu domain of the SoC.

This domain uses AVS.  There are registers in the SoC that dictate on a unit by unit basis what is the appropriate voltage level to set the PMIC to for a given OPP (frequency target).  If you set the voltage level lower than the fuse dictates then the SoC functionality cannot be guaranteed.  I.e., the SoC can/will crash if the PMIC is misprogrammed.

Regards,

Kyle

Hello Kyle,

Yes, I understand. They are simply voltage control registers that set voltage levels and depending on those levels the SoC either works propertly or not (if undervoltage).

They problem is that something persistent happens to our system PMIC + AM5728 when an undervoltage is written once to SMPS12_VOLTAGE (it makes the SoC reset which is fully expected but the problem is that the system never starts-up as it did before)

In other words:

We have had a normal operation for months:

- Power is applied to our card

- PMIC starts

- OTP register values are downloaded to PMIC registers

- Voltage values to SoC are generated at good level and drivers do not try to adjust PMIC voltage levels because they are fine

when writing a SMPS12_VOLTAGE less than the SoC needs to propertly work:

- system hangs

It was expected to hang or reset and it does.....but then, following power-up was expected to work propertly:

- Power is applied to our card

- PMIC starts

- OTP register values are downloaded to PMIC registers

- Register voltage values to SoC show undervoltage levels and drivers adjust PMIC voltage levels because they are not fine

The question is why?

If OTP values cannot be changed, a fresh power up would not make anny difference between the normal situation we had for months and the temporary undervoltage that happened in other power cycle and made the SoC hang/reset.

What was permanetly changed that prevents the PMIC to generate the correct voltage values at start up as it did for months?

Thanks you for your support,

Regards, 

Jorge, 

I'll loop the PMIC team again.  I can imagine if a warm reset occurs maybe the PMIC would retain the previous voltage levels.  

If power is completely removed from the system (to the PMIC input) for an extended period, the next power cycle should use the original OTP voltage levels (boot voltages).  Are you saying the PMIC now permanently boots (with extended period of complete power down) with 0.96V or whatever level was written?

Thanks,

Kyle

Hello,

Yes, we are experiencing in our "Phytec phyCORE-AM57x SOM", that once that an incorrect value is written to SMPS12_VOLTAGE, the PMIC permanently boots (with extended period of complete power down) with undervoltage values. Drivers detect this situation and try to set SMPS12_VOLTAGE to minimum of 0.85volt which is not enough to power phyCORE-AM57x SOM which causes the board reboot.

If OTP values cannot be modified, something else must be happening.

Regards,

Jorge,

Can you use a multimeter or scope to measure the voltage on the SMPS12 rail? It would be helpful to understand what the voltage measurement of the rail is before and after you change the voltage through I2C.

Also, please verify the following voltages as well: LDOVRTC, VCCA, VIO_IN

If you can scope the following digital rails, this may also help indicate what is going on: NRESWARM, RESET_OUT, RESET_IN, POWERHOLD (GPIO_7).

Thanks,

Nastasha