TMS570LC4357-EP: Intermittent issue with N2HET

Hi Donald,

Apologies for the delayed response, 

We never came across this issue before on these devices, our internal AI suggesting few theoretical root cause, could you please verify them once:

Most Likely Root Cause Theories

 Theory 1: Race Condition Between nRST Deassertion and the PCR/CLKCNTL Peripheral Enable Sequence (Most Probable)

Your startup sequence performs a forced peripheral disable → PSPWRDWNCLRx → forced peripheral re-enable cycle (steps 7a–7c). This is a non-standard sequence. The TMS570 Technical Reference Manual (TRM) describes a specific ordering for peripheral frame power-up. The concern here is:

• When the Lauterbach probe drives nRST, the reset release timing is controlled externally by the probe, not by the device's internal power-on-reset (POR) sequencer.
• If nRST is released at a point where the internal oscillator or GCLK/HCLK is in a transient state, the PCR (Peripheral Central Resource) state machine may not complete its internal reset handshake correctly before your code writes to PSPWRDWNCLRx.
• Writing 0xFFFFFFFF to all PSPWRDWNCLRx registers while the PCR is still in an intermediate reset state could cause the PCR to latch into an inconsistent state where it believes the peripheral frames are powered but the internal reset to those frames was never properly deasserted.

This would explain why the registers appear zeroed and unwritable — the HET frame's internal reset is still asserted at the register bus level, even though the PCR power-down bit is cleared.

 Theory 2: nRST Glitch / Insufficient nRST Pulse Width from the Lauterbach Probe

The TMS570LC4357 requires a minimum nRST pulse width (typically specified in the device datasheet, often ≥ 1 µs, but the internal reset sequencer may require longer). If the Lauterbach Trace32 probe issues a very short nRST pulse:

• The device's internal reset controller (ESM, SYS, PCR) may not fully complete its reset sequence.
• The PCR reset state machine may be left in an intermediate state.
• This is consistent with the 1-in-10,000 failure rate — it could be a marginal timing condition that only manifests under specific temperature/voltage/clock phase conditions.

Recommended check: Use an oscilloscope to measure the nRST pulse width generated by the Lauterbach probe and compare it against the TMS570LC4357 datasheet minimum specification.

 Theory 3: Interaction with the TMS570 Reset Controller and Warm Reset vs. Cold Reset Behavior

The TMS570 distinguishes between different reset types (POR, warm reset via nRST, software reset, debug reset). A warm reset via nRST does not reset all registers to their POR state — specifically:

• The PCR power-down registers (PSPWRDWNCLRx/PSPWRDWNSETx) may retain their state across a warm nRST reset in some silicon revisions.
• If a previous run left any peripheral frame in a powered-down state, and the nRST reset does not clear this, your PSPWRDWNCLRx write may be racing against the reset sequencer re-asserting the power-down state.

Check: Read back the PSPWRDWNSETx registers immediately after your step 7b to verify they are actually cleared before proceeding to step 7c.

 Theory 4: Errata GCM#58 — VCLK/HCLK Ratio (Your Hypothesis)

You correctly noted errata GCM#58. While you assume VCLK/HCLK = 1/2 at startup, it is worth verifying:

• At the point of your step 7 (peripheral bring-out-of-reset), what is the actual CLKCNTL register value? Specifically, confirm VCLKR and VCLK2R fields.
• If the probe reset leaves the clock divider registers in an unexpected state (not POR default), it is possible VCLK could momentarily be at a ratio that triggers GCM#58 during the PCR access.

 Theory 5: Lauterbach Probe JTAG/DAP Interaction During Reset

The Lauterbach Trace32 probe maintains a JTAG/DAP connection during the reset. There is a known class of issues on ARM Cortex-R devices where:

• The debug access port (DAP) can hold certain system bus transactions open during reset.
• If the probe is actively polling registers (e.g., for a live watch window) at the moment nRST is asserted/deasserted, a partially-completed AHB/AXI transaction to the PCR or SYS register space could corrupt the PCR state machine.

--
Thanks & regareds,
Jagadish.

Hi Jagadish,

 So we’ve tested a few of these theories out + some of our own. I’ll give you the quick summary of the results:

Theory 1: Race Condition Between nRST Deassertion and the PCR/CLKCNTL Peripheral Enable Sequence (Most Probable)
 We didn’t find an initialization sequence for TMS570LC4357 but we assume this one for the TMS570LS043 is applicable, in section 2 (Initialization of the TMS570LS043x, 570LS5033x & RM42L432 Hercules ARM Cortex-R4). If the correct initialization sequence for TMS570LC4357 is different, please let us know.

 We tested changing the order of operations (PLL enabled either before or after peripherals are brought out of reset) but the results were the same. We are pending a test where we do all these changes but only release the clock after enabling peripherals and will keep you informed if this has any different result.

Theory 2: nRST Glitch / Insufficient nRST Pulse Width from the Lauterbach Probe
 This was ruled out via electrical testing: we monitored the nRST pin with an oscilloscope and the Lauterbach probe’s pulse width was 400ms, well above the 2000 ns threshold shown in the datasheet (section 6.4.2)

Theory 3: Interaction with the TMS570 Reset Controller and Warm Reset vs. Cold Reset Behavior
 PCR power-down registers (PSPWRDWNCLRx/PSPWRDWNSETx) maintained their configuration in between warm resets, but the values were not erroneous. I confirm it looks like from the PCR registers that the power domain was not powered-down prior to the reset or after it.

Theory 4: Errata GCM#58 — VCLK/HCLK Ratio
 At the point when peripherals are brought out of reset (and during the reset operation), the actual CLKCNTL register values are 01010100, i.e. VCLKR2 set to HCLK/2, VCLKR set to HCLK/2  and PENA in No reset state.

Theory 5: Lauterbach Probe JTAG/DAP Interaction During Reset
Probe isn’t polling registers from a live watch during the operation so this seems very unlikely. The processor is stopped and the probe is only sending a reset command when this happens (no data read from the probe, only a write to command the reset + nRST toggle)

We are starting to suspect it’s something in the interaction between tester rig and the MCU, as it does not appear to affect all our test bench setups (some benches appear to not have been affected by this intermittent issue while others do). There are some differences with the harnessing and the IOs feeding data to the MCU board (the MCU board themselves are identical). Do you have a theory on what kinds of test rig interaction could cause a peripheral lock-up? Like some transient feedback from one of the IO pins in particular or a latch-up condition? We suspected a problem with Vref transients, but are scratching our heads because we thought that would have caused a lock-up of multiple peripherals instead of an isolated one? FYI, GPIO ports (A and B) remain working fine, as well as DMA, zSPI, and similar others.