TDA4VE-Q1: An ESM event was reported but did not actually affect system operation.

Hi Zhiwei,

I have informed the corresponding expert to have a look into this query. Thanks in advance for your patience.

Regards
Gokul

Hi, 

Is this intSrc in hex or decimal? Are you using the SDL examples to initialize the ESM callback?

Regards,

Josiitaa

Hi,

The intSrc is in decimal. And we are using the ​​SDK ESM driver​​ from the ​​TI SDK​​ for initialization.

This should point to "#define SDLR_ESM0_ESM_LVL_EVENT_PLLFRACF2_SSMOD16_LOCKLOSS_IPCFG_0 (16U)

"

Hi, 

Yes. This interrupt is that of a PLL slip detect. Please refer to the TRM section "5.4.8.4.1.2.2 PLL Lock" for more details.

Regards, 

Josiitaa

Hi,

We are wondering if this is a true fault or fake fault, and what is the fault corresponding to this 'event'? What are the possible triggering causes?

Because this fault happens several times, but we don't see there is anything wrong with the system.

If this is a fake fault, we will consider disabling this mechanism.

Hi,

Zhiwei Wang said:

what is the fault corresponding to this 'event'? What are the possible triggering causes?

PLL module outputs a lock status signal to indicate that the PLL has achieved frequency lock. When the PLL detects no cycle slips between the feedback clock (FFB) and reference clock FPFD (FREF/ REFDIV[5-0]) for 128 consecutive cycles, it asserts the lock signal high. When the PLL detects any cycle slip, lock signal will go low and stays low until it detects no cycle slip for 128 consecutive cycles. This lock signal is captured in <PLL_name>_STAT[0] LOCK bit. Software can read this bit to determine if the PLL has achieved frequency lock before selecting the PLL clock through external bypass mux.

Zhiwei Wang said:

Because this fault happens several times, but we don't see there is anything wrong with the system.

When PLL losses lock, there is a hardware mechanism to automatically bypass the PLL clock to the reference clock (FREF) using the external glitch free mux. BYP_ON_LOCKLOSS bit in <PLL_name>_CTRL register enables this automatic bypass mode on PLL lock loss. When the PLL re-locks, the glitch free mux switches to PLL clock out.

As mentioned above could you please refer to the TRM section "5.4.8.4.1.2.2 PLL Lock" for more details.

Regards,

Manojna

Hi,

As of yesterday, we conducted a total of 2,732 stress tests, during which the corresponding fault was triggered 117 times. Is this trigger frequency normal? What factors could contribute to this fault? The TRM states that recovery occurs after 128 consecutive cycles without cycle slips. How long is this recovery period? We plan to use this cycle as a delay time to reduce false alarms.

Hi,

Could the details of stress test be shared??.

Zhiwei Wang said:

The TRM states that recovery occurs after 128 consecutive cycles without cycle slips

If the clock gets 128 cycles without slip, then it locks it, if it does not get that then it will trigger a fault.

Regards,

Manojna

Hi,

The stress test is "Activate AVM and ensure image output after KL15 power cycle (sleep/wake-up)"

And could you tell me how long time is the "128 cycles without slip"? We might set this as the debounce time.

Hi,

128 cycles is dependent on your clock source, PLL is trying to lock.

Consider an example if the clock is 10Mhz, then one cycle would be (1/10MHz).

Regards,

Manojna

Hi Manojna,

Thanks for your reply. We still would like to make sure if this is a false fault. Have you ever seen similar issue from other customer? And could you please try to reproduce this issue on TI EVM to confirm if this issue is related with customer HW. Thanks

Hi,

Could you please provide more information on the test.

Regards,

Manojna