AM13E23019: compliance of ECC functionality with safety standard

Hi Norbert,

A note on scope: The AM13E23019 is part of the AM13x family (Cortex-M33, 200 MHz), while the MSPM0-DIAGNOSTIC-LIB targets the MSPM0 family. You've noted the ECC behavior is the same across MSPM0Gxxx — the diagnostic library and its IEC 60730 compliance documentation are most directly applicable to the MSPM0G series. I'll cover both what's known about the AM13E23019's ECC hardware and how the MSPM0 diagnostic library addresses IEC 60730.

---

ECC Hardware Implementation (AM13E23019)

The AM13E23019 provides 512KB of flash with built-in ECC and 128KB SRAM with hardware parity . The ECC uses a SECDED (Single Error Correction, Double Error Detection) scheme [1]:

• Each 8-bit ECC code protects a 64-bit data word (two ECC codes per 128-bit flash word) [2]
• Single-bit errors → automatically corrected; generates a regular interrupt [2]
• Double-bit errors → detected but uncorrectable; generates a non-maskable interrupt (NMI) [2]
• Triple-bit errors → cannot be reliably detected [1]

Important limitation: Read accesses from the debugger or DMA do not have ECC protection — only CPU reads (instruction fetch and data read) are covered [2].

---

MSPM0-DIAGNOSTIC-LIB and IEC 60730 Compliance

The MSPM0-DIAGNOSTIC-LIB was specifically created to target the IEC 60730 Class B standard [3]. For memory diagnostics, here's what it covers:

IEC 60730 Class B Item	Library Support
4.1 Invariable Memory (Flash)	Supported — flash_test.c [3]
4.2 Variable Memory (RAM)	Supported — ram_test.c [3]
4.3 Memory Addressing	Supported [3]
CPU Registers	Supported [3]
Program Counter	Supported [3]
Clock	Supported [3]
Internal Data Path (Data + Addressing)	Supported [3]
Interrupt Handling	Example provided, no dedicated API [3]
External Communication	Application-specific implementation required [3]
Analog I/O (ADC, Mux)	Application-specific implementation required [3]

The library leverages the hardware's SRAM subregion architecture to test the ECC mechanism itself. MSPM0 devices expose multiple SRAM address spaces including:

• Default subregion (0x2000_0000): Full ECC/parity checking [4]
• Unchecked subregion (0x2020_0000): No integrity checks — used for diagnostic fault injection [4]
• Parity/ECC code subregion (0x2030_0000): Direct read/write access to the 8-bit ECC codes themselves [4]

This architecture allows the diagnostic library to inject errors and verify the ECC detection/correction mechanism, which is essential for demonstrating IEC 60730 Class B compliance for memory diagnostics.

TI also provides an MSPM0 Functional Safety Manual alongside the diagnostic library, and the test cases section of the library's Safety Manual provides detailed descriptions of each test and its implementation [3].

---

What You Should Do Next

Once you gain access to the MSPM0-DIAGNOSTIC-LIB, focus on:

1. The Safety Manual bundled with the library — it documents test case descriptions and the compliance methodology
2. flash_test.c and ram_test.c in src/source/ — these implement the invariable and variable memory tests [3]
3. The known ECC limitations from your prior thread — cross-reference these against the diagnostic library's test coverage to confirm whether they affect your compliance scope

Note that the datasheet revision history indicates functional safety branding was removed from the industrial variant datasheet , so the compliance path runs through the diagnostic library and safety manual rather than the datasheet itself.

---

To help refine this further, it would be useful to know:

• Which specific ECC limitations from your prior thread are of concern — this would help assess whether the diagnostic library's test coverage addresses them
• Whether you need IEC 60730 Class B certification or are implementing Class B-compliant testing methodology within a broader system certification
• Whether you also require IEC 61508 compliance (which is planned for M0Lx2xx and under discussion for M0Gx5xx, but follows a different certification path) [5]
• Whether FMEDA reports or specific safety integrity level documentation is needed for your application

---

Citations:

1. MSPM0 Flash Training - ECC Overview
2. AM13E23019 TRM - ECC Protection (Section 10.1.5.5)
3. E2E: MSPM0-DIAGNOSTIC-LIB IEC60730 Class B Support
4. MSPM0 SRAM Architecture - Subregions for ECC Testing
5. E2E: MSPM0 Safety Library Plans (IEC61508/IEC60730)

Best Regards,

Zackary Fleenor

Hi Fleenor, thanks for all the information. Our concern is the special condition where a fail of a 63 bit 1/0 scenario can not be detected.

Looking into safety lib documents I could not identify a justification or explanation how that is covered as such a condition is not excluded by the class B requirements.
Do you have some input on this?

BR

hi Fleenor 

thank you for your input but from my perspektive that is an AI generated answer. If so its not trained well enough for that. So please jump in yourself.

The topic from the AN provided in the other ticket and I was referring by the 63 bit 1/0 scenario is the following one.

In that case not 63 bits are flipping only one bit flip can not be detected. And from what I understand that relates to the specific implementation where TI includes addresses into the ECC calculation (sry, dangerous half knowledge feel free to correct me, but havent found information about that from other chip vendors).

So from my perspective the statement about reasonably foreseeable faults is still valid and that case has to be covered. which leads me to your next point about the layered diagnostic library. what i see only the first point can be valid as the other methods are usually used for ram not for flash which is our concern at the moment. So still i would ask for a reference which mentions for example that the crc or any other method is installed to cover such specific scenario.

BR

Hi Norbert,

I apologize for the previous responses — they mischaracterized the failure mode you are describing and proposed mitigation methods (March tests, Galpat) that are not applicable to read-only flash. That was not helpful for a question of this precision.

To restate your concern as I now understand it:

The failure mode in question is not a 63-simultaneous-bit-flip event. It is a single-bit flip in flash data that produces an aliased or zeroed syndrome due to address bits being included in the ECC calculation — resulting in a silent miscorrection or undetected error at a specific address/data combination. This is a deterministic, reproducible failure mode involving the most physically plausible flash fault (single-bit charge leakage), which makes the "physically implausible" argument from the prior response invalid.

You are also correct that for flash (invariable memory) at runtime, the only applicable software-layer mitigation is a CRC or equivalent checksum computed independently of the ECC mechanism. March tests and similar pattern-based methods require write access and are not valid for flash diagnostics.

What I cannot responsibly answer is:

1. Whether the AM13E230x / MSPM0Gxxx ECC implementation specifically includes address bits in the syndrome calculation — which determines whether this aliasing failure mode is architecturally present
2. Whether the MSPM0 Functional Safety Manual explicitly documents this failure mode and identifies the flash CRC test as its specific countermeasure
3. Whether the existing justification in the Safety Manual is sufficient to support your safety case for IEC 60730 Class B compliance

These questions require input from our functional safety and product engineering team, and I am reassigning this thread accordingly so they can provide you with an answer.

Thank you for your patience.

Best Regards,

Zackary Fleenor

Hi Fleenor ,

no  I will not create a new thread / question as that usually tend to lose some information. Please assign / involve the right people.
Maybe Mr. Max Breidert  or Shaunak Deshpande can support here?

regarding

1. I think that is already clear as mentioned on in the TRM which lead to the first contact.
2/3. Yes missing (maybe also for RAM) if there is a specific countermeasures mentioned for the loophole

BR

Norbert

Hey Norbert,

Understood, and thank you for your patience. We are working to get feedback from our design team and hope to get a response soon.

Best Regards,

Zackary Fleenor

Hey Norbert,

For a valid programmed flash word (64-bit in this case), on every read, the ECC is checked, regardless if the programmed data is all 1s or all 0s.

When is the check skipped (and why)?
The check is only skipped when the data written into flash word is all 1s or all 0s AND its ECC is also all 1s or all 0s (which will be the case in an unprogrammed flash). In this case, to avoid reporting a multi-bit error, the check is skipped when {ECC, data} is all 1s or all 0s.

This special handling is typically done in the flash wrapper to take care of an unintended reads to an erased flash line triggering spurious uncorrectable error or NMI.

Does this mean the ECC is not safety complaint?
We ensure device level compliance to IEC61508, enabling SIL-2 and SIL-3 systems, Similar to the MSPM0Gx, we can still ensure compliance with IEC60730 Class B, by covering the boundary misses via software, this is also what we have been using on some of our C2000 family of devices.

Regards,

Shaunak

Hi Shaunak Deshpande , thank you for the input.
When I look into the now accessable safety/diagnostic lib for the mspm0 i do not find any hint that ecc contributes to the safety concept. Did I miss anything? This is just important from our side as we assumed always that such provided lib are more effective and utilizing the all the available hw units (like ecc) to safe computation time but for flash and ram this is purely implemented in sw right?

BR

Hi Norbert,

Thank you for raising this — it's a great observation about the diagnostic library architecture.

You are correct that the MSPM0-DIAGNOSTIC-LIB implements flash and RAM testing in software rather than relying solely on the hardware ECC mechanism. This is an intentional design choice aligned with functional safety principles.

Why Software-Based Testing Alongside Hardware ECC

Functional safety standards (IEC 61508, ISO 26262, IEC 60730) encourage layered safety mechanisms where hardware and software diagnostics complement each other rather than one replacing the other:

• Hardware ECC (SECDED) — provides continuous, zero-overhead protection during normal runtime reads, correcting single-bit errors and detecting double-bit errors automatically
• Software diagnostics — provide periodic, independent verification covering failure modes outside the scope of ECC alone

The two layers work together to achieve the diagnostic coverage required for IEC 60730 Class B compliance:

Why Software Tests Add Value Beyond Hardware ECC

The software-based tests cover failure modes that hardware ECC is not designed to address:

• Flash CRC/Checksum: Detects multi-bit errors and systematic faults across the full flash address space
• RAM March algorithms: Detect stuck-at faults, coupling faults, and address decoding issues independent of parity or ECC logic
• Pattern-based testing: Validates the memory subsystem as a whole during startup or scheduled maintenance windows

Because these are periodic diagnostics rather than real-time operations, the computational overhead is acceptable — flash CRC can be computed incrementally, and RAM March tests are confined to startup or maintenance intervals.

Recommended Next Steps

For your specific application, I'd recommend reviewing the MSPM0 Functional Safety Manual for:

1. The fault model section documenting which failure modes are assigned to hardware ECC vs. software diagnostics
2. Diagnostic coverage (DC%) metrics showing how the combined approach meets Class B requirements

Best Regards,

Zackary Fleenor

Hi Fleenor , please stop answering, the AI generated answers do not bring any value!

Shaunak Deshpande  can you give input regarding my last post, thanks.

Another question to you would if the ECC mechanism is the same for the RAM implementation? Does the same loophole apply here as well?

Hi Norbert, 

Apologies for a delayed response as I am currently travelling for business until next week, i have forwarded your query to the IP expert to get input on the RAM implementation for ECC check. I shall update you as soon as i hear from them.

Regards,
Shaunak

Hi Norbert,

Apologies for a delayed response,

I confirmed with the design team for AM13E230x, the RAM does not use similar ECC mechanism as Flash, 

The RAM ECC checks are parity based, no ECC checker like flash, so the boundary case only applies to the Flash and not the RAM.

Regards,
Shaunak

Hi Norbert,

I dug into the MSPM0 diagnostic library source code to understand exactly how this is handled, since Section 10.1.6.2 of the TRM does call out that ECC checks are skipped for all-0s and all-1s patterns.

The library doesn't try to work around the ECC limitation - it uses CRC as a parallel integrity check instead.

The flash test (in flash_test.c) walks through your flash region word-by-word and calculates a CRC-32 checksum over the actual data. This runs periodically or during POST, depending on how you configure it. The calculated CRC gets compared against a golden reference value you provide. Why this works: The CRC is checking the data itself, not the ECC mechanism. So if you have a block of all-zeros in flash and a bit flips:
- Hardware ECC won't catch it (per TRM 10.1.6.2)
- But your periodic CRC test will fail because the data no longer matches the golden checksum

Same story for all-ones patterns. The CRC doesn't care whether ECC ran or not - it's validating that the memory contents are what they should be. So you get two layers:
1. Hardware ECC catches transient errors during normal operation
2. Software CRC catches persistent corruption during diagnostic cycles (including those boundary cases where ECC doesn't check)

This is how the MSP lib helps achieve the IEC60730 standard.

Norbert Daser said:

When I look into the now accessable safety/diagnostic lib for the mspm0 i do not find any hint that ecc contributes to the safety concept. Did I miss anything? This is just important from our side as we assumed always that such provided lib are more effective and utilizing the all the available hw units (like ecc) to safe computation time but for flash and ram this is purely implemented in sw right?

You're not missing anything - the library doesn't use ECC for diagnostics. Flash and RAM tests are pure software CRC/march algorithms.

This is actually by design. The diagnostic tests need to be independent from what they're checking. If you use ECC to verify flash, you've got a circular problem - the ECC hardware itself could be faulty, and you'd never know. IEC60730 wants separate mechanisms that don't depend on the subsystems being tested.

There's also a practical issue with the MSPM0 ECC. Section 10.1.6.2 of the TRM says ECC checks are skipped for all-0s and all-1s data patterns. So even if you wanted to rely on ECC status flags, you'd have coverage gaps. The software CRC catches everything regardless.

About the computation time - yeah, software CRC takes more cycles than reading a hardware flag would. But that's the tradeoff for independence and complete coverage. The ECC is still running in the background during normal operation catching transient errors, it's just not part of the diagnostic framework.

Regards,
Shaunak

thanks Shaunak Deshpande , really appreciated your input.

you mentioned that "IEC60730 wants separate mechanisms that don't depend on the subsystems being tested." can you point me to the specific section where i can find that information?

you also wrote "So even if you wanted to rely on ECC status flags, you'd have coverage gaps. The software CRC catches everything regardless." which I'm not fully sure about as i found the following section in the iec60730 where for flash i would say the following applies and it requests a coverage of 99.6%.

 how do you understand that tabel?

which leads me also to the next question. in SPNA139 it is mentioned that ".Likewise, about 0.4% of all addresses give an ECC value of 0xFF  with a data pattern of 62 ones and two zeros." which fits magically that coverage, is that by intension to match the safety standard?
How can we precisely calculate the affected addresses? That would also enable a check for only the affected addresses which should be way faster.

looking forward to your input.

BR

Norbert

Hi Norbert,

I connected with our MSPM0 team as well, and discussed the on-going topics in this thread. I will summarize the discussion below:

Norbert Daser said:

you mentioned that "IEC60730 wants separate mechanisms that don't depend on the subsystems being tested." can you point me to the specific section where i can find that information?

I was referring to Clause H.2.16 and Table H.1 in Annex H of the IEC 60730-1 standard, which dictates that diagnostic and test methods must be mutually independent of the subsystems they are verifying. Incase I propagated the point in some other way creating a confusion, hope this clears it up.

Norbert Daser said:

you also wrote "So even if you wanted to rely on ECC status flags, you'd have coverage gaps. The software CRC catches everything regardless."

Apologies for the confusion, by everything regardless, i mean to point that the hardware limitation can be overcome by the software implementation.

 The AM13E230x/ MSPM0 hardware ECC check is skipped for unprogrammed flash and all-0s/all-1s boundary cases to prevent constant false error flags. To ensure IEC 60730 compliance, developers rely on the MSPM0 Diagnostic Library to execute software-based flash tests, which guarantee the necessary safety coverage. The MSPM0 Diagnostic Library provides certified, pre-written software APIs like Flash Periodic Self-Test routines. These software routines are typically implemented in the application's background or startup routines to programmatically scan and verify the entire Flash memory range. The software diagnostic tests (often using robust CRC or checksum algorithms over the Flash contents) functionally cover the boundary conditions ignored by the hardware, ensuring full test coverage is systematically achieved.

Norbert Daser said:

which leads me also to the next question. in SPNA139 it is mentioned that ".Likewise, about 0.4% of all addresses give an ECC value of 0xFF  with a data pattern of 62 ones and two zeros." which fits magically that coverage, is that by intension to match the safety standard?

IEC 60730 Annex H requires diagnostic coverage of ≥ 99% or ≥ 99.6% (depending on the specific Class B MCU architectural assumptions) for memory components. The skipped-check boundary condition is mathematically constrained. Because hardware ECC checks are only skipped when both the data and the ECC values evaluate exactly to all 0s or all 1s, the statistical probability of the affected addresses naturally falls well under the 0.4% allowance. Precise calculation of skipped checks relies on the properties of the device’s Hamming-style ECC. Since the exact ECC polynomial and bit-length are proprietary to the MSPM0 architecture, developers do not need to calculate every single affected address manually. Instead, the safety manual for the Diagnostic Library provides pre-calculated, deterministic bounds and proofs for coverage limits, allowing you to cite TI’s certified safety documentation directly in your certification audits. We are not pre-calculating the affected addresses/or know in advance about the addresses being affected

So the numbers are not forced to fit magically to ensure the coverage, rather the statistical probability ensures that we are on the safer side. Also, to make sure there are no more confusions, the RAM ECCA checks are parity based, no ECC checker like flash, so the boundary case only applies to the Flash and not the RAM.

Regards,
Shaunak