DRA829V: PMIC WATCHDOG

Hello Charan,

If you're serving the watchdog when you're making these change, they will not take place due to the registers being locked out.

If you were instead in the long window, and you're writing to the long window bit field to shorten the window to a time interval shorter than the currently elapsed time, YOU WILL GET A TIMEOUT interrupt which leads to a toggling of the nRSTOUT & nRSTOUT_SoC pins which may be the source of your loss control after writing to these registers.

BR,

Nicholas McNamara

Hello Charan,

Charan cherry said:

i2c dev 0
i2c mw 0x48 0x31 0x00 1 ---- i2c2 as gpio for the use of justi2c1 for even watchdog
i2c mw 0x48 0x32 0x00 1 ---- i2c2 as gpio for the use of justi2c1 for even watchdog

i2c md 0x48 0xA5 1
# You should see RECOV_CNT = 0 after power cycle

There's a lot here, now it may be my misunderstanding of Linux commands, but the first two has you performing writes like so:

Write, data 0x00, to register 0x31 (GPIO1_CONF), on I2C address 0x48

Write, data 0x00, to register 0x32 (GPIO2_CONF), on I2C address 0x48

Read, register 0xA5 (RESERVED), on I2C address 0x48

Okay, this is the not the recover register, that's register 0x83

Charan cherry said:

H-SOC-PORz, H-MCU-PORz, signals

which are in PMIC are low low finally after low and high for some cycles when commands are given and serial terminal got lost, but no restart of the board.

PORz is also low at this time.(commands are attached above)

but H-SOC-PORz, H-MCU-PORz are high initially when no commands are given

I think processor went to reset state but no restart

Okay, Charan, honestly it looks like this is just a misconfiguration of the watchdog.

As everything is fine prior to writing to these registers.

Basically, what your writes have done is eliminated the I2C2 physical bus for the WD registers at address 0x12 and set both GPIO 1 & 2 to generic GPIO functions. There is no TRIG_WD pin at this time. So way to respond to the WD after configuring like that..

What I assume is happening after that is the PMIC is performing warm resets with the SoC, the SoC has no way to actually respond due to WD_TRIG pin not being available. This then has the WD timeout over & over until the recovery count hits saturation  (15 attempts), then the nRSTOUT is held low due to lockout from the recovery counter.

Charan cherry said:

# Configure watchdog PROPERLY for testing
i2c mw 0x12 0x06 0x00 1 # Trigger mode, WD_PWRHOLD=0
i2c mw 0x12 0x03 0x10 1 # Window-1 = 2 seconds
i2c mw 0x12 0x04 0x10 1 # Window-2 = 2 seconds
i2c mw 0x12 0x05 0x10 1 # Long Window = 2 seconds

Window 1 & window 2 can never be set to seconds, it's impossible, double check the datasheet as the maximum time allotted is on the order of milliseconds.

So my suggestion is to set that GPIO2 as the TRIG_WDOG, there's no need to change GPIO1 as any change between GPIO1 or GPIO2 from the I2C2 modes will remove the physical I2C2 bus on the PMIC. You will then have a valid pin for the TRIG_WDOG

When changing the WDOG registers be aware of the your boot up time in the long window (is 2 seconds appropriate?)

What is the STATE of the GPIO2 to MCU pin that was once an I2C line (is the pin HIGH or LOW upon PORz?)

This is critical as the rising of falling of the pin may trigger the PMIC to leave the long window upon nRSTOUT going high, which will prevent you from ever responding properly to the WD if this is not considered as I don't know what you're software will be monitoring as a respond to the nINT pin.

Please verify the pin in the MCU domain when trying to use it as the driving PIN, as you still may get stuck in an never booting loop due to this.

BR,

Nicholas McNamara

Hello Charan,

The TDA EVM has connections for WD Q&A, please verify the connection between that and the pin you want to use for WD TRIG, we don't have an example.

The trigger mode is outside of the use case, please read the datasheet in the relevant sections for the I2C for the PMIC & the watchdog, if you have questions please do ask and then I can follow up with answers.

BR,

Nicholas McNamara