TDA4VM: TDA4VM brownout on vdd_cpu during AVS configuration

kcastille said:

Strong suspicion that there may be two writes - one with 0x0 (as per log) and second with 0x31 (as per before/after I2C dump), and these two writes could explain the triangular "droop"

Yes, this is the most likely culprit of the triangular droop. The first half of the wave shows 800mV ->400mV in about 80us. That lines up with the 5mV/us slew rate setting for the rail. Similarly, on the rise ~450mV in ~90us is also 5mV/us.

Hi Michael, Kyle,

I am also unable to recreate the 0x4 // 0x0 value anymore for some reason after adding additional prints to every instance of pmic_reg_write() in order to track which functions are calling the register writes in ./drivers/power/regulator/tps65941_regulator.c - I get the following as part of the U-Boot SPL messages now:

printing from buck_enable
addr = 0x4 and value = 0x1
printing from buck_val
addr = 0xe and value = 0x41

 However the brownout/glitch remains. For completeness, I also re-dumped the registers before and after (irrelevant lines omitted). The registers that change are as noted in the log (04h and 0Eh).

Before: 

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: 00 82 13 04 31 2b 20 2b 30 2d 31 2b 31 1b 37 37    .???1+ +0-1+1?77

After:

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: 00 82 13 04 01 2b 20 2b 30 2d 31 2b 31 1b 41 37   .????+ +0-1+1?A7

I tried to capture the I2C WKUP bus during the attempted bootup sequence using a logic analyzer as in the attached document, please let me know if anything stands out. It seems as if there is some I2C activity outside of the tps65941_regulator.c driver as well. The capture was started after finishing the sysfw.itb upload from USB-DFU boot.

Edit: Upon some researching it looks like there might be a spurious command in the last capture, see:

If I am reading the datasheet correct, I see 0x0E 0x05 which translates to set VBUCK1 to 0.4V followed by the 0x0E 0x41 which is 0.85V:

Does this seem reasonable?

tps6594_logic_analyzer_tda4vm_debug.docx

Jonathan Lee said:

I see 0x0E 0x05 which translates to set VBUCK

Anyway you can check how this is getting set to 0x5? 

Jonathan Lee said:

printing from buck_val
addr = 0xe and value = 0x41

We see only this print.

- Keerthy

Hi Keerthy,

I have inserted a print statement before every instance of pmic_reg_write() in tps65941_regulator.c already. I did a search for any other source files referencing the tps6594 code and found one more file at drivers/power/pmic/tps65941.c. I added prints to the tps65941_write() function.

Relevant output is below. I can match up some of the additional writes such as 0x6c / 0x3f and 0x92 / 0x60 with my logic analyzer dump but I'm not seeing the double 0x0e write.

Reading on-board EEPROM at 0x51 failed -121
printing from buck_enable
addr = 0x4 and value = 0x1
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x4 and value = 0x1
printing from buck_val
addr = 0xe and value = 0x41
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0xe and value = 0x41
k3_ddrss_probe(dev=41c876fc)
k3_ddrss_ofdata_to_priv(dev=41c876fc)
k3_ddrss memorycontroller@0298e000: No reg property for SS Config region, but this is optional so continuing.
k3_ddrss memorycontroller@0298e000: ddr freq0 not populated, using bypass frequency.
k3_ddrss_power_on(ddrss=41cdc940)
k3_ddrss memorycontroller@0298e000: vtt-supply not found.
k3_lpddr4_probe: PASS
k3_lpddr4_init: PASS
--->>> LPDDR4 Initialization is in progress ... <<<---
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 0, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 0, req no. = 1, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 2, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 2, req no. = 3, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 4, instance = 0
k3_lpddr4_freq_update: received freq change req: req type = 2, req no. = 5, instance = 0
k3_lpddr4_start: Post start PASS
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x6c and value = 0x3f
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x92 and value = 0x60
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x59 and value = 0x7
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x8f and value = 0x1

Are there any other places in the code that register writes could be called from? 

Thanks,

Jonathan

Jonathan Lee said:

printing from buck_enable
addr = 0x4 and value = 0x1
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x4 and value = 0x1

Writing 0x01 to register 0x04 will disable the BUCK1 voltage monitor. This might be ok for debug purposes but not for regular in system use. In general, a rail shouldn't be enabled without it's corresponding voltage monitor. When moving to the ACTIVE state, the PMIC will set register 0x04 to 0x31.

Jonathan Lee said:

printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x6c and value = 0x3f
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x92 and value = 0x60
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x59 and value = 0x7
printing from drivers/power/pmic/tps65941.c tps65941_write addr = 0x8f and value = 0x1

These writes configure and start the ESM_MCU in level mode. Is the nERR_MCU signal high when the last write is made? If not, this will cause an ESM_MCU_ERR leading to a warm reset. Output voltages get set back to default values and nRSTOUT and nRSTOUT_SOC are toggled low for 2ms.

Hi Jonathan,

Not sure this is critical, but it appears your before/after for 0x4 is different than originally shared?   This thread says before = 0x31 and after = 0x1.   Am I reading this correctly?

Also ... if there is a spurious write to set 0x0E 0x05 which translates to set VBUCK1 to 0.4V ... that looks like a smoking gun.

Side note related to "Reading on-board EEPROM at 0x51 failed -121".  The TI EVM has a EEPROM which is used to self-identify itself ("I'm a TDA4VM EVM", or "I'm a TDA4VM Starter Kit") such that SDK/software can adapt to the particular hardware.  99% of the time, customer boards won't implement that EEPROM.  As such, it may be worth removing those I2C reads from your software.  That's likely the source of other spurious accesses that you're seeing on your LA traces.

Regards,

Kyle