Renesas RA Family RA4 Quick Design Guide
R01AN5988EU0100 Rev.1.00 Page 24 of 51
Jul.21.21
6.11 Determining the Reset Source
The RA4 MCUs allow the user to determine the reset signal generation source. Read RSTSR0, RSTSR1,
and RSTSR0 to determine which reset was the source of the reset. Refer to the Hardware User’s Manual
section “Determination of Reset Generation Source” for the flow diagram.
The following sample code shows how to determine if a reset is caused by Software Reset, Deep Software
Standby or Power-On Reset using CMSIS based register structure in Renesas FSP.
/* Deep Software Standby Reset */
if(1 == R_SYSTEM->RSTSR0_b.DPSRSTF)
{
/* Do something */
}
/* Power-on Reset */
if(1 == R_SYSTEM->RSTSR0_b.PORF)
{
/* Do something */
}
/* Software Reset */
if(1 == R_SYSTEM->RSTSR1_b.SWRF)
{
/* Do something */
}
7. TrustZone Support
7.1 Implementation of Arm TrustZone Technology
Some RA4 MCUs, such as RA4M2 and RA4M3, include Arm TrustZone (TZ) security features. For full
details of TZ implementation, please refer to Arm documentation (
https://developer.arm.com/ip-
products/security-ip/trustzone) or the appropriate Hardware User’s Manual.
Arm TZ technology can create separations in the memory map within the MCU and therefore separate the
application into Secure and Non-Secure partitions. Secure applications can access both Secure and Non-
Secure memory and resources. Non-Secure code can access Non-Secure memory and resources as well as
Secure resources through a set of so-called veneers located in the Non-Secure Callable (NSC) region. This
ensures a single access point for Secure code when called from the Non-Secure partition.
The FSP configures the MCU to start the secure application upon reset. The security state of the CPU can
be either Secure or Non-Secure. The MCU code flash, data flash, and SRAM are divided into Secure (S) and
Non-Secure (NS) regions. Code flash and SRAM include a further region known as Non-Secure Callable
(NSC). These memory security attributes are set into the non-volatile memory via SCI or USB boot mode
commands when the device lifecycle is Secure Software Debug (SSD) state. The memory security attributes
are loaded into the Implementation Defined Attribution Unit (IDAU) peripheral and the memory controller
before application execution and cannot be updated by application code.