TMS570LC4357: TMS570LC4357 STC LBIST Diagnostics for STC1 segment 1

Hi Daniel,

I am checking your issue, and mean time could you please refer below e2e once to understand the testing of STC procedure:

(+) TMS570LC4357: WFI-Instruction not starting LBIST or interconnect self-test - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi Jagadish,

thanks for your reply. I've gone through the referenced thread, but there is nothing new to me. I assume that I've understood the STC LBIST procedure. As described in the TRM (SPNU563A) sec. 10.10, I execute a sequence of four runs for the STC1 diagnostic test:

1. Fault insertion on segment 0 with parameters INTCOUNT=1, RS_CNT=1, SEG0_CORE_SEL=0, STC_ENA=0xA, TPR=0xFFFFFFFF, SEGID_PLOAD=0, SCSCR=0x1A

2. Clearing the fail bits with parameters INTCOUNT=1, RS_CNT=1, SEG0_CORE_SEL=0, STC_ENA=0xA, TPR=0xFFFFFFFF, SEGID_PLOAD=0, SCSCR=0x05

3. Fault insertion on segment 0 with parameters INTCOUNT=1, RS_CNT=1, SEG0_CORE_SEL=0, STC_ENA=0xA, TPR=0xFFFFFFFF, SEGID_PLOAD=1, SCSCR=0x1A

4. Clearing the fail bits with parameters INTCOUNT=1, RS_CNT=1, SEG0_CORE_SEL=0, STC_ENA=0xA, TPR=0xFFFFFFFF, SEGID_PLOAD=0, SCSCR=0x05

For each run the LBIST is executed (as descibed in TRM 10.4) with context saving and executing wfi. Runs 1, 2 and 4 lead to the correct results in GSTAT and FSTAT as described in TRM 10.10. But for run 3 the FSEG_ID is still 0 after the CPU reset, which is contradicting the last sentence in in TRM 10.10 Step 4 saying "Check if the FSEGID bits in the STCFSTAT register are set to 01".

Please tell me if I'm doing wrong at some point.

Looking forward to get to know about your findings.

Best regards,
Daniel

Hi Daniel,

I will try to reproduce this issue at my end and will do debugging and let you know.

--
Thanks & Regards,
Jagadish.

Hi Jagadish,

any news on the issue?

Have you been able to reproduce it? If not (so if FSEG_ID actually turns to 1 in your experiments), could you please share your source code with me so that I can compare it with mine?

Thanks and regards,
Daniel

Apologies for the delayed response.

I will try to provide you an update as soon as possible.

Hi Daniel,

Apologies for the delayed response, currently i am lack of hardware(TMS570LC4357) now. I am trying alternatives. In mean time i would suggest you to refer our internal AI response also once, which can access all our e2e's as well documentations, here are suggestions from it.

1. Literature Bug Status on STCSEGPLR / FSEG_ID

Based on the E2E thread you referenced (ticket ~2020), TI acknowledged that the SEGID_PLOAD field in STCSEGPLR is effectively ignored by hardware when selecting segment 1 for preload during the STC1 diagnostic test — the FSEG_ID in STCFSTAT always reads back 0b00 regardless of the written value. As of the information available to me:

• This was identified as a documentation/silicon issue on the TMS570LC4357.
• Whether a formal errata entry or TRM revision (beyond SPNU563A) has been published to reflect this, I cannot confirm — you should check the latest errata document SPRZ411 (TMS570LC43xx Silicon Errata) on ti.com directly, as errata are updated independently of the TRM.

2. RS_CNT Register Field — Meaning of Bit 1 (Marked Reserved in TRM)

The RS_CNT field is located in STCGCR0 [bits 25:24] (2-bit field). The TRM (SPNU563A) documents:

From the E2E community discussion and silicon behavior observed by multiple users:

• Bit 1 of RS_CNT (i.e., RS_CNT = 0b10 or 0b11) appears to control whether the STC triggers a system-level reset (as opposed to a CPU-only reset). This is the behavior that causes your debugger connection to be lost — a system reset tears down the debug session.
• With RS_CNT = 0b01, only the CPU core resets, which preserves the debug connection and allows context restore via the debugger.
• Writing 0b10 or 0b11 likely triggers a full device reset (equivalent to a power-on reset or nRST assertion), which is why execution resumes immediately from the reset vector and the debugger loses its connection — it is not a "step-over" behavior but a hard reset.

Conclusion on RS_CNT bit 1: It is believed to select between CPU-only reset (bit1=0) and full system/device reset (bit1=1). Since it is marked reserved, TI does not guarantee this behavior across silicon revisions, and using 0b10/0b11 is not recommended for the diagnostic flow described in TRM sec. 10.10.

3. STC Configuration Register Write Order & Dependencies

Based on the TRM sec. 10.4 and 10.10 flow, the critical ordering constraints are:

1. Write STCGCR0 first (INTCOUNT, RS_CNT, SEG0_CORE_SEL) — this configures the test parameters before enabling.
2. Write STCTPR (TPR = 0xFFFFFFFF) — sets the time-out period; must be set before enabling.
3. Write STCSEGPLR (SEGID_PLOAD) — must be written before STCGCR1 is written with STC_ENA. This is the critical dependency: the preload segment register must be configured prior to triggering the enable.
4. Write STCSCSCR (SCSCR) — fault insertion / clear control; also before enable.
5. Write STCGCR1 last (STC_ENA = 0xA) — this is the trigger. Writing this register initiates the self-test sequence. No other STC register should be written after this point in the same run.

️ Key dependency: If STCSEGPLR is written after STCGCR1, the preload segment selection will be ignored. Always ensure STCSEGPLR is written and stable before asserting STC_ENA.

Additionally, between consecutive runs (e.g., your 4-run sequence):

• After each CPU reset and context restore, all STC registers must be re-written from scratch — they do not retain their values across the CPU reset triggered by RS_CNT=1.
• The order above must be repeated for each run.

--
Thanks & regards,
Jagadish.