TMS570LS3137: nERROR/ECC LED activates when calling a function from UART ISR

Hi Hasan,

I would suggest you verify which ESM bit got set. You can refer below e2e to understand how to verify these bits:

(+) TMS570LC4357: ESM High Interrupt occurs with no pending interrupt in ESMIOFFHR - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

We have one internal AI which can analyze all our internal database, and it is providing below suggestion, please refer this one as well:

---

## Root Cause Analysis

### The Core Issue: Uninitialized IRQ Stack Memory and ECC

The TMS570LS3137 uses **TCRAM (SRAM) with hardware ECC**. The ECC is computed and checked on every **64-bit (double-word) read**. If a memory location has never been written since power-on, its ECC bits are in an indeterminate state. Reading such a location will trigger an **ECC single-bit correction or double-bit detection error**, which asserts the `nERROR` pin and lights the ECC LED.

The key distinction in your observation is:

| Scenario | Behavior |
|---|---|
| Ring-buffer code **inlined** in ISR | No ECC error |
| Ring-buffer code in a **called function** | ECC error triggered |

This difference is explained entirely by **stack frame usage**:

- When the code is **inlined**, the compiler uses only the registers already allocated for the ISR's stack frame — no new stack region is touched.
- When `comp_pod_ring_buf_put()` is **called**, the compiler generates a new stack frame for that function. This pushes the link register (`LR`), possibly `r4`–`r11`, and local variables onto the **IRQ stack** at addresses that have **never been written before**. The subsequent function epilogue **reads back** those stack locations (to restore registers via `POP`/`LDMFD`), and if those addresses were never initialized with valid ECC, the read triggers an ECC fault.

> **In short: The function call causes a stack `PUSH` followed by a `POP`. The `POP` reads memory that was never ECC-initialized, triggering the fault.**

Increasing the stack size to `0x400` did not help because the problem is not *overflow* — it is that the **newly allocated stack pages were never written** (and thus have no valid ECC syndrome).

---

## Why the Application Continues Running

The TMS570 ECC logic distinguishes between:
- **Single-bit errors (correctable):** The SECDED hardware corrects the data and asserts `nERROR`, but execution continues. This matches your observation exactly — the LED lights, but the application keeps running.
- **Double-bit errors (uncorrectable):** These cause a data abort.

You are hitting **single-bit ECC errors on uninitialized TCRAM**, which are corrected in hardware but still assert `nERROR`.

---

## Solutions

###  Solution 1: Initialize the Entire IRQ Stack Region at Startup (Recommended)

The standard fix is to **write a known pattern to the entire IRQ stack** during startup, before any interrupts are enabled. This initializes the ECC for every address in the stack region.

HALCoGen-generated startup code (`sys_startup.c`) typically does this for the full SRAM via the `_memInit_` routine, but **it may not cover the IRQ stack region if it was recently enlarged or if the linker script was modified**.

Check your `sys_startup.c` for a call like:

```c
/* Initialize TCRAM ECC */
_memInit_();
```

And verify that the **entire IRQ stack region** (as defined in your linker `.cmd` file) falls within the range covered by `_memInit_`. If you enlarged the stack from `0x100` to `0x400` and adjusted the linker RAM boundaries, confirm that the new boundaries are reflected in the startup ECC initialization range.

---

###  Solution 2: Explicitly Zero-Initialize the Stack in Your Startup Code

Add an explicit stack scrub in your startup assembly or C startup code before enabling VIM/interrupts:

```asm
; In sys_startup.asm or equivalent
; Switch to IRQ mode and zero the stack
MSR CPSR_c, #0xD2 ; IRQ mode, IRQ/FIQ disabled
MOV r0, #0
MOV r1, #0
; ... fill IRQ stack region with STM/STMIA loop
```

Or in C (before `main()` or before enabling interrupts):

```c
extern uint32_t __IRQ_STACK_START__;
extern uint32_t __IRQ_STACK_END__;
uint32_t *p = &__IRQ_STACK_START__;
while (p < &__IRQ_STACK_END__) {
*p++ = 0xDEADBEEFU; /* any write initializes ECC */
}
```

---

###  Solution 3: Verify HALCoGen `_memInit_` Coverage

In HALCoGen-generated projects, open `sys_startup.c` and look for the TCRAM initialization block. It typically uses the **MINITGCR** and **MSIENA** registers to trigger a hardware memory initialization. Confirm:

1. The hardware init covers the full SRAM range including your stack.
2. The init completes (polls the status bit) **before** `vimInit()` or any interrupt enable.

---

###  Solution 4: Use `__attribute__((noinline))` Carefully / Restructure

This is a **workaround, not a fix**, but confirms the diagnosis: if you mark `comp_pod_ring_buf_put` as `__attribute__((always_inline))`, the ECC error disappears — because no new stack frame is created. You already observed this with manual inlining.

---

## Summary Checklist

- [ ] Confirm `_memInit_()` in `sys_startup.c` covers the **full IRQ stack** address range after your linker script change.
- [ ] Confirm memory initialization completes **before** `vimInit()` / interrupt enable.
- [ ] If using a custom linker `.cmd`, verify the IRQ stack section is placed in a region covered by the ECC scrub.
- [ ] Check TI's errata for TMS570LS3137 (SPNZ193) for any related silicon errata on TCRAM ECC initialization.

---

> ️ **Note:** This analysis is based on general expert knowledge of the TMS570LS3137 architecture, ARM Cortex-R4 ECC behavior, and TI ARM Compiler behavior, as this specific issue falls outside the scope of the EDA tool knowledge bases available to me. I recommend cross-referencing with the [TI E2E Community forums](https://e2e.ti.com) and the TMS570LS3137 Technical Reference Manual (SPNU489) for authoritative confirmation.

--
Thanks & regards,
Jagadish.