This code example shows how to configure the fault subsystem and describes its operation.
The device used in this code example (CE) is:
The board used for testing is:
- TRAVEO™ T2G Cluster 6M Lite Kit (KIT_T2G_C-2D-6M_LITE)
In this example, a correctable error correction code (ECC) error is injected into the memory, causing a fault.
Fault Subsystem
The fault subsystem contains information about faults that occur in the system. The subsystem can cause a reset, give a pulse indication, or trigger another peripheral. The TRAVEO™ T2G platform uses a centralized fault report structure. The centralized nature allows for a system-wide, consistent handling of faults, which simplifies software development as follows:
- Only a single fault interrupt handler is required
- The fault report structure provides the fault source and additional fault-specific information from a single set of Memory Mapped Input/Output (MMIO) registers; that is, no iterative search is required for the fault source and fault information
- All pending faults are available from a single set of MMIO registers
The fault subsystem captures faults related to, but not limited to:
- MPU/SMPU/PPU protection violations
- Peripheral-specific errors
- Memory controller specific errors, such as SRAM controller ECC errors, flash controller “read-while-program”, and ECC errors
- Processor tightly-coupled memory (TCM) ECC errors
- Timeout errors
Note that some of the above faults also result in errors on the bus infrastructure. These faults are communicated in two ways:
- As a bus error to the master of the faulting bus transfer
- As a fault in a fault report structure. This fault can be communicated as a fault interrupt to any processor in the system. This allows fault handling on a processor that is not the master of the faulting bus transfer. It is useful for faults that cause the master of the faulting transfer to become unresponsive or unreliable
The fault subsystem only captures faults. It does not take any action to correct it.
More details can be found in:
- TRAVEO™ T2G CYT4DN
This CE has been developed for:
- TRAVEO™ T2G Cluster 6M Lite Kit (KIT_T2G_C-2D-6M_LITE)
Figure 1. KIT_T2G_C-2D-6M_LITE (Top View)
This design consists of one User LED1. ECC correctable errors can be generated by using CPUSS ECC injection mechanisms. For this purpose, the CPUSS is configured to cause an ECC error, which is detected and handled by the fault system. Depending on the configuration, an interrupt is caused and processed by the corresponding fault handler, or the system freezes and requires a reset.
STDIN / STDOUT setting
Initialization of the GPIO for UART is done in the cy_retarget_io_init() function.
- Initialize the pin specified by CYBSP_DEBUG_UART_TX as UART TX, the pin specified by CYBSP_DEBUG_UART_RX as UART RX (these pins are connected to KitProg3 COM port)
- The serial port parameters are set to 8N1 and 115200 baud
Cy_SCB_UART_Get() returns the user input from the terminal as received data.
LED control
Initialization of the GPIO port pin is done once in the Cy_GPIO_Pin_Init() function.
- Initialize the pin specified by User LED1 as output
The GPIO is controlled when a fault occurs as a handle_Fault_IRQ interrupt.
- The User LED1 blinks three times with a period of 500 ms, whose level is inverted by Cy_GPIO_Inv() and the interval is created by Cy_SysLib_Delay().
Fault detection after reset
To detect a fault, which requested a reset, a check on FAULT_STRUCT0->STATUS is performed during startup. If a fault caused the reset, corresponding information can be displayed using Cy_SysFault_GetFaultData().
ECC error injection
- All the fault initialization is done in init_Fault(). This function firstly clears the fault status by calling Cy_SysFault_ClearStatus(). Then enable capturing RAM ECC faults by calling Cy_SysFault_SetMaskByIdx() and Cy_SysFault_SetInterruptMask().
- if 'i' is pressed, the fault handling is configured to request an interrupt after detection by calling init_Fault(), which will call Cy_SysFault_Init(), using an interrupt configuration. Afterwards, function generate_ECC_SRAM0_correctable_error_by_parity() causes an ECC error to be injected and detected by the fault handler.
- if 'r' is pressed, the fault handling is configured to request a reset after detection by calling init_Fault(), which will call Cy_SysFault_Init(), using a reset configuration. Afterwards, function generate_ECC_SRAM0_correctable_error_by_parity() causes an ECC error to be injected and detected by the fault handler.
- In both cases, the parity values (normal and 1/2-bit error values) of the memory under test (g_Test) are calculated by the generate_Parity() function. This function calculates the parity value based on the word given as an argument which includes the address and value of g_Test calculated by make_Word_For_Sram_Ecc(). See TRM for details on how parity is calculated.
- Finally, init_Fault() sets up handle_Fault_IRQ() to be called as an interrupt handler when a fault occurs by calling Cy_SysInt_Init(), NVIC_SetPriority() and NVIC_EnableIRQ().
Before testing this code example:
- Power the board through the dedicated power connector
- Connect the board to the PC through the USB interface
- Build the project using the dedicated Build button
or by right-clicking the project name and selecting "Build Project" - To program the board, in the Quick Panel, scroll down, and click [Project Name] Program (KitProg3_MiniProg4)
For this example, a terminal emulator is required to display outputs and receive keys pressed. You can install a terminal emulator if you do not have one. In this example, Tera Term was used as the terminal emulator.
After code compilation, perform the following steps to flash the device:
-
Connect the board to your PC using the provided USB cable through the KitProg3 USB connector.
-
Open a terminal program and select the KitProg3 COM port. Set the serial port parameters to 8N1 and 115200 baud.
-
Program the board using one of the following:
- Select the code example project in the Project Explorer.
- In the Quick Panel, scroll down, and click [Project Name] Program (KitProg3_MiniProg4).
-
After programming, the code example starts automatically. Confirm that the messages are displayed on the UART terminal.
Figure 2. Terminal output on program startup
-
When
iis pressed, the fault information is displayed.Fiogure 3. Terminal output after fault interrupt
-
When
ris pressed, a reset is required. After reset, the fault information, which requested the reset, is displayed.Figure 4. Terminal output fault reset
-
You can debug the example to step through the code. In the IDE, use the [Project Name] Debug (KitProg3_MiniProg4) configuration in the Quick Panel. For details, see the "Program and debug" section in the Eclipse IDE for ModusToolbox™ software user guide.
Note: (Only while debugging) On the CM7 CPU, some code in main() may execute before the debugger halts at the beginning of main(). This means that some code executes twice: once before the debugger stops execution, and again after the debugger resets the program counter to the beginning of main(). See KBA231071 to learn about this and for the workaround.
Relevant Application notes are:
- AN235305 - Getting started with TRAVEO™ T2G family MCUs in ModusToolbox™
- AN219842 - How to use interrupt in TRAVEO™ II
ModusToolbox™ is available online:
Associated TRAVEO™ T2G MCUs can be found on:
More code examples can be found on the GIT repository:
For additional trainings, visit our webpage:
For questions and support, use the TRAVEO™ T2G Forum: