This code example checks RAM Retention mode after External Reset occurs.
The device used in this code example is:
The board used for testing is:
- TRAVEO™ T2G Cluster 6M Lite Kit (KIT_T2G_C-2D-6M_LITE)
The TRAVEO™ T2G MCU has a retention function for SRAM (Static Random-Access Memory), but after an external reset using the XRES_L pin occurs, the SRAM values cannot be retained correctly because the write buffer of the SRAM is not subject to retention. This example shows how to retain the SRAM value even after the MCU is reset by an external device.
SRAM Interface
- Optional memory size: 640 KB
- AXI bus interfaces:
- In the fast clock domain for the CM7 CPUs
- AHB-Lite bus interface:
- In the slow clock domain for all bus masters (CM0+ CPU, Crypto, P-DMA, M-DMA, debug interface, and optional external bus master). The slow bus infrastructure combines the bus masters in the slow clock domain.
- Programmable wait states.
- ECC function
- Single-bit error correction and double-bit error detection (SECDED)
- ECC error injection
- RAM retention function
- RAM power-up delay control
- Setting the power stabilization wait after switching on the SRAM power domain.
Reset System
TRAVEO™ T2G supports several types of resets that guarantee error-free operation during power up and allow the device to reset based on user-supplied external hardware or internal software reset signals. Resets have a broad scope and are generally aligned with power domains and global power modes. TRAVEO™ T2G has these reset sources:
- Power-on reset (POR) to hold the device in reset while the power supply is below the level required for initialization of startup circuits.
- Brownout detection reset (BOD) to reset the device if the power supply falls below the device specifications during normal operation.
- Over-voltage detection reset
- Over-current detection reset of the Active or DeepSleep regulator
- External reset (XRES_L) to reset the device using an external input
- Watchdog resets of the basic watchdog timer (WDT) and the multi-counter watchdog timers (MCWDT) to reset the device if the firmware execution fails to periodically service the watchdog timer
- Internal system reset to reset the device on demand using firmware
- Fault detection resets to reset the device if certain faults occur
- Clock-supervision resets to reset the device when clock-related errors occur
- Setting the power stabilization wait after switching on the SRAM power domain.
Internal System Reset
The internal system reset is a mechanism that allows software running on any of the CPUs or a connected debugger to request a system reset. The Cortex-M0+ and Cortex-M7 Application Interrupt and Reset Control registers (CM0P_SCS_AIRCR and CM7_0/CM7_1_SCS_AIRCR, respectively) can request a reset by writing a ‘1’ to the SYSRESETREQ bit of the respective registers.
Note that a value of 0x5FA should be written to the VECTKEY field of the AIRCR register before setting the SYSRESETREQ bit; otherwise, the processor ignores the write.
More details can be found in:
- TRAVEO™ T2G CYT4DN
This code example 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)
No changes are required from the board's default settings.
This code example uses software reset instead of an external reset using XRES_L pin. The example writes known data into SRAM Controller 1 and configures the GPIO to detect its falling edge as an interrupt. In the handler function of the interrupt, it flushes the content contained in write buffer of SRAM before issuing software reset. After the reset, data written to SRAM Controller 1 is read back and compared to the data written before software reset was triggered to check if the data is retained. All the procedures are implemented on CM0+ core.
SRAM configuration
- After in system initialization in main function is completed, cause for reset is get using Cy_SysLib_GetResetReason()
- If the cause of the reset is anything other than software reset, the reset cause is cleared by Cy_SysLib_ClearResetReason(), then known data is written to SRAM_CONTROLLER1 memory location (0x28040000 to 0x2807FFFF).
- If the cause of the reset is due to software reset, then SRAM is put in enabled mode. In enabled mode, the data written in SRAM_CONTROLLER1 memory location is read back to check if data is retained or not. The result is then printed on the terminal and the loop starts again.
GPIO Interrupt
The user button is configured as an interrupt source and controlled by PDL (Peripheral Driver Library) functions.
- Cy_GPIO_Pin_Init initialize user button 1.
- Cy_SysInt_Init() and Cy_GPIO_SetInterruptMask() initialize user button events that generate button interrupts whenever user button 1 is pressed. And NVIC_EnableIRQ() function enables it.
- Handle_GPIO_Interrupt() function is the button ISR where, first the write buffer of the SRAM is flushed. Then, SRAM Retention mode is enabled. This is done by setting CPUSS_RAM1_PWR_CTL_PWR_MODE field of RAM1_PWR_CTL register. Finally, __NVIC_SystemReset() issues software reset.
Miscellaneous settings
-
STDOUT setting
- Calling cy_retarget_io_init() function to use UART as STDIN / STDOUT
- Initialize the port defined as CYBSP_DEBUG_UART_TX as UART TX, defined as CYBSP_DEBUG_UART_RX as UART RX (these pins are connected to KitProg3 COM port)
- The serial port parameters become to 8N1 and 115200 baud
- Calling cy_retarget_io_init() function to use UART as STDIN / STDOUT
For this code example, a terminal emulator is required for displaying outputs. Install a terminal emulator if you do not have one. Instructions in this document use Tera Term.
After code compilation, perform the following steps to flashing 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.
-
Press user button 1 to trigger software reset and confirm that the messages are displayed on the UART terminal.
- Terminal output on program startup
- Terminal output on program startup
-
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
- AN220152 - How to Retain RAM Data in Reset Procedure and Low-Power Mode Transition in TRAVEO™ II Family
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: