MTU (Memory Test Unit) controls and monitors the testing, initialization, and data integrity check functions of various memories in the device. Each SRAM in the platform has some digital logic around it called SRAM Supporting Hardware (SSH). SSH is a hardware block that controls error detection and correction of internal memory, in-memory self-test (MBIST). Each SSH block provides a unified interface to control its various functions. There are multiple such SSH instances, each of which controls one or more different internal memory. The Memory Test Unit (MTU) in the AurixPlus platform provides a register interface to configure and control these different memory controllers.

MTU System View

Different IP modules in the system (such as CPU, LMU, CAN, etc.) may have one or more Srams inside. Each SRAM has its own SSH module around it, with its own registers (SRAM supports hardware (SSH) registers) and MBIST logic. Each SSH is connected to the MTU separately through an internal interface. The MTU itself is connected to the SPB bus, and each SSH register can be accessed through this SPB interface. Each SPB access is internally forwarded (and returned) by the MTU to (and from) the corresponding SSH.     

MTU Functional Features

1. Provide a unified interface to the internal SSH instance.

- MTU provides a unified register interface to control the operations and functions of each internal SSH instance.

- Various configurable test types for each SRAM in the system can be controlled via MTU.

2. Data initialization

- Each SRAM block in the system can be hardware initialized using MTU.

- Security-Sensitive storage can be automatically initialized to prevent data from being read out through the MTU.

3. Memory error correction and detection

- Memory error correction and detection of each SRAM in the system can be configured by MTU.

- Correctable and uncorrectable error detection.

- Address error detection.

4. SMU warning notification

- Three alarms (CE alarm, UCE alarm and ME alarm) from SRAM/SSH are sent to MTU and then forwarded to SMU by MTU.

Enabling the SRAM Support Hardware

Each SSH in the AurixPlus platform has an enabled bit associated with it in the MTU_MEMTESTx (x=0-2) register. SSH enabled MEMTESTi (i=0-2) register implemented in the AurixPlus platform. Each SSH's control register is accessible only when SSH is enabled (MTU_MEMTEST.MEMx_EN = 1). The only exceptions are the registers MCi_ECCS (i=0-95), MCi_ECCD (i=0-95), and MCi_ETRRx (i=0-95; x=0-4), MCi_ERRINFOx (i=0-95; x=0-4), MCi_ALMSRCS (i=0-95), and MCi_FAULTSTS (i=0-95)(in each SSH instance), which at any time allow easy run-time access to ECC features, namely these specific registers (i.e. ECCS, ECCD, ETRRx, ERRINFOx, ALMSRCS, and FAULTSTS) can read and write only if the MTU clock is enabled through the MTU_CLC register. All other registers of SSH can be accessed only if SSH is enabled through the MEMTEST register, otherwise MTU will return an SPB error. For some SSHS, enabling or disabling SSH through the MEMTEST register may cause all or part of memory to be automatically initialized, depending on the configuration. This automatic initialization can take hundreds of clock cycles to complete. During this period, SSH registers cannot be accessed (even registers that are not normally required to enable SSH), and any register access to running auto-initialized SSH will result in an SPB bus error. Note that the clock input of the module containing the SRAM must be enabled through the CCU register before any SSH register can be accessed through the MTU. Apart from this CCU clock configuration, there is no need to enable the module clock (for example, using the CLC register) to access the SSH register. 

Note：

1.    When SSH is enabled, memory access is temporarily unavailable. When a memory is being tested, the software should block functional access to that memory (for example, when testing the CPU's local memory, the CPU should be idle, or executing from other memory).

2.    Properly performing an SSH operation (e.g. a MBIST test) requires that both the MTU and the module containing the memory under test are operable during an SSH operation (e.g. a test). When SSH is enabled, the reset of the module containing the memory under test can cause unexpected behavior. Software must be aware that when SSH is enabled, events such as application resets, module resets, alternate entries, clock frequency changes, etc. are not triggered. For example, a module reset may cause the module to try to access SRAM normally after the reset while SSH is still enabled (and therefore functional access is disabled), such a scenario must be avoided with software.

3.    When the module is reset, if the communication between MTU and SSH is in progress (such as SSH register read or write), the communication is aborted and a bus error is triggered immediately on the SPB within a few cycles without any timeouts. Only ongoing reads and writes may be disrupted, and future communications will not be affected.

4.    If an invalid SSH register is accessed (for example, a register that does not exist in an SSH instance, or an SSH instance that does not exist), this will result in a bus error on the SPB.

Security-Sensitive Memories and AutoInitialization

For the TC3XX platform, the following memory is considered Security-Sensitive memory.

1.    CPUx_DMEM(x = 0 - 5) - Only the cache part of the memory is considered security sensitive.

2.    CPUx_DTAG(x = 0 - 5)

3.    CPUx_PMEM(x = 0 - 5) - Only the cache part of the memory is considered security sensitive.

4.    CPUx_PTAG(x = 0 - 5)

For the Security-Sensitive memory, the MTU must prevent the memory from being read or written over SSH. For secure applications, Security-Sensitive memory can be automatically initialized to erase existing content. This is controlled by the PROCONRAM register in the DMU.

If PROCONRAM.RAMIN = 00, 01 or 10 then automatic memory content initialization is enabled. PROCONRAM. configures whether the initialization is triggered by cold resets, warm resets or both.In these modes, an automatic initialization of security-sensitive memories is also triggered whenever the corresponding MTU_MEMTEST.MEMx_EN or MTU_MEMMAP is changed (i.e. The corresponding SSH is enabled or disabled or if memory map mode is changed). The MEMSTATi (i=0-2) register bits indicate whether an automatic data initialization of Memory x has been triggered by a change of state of MEMTEST.MEMx_EN or MTU_MEMMAP and the initialization sequence has not yet completed. If a MEMx_AIU bit in a MEMSTAT register is set, this means that Autoinitialization for that memory is still underway. The SSH is enabled only after, and disabled before the Auto-initialization starts. The software can wait for the Auto-initialization to be completed by polling this bit.

If PROCONRAM.RAMIN=11 then no automatic initialization of RAM content is performed on a reset and no automatic initialization of RAM content is performed when SSH modules are enabled or disabled with MTU_MEMTEST.MEMx_EN or MTU_MEMMAP register bits. This permits the use of the SSH by an application (E.g. for error injection, data modification or runtime memory testing) without unwanted corruption of memory content.

SRAM Support Hardware (SSH) Operation

Starting a Memory Test Sequence

Each memory test is started by writing the corresponding SSH register MCONTROL.START bit. Before enabling the MCONTROL.START bit, the configuration registers MCi_CONFIG0 (i=0-95) and MCi_CONFIG1 (i=0-95) need to be configured correctly.

1.   CONFIG0.ACCSTYPE specifies the type of access (read/write) that will be performed on each single address of the current content.

2.   CONFIG0.NUMACCS Specifies the total number of accesses to a single address in the current content.

3.   CONFIG1.ACCSPAT Specifies the access mode.

4.   CONFIG1.AG_MOD specifies that SSH uses a complex addressing scheme.

5. CONFIG1.AG_MOD specifies that the configuration test is noninvasive. When using noninvasive tests, MSTATUS.FAIL is not fixed, and the software must check whether the ECCD, ETRR, and ERRINFO registers detect any errors during the test.

Memory test completion is identified by MSTATUS.DONE=1. If the test fails, the MSTATUS.FAIL bit is raised. Note: If the test sequence stops testing due to an intermediate fault, MSTATUS.DONE will not be set to 1.

Memory Test Done Interrupt

The MTU provides an interrupt to the interrupt router (IR). The interrupt signifies the completion of all running tests. The reset value of this signal is high. When a test on any SRAM is started, this signal goes to low. On completion of all on-going tests, this signal again goes high, and this rising edge triggers the interrupt.

Getting Detailed Memory Test Results

The MSTATUS.FAIL and MSTATUS.DONE (can be polled from the MTU itself via MEMDONEi (i=0-2) register) bits provide a general pass/fail information and test completion status.

If MCONTROL.FAILDMP = ‘1’, the test stops after a failure and the fail information is immediately available for dump. MSTATUS.FDA (fail dump available) is set in this case. Any dump information has to be polled from registers RDBFL and ETRR(0). RDBFL contains the fail bit map and ETRR the failed address.

Reading MSTATUS and the RDBFL(n-1) registers with MSTATUS.FDA = ‘1’ will reset MSTATUS.FDA back to ‘0’. A consequent setting of MCONTROL.RESUME will resume the interrupted test sequence.

The RANGE register can be used to run consecutive tests on constantly shifted memory ranges so that in the end the complete memory has been analyzed.

Error Injection During Memory Tests.

l  For a non-destructive test, an error in the data can be introduced by programming a word with wrong ecc before the test, via the ECCMAP bits.

l  During a destructive march test, it is possible to inject data errors via the RANGE.INJERR bit. When this bit is set (and RANGE.RAEN = 1), then the RANGE.ADDR field is taken as a pointer to a physical SRAM location, to which write accesses during the test are not executed. Software can then write a particular value (i.e. using single SRAM write access using the RDBFL register) before a march test, and then run the test with RANGE.INJERR and RAEN = 1.

l  Data Error：

1.    The test then runs over the full memory, and on the address corresponding to RANGE.ADDR, writes are not executed. This results in mismatch of the expected data during the test, resulting in a FAIL.

2.    With errors injected, all normal diagnostics and notifications can be tested- that is, alarms are triggered, errors are tracked in the ETRR/ERRINFO during a non-destructive test.

3.    During a march test, FAIL bit is set, and when FAILDUMP = 1, the fail bitmap is obtained and FDA is set.

4.    The fail bitmap is simply (Expected data pattern) XOR (Actual data pattern).

l  Address errors are triggered during the test by simply setting SFLE bit to 1. Note that this will trigger an address error from each address, and during a non-destructive test, result in the ETRR/ERRINFO getting filled with address errors.

Filling a Memory with Defined Contents

The SSH can be used to fill a memory range or a complete memory with a defined pattern very fast, i.e. one write access per cycle with the full memory data width, using the MCONTROL.DINIT bit. For this, it has to be ensured that MCONTROL.SRAM_CLR = 0.

Before setting the MCONTROL.DINIT, the software should first fill the RDBFL register with the desired bit pattern (please refer to the MCi_RDBFLy (i=0-95;y=0-66)). It is not mandatory to have a valid ECC code in this pattern.

Next, the RANGE register needs to be set with the memory range into which the pattern needs to be filled.

Next, the MCONTROL.DINIT needs to be set, and then the MCONTROL.START bit should be set to start initializing the RAM. The software should then clear the MCONTROL.START. When MSTATUS.DONE bit is set by the hardware, the memory filling operation is complete.

This method of SRAM initialization using the DINIT bit is not supported for certain SRAMs. These exceptions are mentioned in the product specific appendix chapter.

Initializing SRAMs

Using the MCONTROL.SRAM_CLR bit, it is possible to initialize the complete SRAM. This is supported for all SSHs and SRAMs.

l  For this operation, enable the SSH (MEMTESTx.MEMxEN = 1), and: (Note that this will trigger an UCE alarm. Therefore, the alarm reaction may need to be disabled before. Software can set ALMSRCS.OPENE before)

l  Set the MCONTROL.SRAM_CLR.

l  Start the initialization using MCONTROL.START.

l  Wait for MSTATUS.DONE   to be reset and clear the MCONTROL.START.

l  Wait for the end of the initialization by polling the MSTATUS.DONE bit.

l  Clear the MCONTROL.SRAM_CLR and leave the test mode (MEMTESTx.MEMxEN = 0).

With this initialization, the complete SRAM will be filled with ECC-correct zero value. Clear the UCERR and OPERR flags set due to this operation. Re-enable ALMSRCS.OPENE if it was disabled before the test.

Reading a Single Memory Location

SSH can also be used to read the content of a single word. The RDBFL register stores the content of a complete memory word, so it can read all memory bits, including ECC or parity bits.

The necessary steps are:

    1. Enter memory test mode

    2. Initialize registers，RANGE := RAEN = 0 (range disabled = single address) & address to be read，CONFIG0 := 1001H (NUMACCS = 1H, ACCSTYPE = 01H (read))CONFIG1 := 0000H (linear mode, non inverted pattern)

    3. MCONTROL := 4009H (FAILDMP = 0, direction up, start): Start read operation. MSTATUS.DONE will be cleared now.

    4. MCONTROL := 4008H (clear START)

    5. Wait for MSTATUS.DONE to be set again (Poll the corresponding bit in the MEMDONEi (i=0-2) register).

    6. Read RDBFL register

    7. Leave memory test mode

    8. Clear the UCERR and OPERR flags set due to this operation.

Writing to a Single Memory Location

The SSH can also be used to write the contents of RDBFL register to a single memory location. RDBFL holds the contents of a complete memory word and thus it is possible to write to all memory bits, including ECC or parity bits. The necessary steps are:(Note that this will trigger the UCE alarm. Therefore, the alarm reaction may need to be disabled before)

1.  Enter memory test mode

2.  Initialize registers

3.    RDBFL := write data，RANGE := RAEN= 0 (range disabled = single address) & address to be written to ，CONFIG0 := 1000H (NUMACCS = 1H, ACCSTYPE = 00H (write))，CONFIG1 := 0000H (linear mode, non inverted pattern)

3. MCONTROL := 4009H (FAILDMP = 0, direction up, start): Start write operation. MSTATUS.DONE will be clearednow.

4. MCONTROL := 4008H (clear START)

5. Wait for MSTATUS.DONE to be set again (Poll the corresponding bit in the MEMDONEi (i=0-2) register).

6. Leave memory test mode

7. Clear the UCERR and OPERR flags set due to this operation.

Alarm Handling after Reset

When an alarm occurs, the system may perform a reset. The Alarm status bits in the ECCD register (i.e. ECCD. CERR, UCERR and MERR) are cleared after an application reset. However, the error status bits (i.e. ETRR, ERRINFO and FAULTSTS registers) are still available until a power-on reset for diagnosis purposes - they can only be cleared by software and are reset only with a warm PORST.

The alarm itself is also cleared with an application reset. This prevents a single alarm creating a reset loop.

Safety Features

The safety features implemented in the SRAMs, SSH instances and the MTU are the following:

1. Error Detection and Correction Codes / Logic

2. Address Error Monitor

3. SRAM Mux Factor

4. Error Tracking Registers

5. Safety Flip-Flop implementation for critical register bits.

Example of MBIST detection

Program Steps：

1.    Enable MTU interfaces: CLC. DISR = 0, CLC.EDIS = 1.

2.    Clear SSH fault information: MCi_ECCD.TRC = 1(i:0-95).

3.    Clear the fault information about the SMU: Smu_ClearAlarmStatus.

4.    Disable the SMU alarm action: SMU AGiCFj = 0.

5.    Initializing SSH：

            1.    Disable ALMSRCS. MISCE and OPENE fault detection.

            2.    Configure MEMTESTi(i:0-2) to enable SSH.

            3.    Poll the MEMSTAT0 register and wait for the SRAM automatic initialization of SSH to complete.

            4.    Set CONFIG0 = 0x4005(NUMACCS = 4，ACCSTYPE = 5), CONFIG1 = 0x5008(ACCSPAT = 8, AG_MOD = 5)

            5.    Start SRAM Test, MCONTROL. START = 1.

            6.    Clear Start Flag，MCONTROL. START = 0。

            7.     Poll MSTATUS.DONE and wait for the SRAM test to complete.

            8.    Check the SERR, CERR, MERR, and EOV faults of the ECCD register.

            9.    Check the ERRINFO and ETRR registers to obtain fault information.

            10.  Clear the fault information. ECCD.TRC = 1.

ZC TC3XX SafetyFrame Product Introduction

The electrification and intelligent development of automobile electronic control system is becoming more and more complex, and the safety requirements of electronic and electrical architecture are becoming higher and higher. Through HARA analysis of road vehicle application scenarios, more and more attention is paid to vehicle functional safety in order to degrade and decompose safety objectives and keep the possibility of hazard occurrence lower than the risk limit. In recent years, reference has been made to ISO 26262 for functional safety standards; Refer to E-GAS layering for the software shelf security architecture. In electronic and electrical systems, For the common Element, the SEooC (safety element out of context) approach is usually adopted for its design and development.

ZC launched SAFETY FRAME to provide customers with ASIL level decomposition consultation, FMEDA analysis process support, chip-level self-check safety mechanism development, SafetyFrame configuration and software integration and other full-process functional safety services.

SAFETY FRAME consists of 3 components: the internal module self-checking test component of MCU (i.e. SF.MCU), the driver component of SBC's hardware security mechanism (i.e. SF.SBC), and the safety architecture component (i.e. SF.Architecture). The core module of SF.Architecture is Test Manager, which is used for the scheduling management of Safety Library for MCU and SBC, including Safety Wdgm, scheduling of Safety SBC/ASIC driver modules, and interfaces with application layer PFC (Program Flow Check), etc. SF.MCU contains 3 major modules:

l  TestLib-- Implementation of MCU chip module inspection.

l  DriverLib-- Implements the MCU chip module driver.

l SwLib-- Interfaces such as digital signature database and end-to-end protection database are commonly used by users.

In the principle of software modular layering, Function Controller and Monitoring Controller are implemented by SF.MCU and SF.SBC, respectively. It is also deployed at EGAS Level2 and Level3 levels, taking into account the application requirements of program flow monitoring and shutdown path design.

Software Architecture

The functional safety modules implemented by SafetyFrame products include: Test Manager module, LBIST Test module, MBIST Test module, PFlash Test module, MCU Firmware Test module, Register Test module, DMA Test module, SRI Error Handling module, MONBIST Test module, Mcu Register Monitor module, Register Monitor Test module, Evadc Test module, Interrupt monitor Test module, Clock Plausibility Test module, DAM Test module, Convctrl Test module, CPU Internal BUS Test module, STM Test module, GTM TIM Clock Test module, Gtm IOM Alarm Test module, Gtm Tom Tim Test module, Port Test module, GptTst module, PMS configuration module, DTS Configuration module, OSC Clock Monitor module, SMU Error Handler module, SMU Software Alarm Drv module, IR FFI Control module, GTM IOM Configuration module, ERU Configuration module, TLF35584 Driver module, TLF35584 Error Handler module, E2E protection module, Safe Watchdog Manager module, Safe Watchdog Interface module, Safe Internal Watchdog module, Safe SBC Watchdog module.

SafetyFrame products for the TC3XX MTU module mentioned in this article to implement the memory self-check MBIST module, as well as register self-check  RegMonTst module, the module implements the following safety mechanism.

Click to download the product manual