TDA4VM: K3 ESM state cleared in U‑Boot, root‑cause ESM debug info lost after PMIC‑triggered reset

Part Number: TDA4VM

Hi TI team,

during an endurance run on our board, an ESM event occurred that caused the attached TPS6594x PMIC to reset the SoC.

After the reboot, we want to determine which ESM event caused the reset. However, we found that the ESM fault status is cleared very early in U‑Boot, inside the k3_esm driver probe function. As a result, all ESM raw status bits from the previous boot are cleared before we have any chance to inspect or log them.

The relevant U‑Boot code (drivers/misc/k3_esm.c):

writel(ESM_SFT_RST_KEY, base + ESM_SFT_RST);

for (i = 0; i < num_pins; i++) {
    esm_intr_prio_set(base, pins[i]);
    esm_clear_raw_status(base, pins[i]); // ESM registers cleared
    esm_pin_enable(base, pins[i]);
    esm_intr_enable(base, pins[i]);
}

writel(ESM_EN_KEY, base + ESM_EN);

Questions:

Does TI provide guidance or best practices on logging ESM faults across PMIC‑triggered resets?
Has anyone successfully implemented persistent ESM fault logging for Jacinto devices?

Any recommendations on how to reliably capture the root cause before U‑Boot clears the ESM state would be greatly appreciated.

Thanks in advance!

Peiren