The BSP is responsible for getting the MCU from reset to the user's application. Before reaching the user's application, the BSP sets up the stacks, heap, clocks, interrupts, C runtime environment, and stack monitor.
All system clocks are set up during BSP initialization based on the settings in bsp_clock_cfg.h. These settings are derived from clock configuration information provided from the Configuration editor Clocks tab.
Clock configuration is performed prior to initializing the C runtime environment to speed up the startup process.
The BSP implements the required delays to allow the selected clock to stabilize.
The BSP will configure the CMSIS SystemCoreClock variable after clock initialization with the current system clock frequency.
System Interrupts
As Cortex-R ARM architecture, the Generic Interrupt Controller (GIC) handles exceptions and interrupt configuration, prioritization and interrupt masking. In the ARM architecture, the GIC handles IRQ and FIQ exceptions and receives the following interrupt types.
Private Peripheral Interrupt (PPI)
Shared Peripheral Interrupt (SPI)
Software Generated Interrupt (SGI)
SGI and PPI are core-related specific interrupts, and SPI is connected to interrupts from each peripheral. GIC has interrupt number (INTID) internally. SGI uses INTID 0 to 15, PPI uses INTID 16 to 31, and SPI uses INTID 32 or later.
Multiplex Interrupts
When multiplex interrupts are enabled, another interrupt can operated while one interrupt is operating.
If an interrupt occurs, it branches to BSP common handler and then to HAL interrupt handler. The user can choose whether to allow multiple interrupts in BSP common handler or in HAL interrupt handler.
There are two ways to enable it:
Enable in BSP properties
Multiplex interrupts are enabled system-wide
The behavior when multiplex interrupts are enabled in the BSP properties is as follows. Pink areas represent critical sections.
Behavior when multiplex interrupts are enabled in BSP
Enable in HAL module properties
Multiplex interrupts are enabled only on set HAL modules
The behavior when multiplex interrupts are enabled for only HAL1 of the two HAL modules in the HAL module properties is as follows. Pink areas represent critical sections.
Behavior when multiplex interrupts are enabled in HAL module
Note
If you enable Multiplex interrupts in BSP properties, it will be enabled even if you disable it in HAL module
External and Peripheral Interrupts
User configurable interrupts begin with slot 32 (SPI). These may be external, or peripheral generated interrupts.
The SPI is mapped along the Event Table, and the BSP allows the user to select only the events of interest as interrupt sources.
BSP Weak Symbols
The weak attribute causes the declaration to be emitted as a weak symbol rather than a global. A weak symbol is one that can be overridden by an accompanying strong reference with the same name. When the BSP declares a function as weak, user code can define the same function and it will be used in place of the BSP function.
Weak symbols are supported for ELF targets and also for a.out targets when using the GNU assembler and linker.
Note that in CMSIS system.c, there is also a weak definition (and a function body) for the Warm Start callback function R_BSP_WarmStart(). Because this function is defined in the same file as the weak declaration, it will be called as the 'default' implementation. The function may be overridden by the user by copying the body into their user application and modifying it as necessary. The linker identifies this as the 'strong' reference and uses it.
Warm Start Callbacks
As the BSP is in the process of bringing up the board out of reset, there are three points where the user can request a callback. These are defined as the 'Pre Clock Init', 'Post Clock Init' and 'Post C' warm start callbacks.
As described above, this function is already weakly defined as R_BSP_WarmStart(), so it is a simple matter of redefining the function or copying the existing body from CMSIS system.c into the application code to get a callback. R_BSP_WarmStart() takes an event parameter of type bsp_warm_start_event_t which describes the type of warm start callback being made.
This function is not enabled/disabled and is always called for both events as part of the BSP startup. Therefore it needs a function body, which will not be called if the user is overriding it. The function body is located in system.c. To use this function just copy this function into your own code and modify it to meet your needs. need to check
FSP Assert
When an assertion or error occurs, the user assert function will be called.
This function is weakly defined as R_BSP_FspAssert(), so it is a simple matter of redefining the function or copying the existing body from bsp_common.c into the application code to manage assertions or errors.
Note
This function is not called even in cases that would return FSP_ERR_ASSERTION when BSP_CFG_ASSERT is defined as 3 (When "Disable checks that would return FSP_ERR_ASSERTION" is set to "Assert Failures" option in the RZT Common configurations on the BSP tab).
C Runtime Initialization
If C Runtime is disabled, users must perform C runtime initialization themselves.
Register Protection
The BSP register protection functions utilize reference counters to ensure that an application which has specified a certain register and subsequently calls another function doesn't have its register protection settings inadvertently modified.
Do not recommend using R_BSP_SoftwareDelay () for strict wait time processing. The reason we do not recommend using this API is that the Delay Time may change depending on the memory area where the execution program is placed.
Implements a blocking software delay. A delay can be specified in microseconds, milliseconds or seconds. The delay is implemented based on the system clock rate.
/* Delay at least 1 second. Depending on the number of wait states required for the region of memory
* that the software_delay_loop has been linked in this could take longer. The default is 4 cycles per loop.
* This can be modified by redefining DELAY_LOOP_CYCLES. BSP_DELAY_UNITS_SECONDS, BSP_DELAY_UNITS_MILLISECONDS,
* and BSP_DELAY_UNITS_MICROSECONDS can all be used with R_BSP_SoftwareDelay. */
Implements Trigonometric math inline functions utilizing TFU hardware. These functions can calculate sine, cosine, arctangent and hypotenuse. The trigonometric library functions sinf(), cosf(), atan2f(), and hypotf() can be mapped to respective TFU functions by enabling TFU Mathlib property in FSP Configuration tool. Extended functions sincosf() and atan2hypotf() are also available when the TFU Mathlib property is enabled in the FSP Configuration editor.
TFU functions are not reentrant. Disable the TFU Mathlib property in Configuration editor if reentrant access to trigonometric library functions is required.
Note
Refer to the MCU hardware user's manual or datasheet to determine if it has TFU support.
Critical Section Macros
Implements a critical section. Interrupts with priority less than or equal to BSP_CFG_IRQ_MASK_LEVEL_FOR_CRITICAL_SECTION are not serviced in critical sections. Interrupts with higher priority than BSP_CFG_IRQ_MASK_LEVEL_FOR_CRITICAL_SECTION still execute in critical sections.
Variables placed in the following sections will be invalidated for caching.
To place the variables in these noncache sections, use the BSP_PLACE_IN_SECTION macro to define them. (e.g. uint32_t value BSP_PLACE_IN_SECTION(".data_noncache") = 1)
Data with and without initial values can be placed.
.data_noncache
Places noncache data for user applications
.dmac_link_mode
Place DMAC link mode descriptor
See Link Mode Example for how to place descriptors
.noncache_buffer
Places noncache data exclusively for each core without sharing between cores
This is only for the FSP driver, and it is not possible to place noncache data used by user applications
.shared_noncache_buffer
Place noncache data that can be shared between cores when multi-core processing
To prevent unexpected initialization of variables, define variables placed here only in the primary project
This is only for the FSP driver, and it is not possible to place noncache data used by user applications
Note
In EWARM, do not mix variables with and without initial values. A warning will occur. To avoid the warning, perform the following operations.
Explicitly define "0" even for variables without initial values. (e.g. uint32_t value BSP_PLACE_IN_SECTION(".data_noncache") = 0)
If you cannot explicitly define the value, you can prevent the warning from occurring by adding "--diag_suppress Be006" to Project Option -> C/C++ Compiler -> Extra Options.
FSPv3.0 or later, the memory layout will be changed as follows:
The address obtained by subtracting 0x80000 from the end address of the Mirror area of System SRAM is the start address of the noncache section.
e.g.)
For RZ/T2M, the end address of the Mirror area of System SRAM is 0x3020_0000, so the start address is 0x3018_0000.
For RZ/T2H CR52, the end address of the System SRAM is 0x1020_0000, so the start address is 0x1018_0000. (No mirror area)
For RZ/T2H CA55, the end address of the Mirror area of System SRAM is 0x1040_0000, so the start address is 0x1038_0000. (Virtual address by MMU)
The address obtained by subtracting 0x20000 from the end address of the Mirror area of System SRAM is the start address of the .shared_noncache_buffer.
e.g.)
For RZ/T2M, the end address of the Mirror area of System SRAM is 0x3020_0000, so the start address is 0x301E_0000.
For RZ/T2H CR52, the end address of the System SRAM is 0x1020_0000, so the start address is 0x101E_0000. (No mirror area)
For RZ/T2H CA55, the end address of the Mirror area of System SRAM is 0x1040_0000, so the start address is 0x103E_0000. (Virtual address by MMU)
In a multi-core project, the start address is the address aligned with 0x20 from the end address of the noncache section used in the primary.
e.g.)
For RZ/T2H CR52, if the primary uses up to 0x1018_0050, the secondary start address will be 0x1018_0060.
Memory attributes
Attributes and Regions can be set in the CPU-MPU/MMU of the BSP property.
Attribute: Select cacheability settings.
Region: Define the address and other information that specifies the attribute.
For example, in the SystemRAM area, the cacheability settings shown below are used:
Attribute: Set Attribute 1 to Normal memory, Inner/Outer Write-Through non-transient, R/W Allocate.
Region:
Set the starting address (Base) and the ending address (Limit) of the memory area.
Set the Shareability field to Non-shareable and the Attribute Index to Attribute1 to enable cache.
The configuration values are generated as macro values in bsp_mcu_cpu_memory_cfg.h and are reflected in the ARM core registers in the startup code.
Note
In the case of the write-back policy, the write operation basically updates data in the cache, and data updates to main memory are performed according to the state of the cache. If it is necessary to explicitly update data to main memory, a separate clean operation must be performed. Please use the following BSP API functions for the clean operation:
- R_BSP_CacheCleanAll
- R_BSP_CacheCleanInvalidateAll
If you need to invalidate the cache (clean data from the cache) in addition to the clean operation, use the following BSP API functions:
- R_BSP_CacheCleanRange
- R_BSP_CacheCleanInvalidateRange
When using Cortex-R52 as the secondary core on the RZ/T2H for multi-core operation, set Cortex-R52 CPU0 ATCM via AXIS (0x20000000 - 0x2007FFFF) and Cortex-R52 CPU1 ATCM via AXIS (0x21000000 - 0x2107FFFF) to Device Memory.
Memory Access
In the CPU-MPU configuration, it is feasible to configure memory attributes tailored to specific applications. For instance, the Normal memory attribute facilitates high-speed access, rendering it suitable for RAM access and instruction execution. Conversely, the Device memory attribute enforces strict execution order, making it apt for peripheral register access and flash memory write operations.
Moreover, the system is capable of detecting and reporting faults in the event of unforeseen access to each memory attribute.
A comprehensive understanding of these specifications is crucial in preventing improper memory access and unintended aborts. Below are some examples of how each memory attribute can be utilized. For detailed information, please consult the Technical Reference Manual and Architecture Reference Manual published by ARM.
In cases where data is written to flash memory with Write Enable command, it is imperative that the sequence of execution adheres strictly to the programmed order. Consequently, configuring the attribute of the target region to Device-nGnRnE (non-Gathering, non-Reordering, with no Early Write Acknowledgement) is deemed appropriate.
Performing unaligned access on Device memory can cause a Data Abort due to an Alignment fault. Please ensure that accesses are aligned.
Speculative instruction access to memory with Device memory via the AXI bus may cause a Prefetch Abort due to a Permission fault, leading to UNPREDICTABLE behavior. This may occur, for example, when executing instructions directly from external flash. In such cases, it is recommended to set memory attribute to Normal memory for instruction fetching.
Dynamic Memory Protection Unit Setting
Glossary of key terms used in this document:
Static region: The memory range is programmed during startup process.
Dynamic region: The memory range is programmed dynamically during run-time.
In addition to configuring MPU regions via BSP properties in the BSP tab, run-time configuration is also supported, offering greater flexibility. Please use the following BSP API function for configuring a dynamic region and reset the setting to initial value:
Note
- R_BSP_MpuRegionDynamicConfig ()
- R_BSP_MpuRegionRestoreConfig ()
Only one dynamic region can be configured at setup; consequently, once R_BSP_MpuRegionDynamicConfig () has been executed, it cannot run again until R_BSP_MpuRegionRestoreConfig () is performed.
Configure dynamic region in the bsp_mpu_dynamic_cfg_t in the following file.
{rz device}/fsp/src/bsp/mcu/all/cr/bsp_mpu_core.h
base address
Set the base address of the dynamic region. The address must be aligned with 64 bytes. size
Set the size of the dynamic region. The input size is not less than 64 bytes and must increase in increments of 64 bytes.
Note
If an unaligned base and size are set, these values will be dynamically configured to the nearest 64-byte boundary.
After the dynamic configuration, accessing addresses outside dynamic region triggers an exception.
attribute
Configures the attribute properties of the dynamic region. All required properties must be specified by the user.
These setting value by using a macro of Access Permission, Shareability, Attribute Index and Other.
Access Permision macro
Name
Description
BSP_EL1RW_EL0NO
Privileged mode: read/write possible, user mode: not accessible
BSP_EL1RW_EL0RW
Privileged mode: read/write possible, user mode: read/write possible
BSP_EL1RO_EL0NO
Privileged mode: read only , user mode: not accessible
BSP_EL1RO_EL0RO
Privileged mode: read only , user mode: read only
Shareability macro
Name
Description
BSP_NON_SHAREABLE
A domain limited to the local agent and do not require synchronization with other cores, processors, or devices.
BSP_INNER_SHAREABLE
A domain that is shared by other agents, but not necessarily all agent in the system.
BSP_OUTER_SHAREABLE
A domain that is shared by multiple agents that can consist of one or more Inner Shareable domains.
Attribute Index maco
Name
Description
BSP_ATTRINDEX0
Attribute Index 0.
BSP_ATTRINDEX1
Attribute Index 1.
BSP_ATTRINDEX2
Attribute Index 2.
BSP_ATTRINDEX3
Attribute Index 3.
BSP_ATTRINDEX4
Attribute Index 4.
BSP_ATTRINDEX5
Attribute Index 5.
BSP_ATTRINDEX6
Attribute Index 6.
BSP_ATTRINDEX7
Attribute Index 7.
Regarding the memory attribute properties such as Memory type and Inner/Outer Attribute settings, these will be set up in CPU MPU|Attribute property in FSP Configuration tool.
Other macro
Name
Description
BSP_EXECUTE_ENABLE
Programs will be allowed to run in the region.
BSP_EXECUTE_NEVER
programs will be prohibited from running in the region.
Example of dynamically region allocated
The following pattern illustrates how a 128-byte region is dynamaically allocated.
A 128-byte aligned memory block
Memory Management Unit
In the CPU-MMU (CA55), a virtual address is assigned to a physical address, so the CPU accesses the virtual address. The use of virtual addresses enables access with different attributes from the CPU. For example, in RZ/T2H CA55, a virtual address noncache is placed in the area offset 0x0020_0000 (Reserved) from the physical address (System SRAM) in order to realize cache access to System SRAM and access noncache.
Region01 (System SRAM : Cache)
Virtual address: 0x1000_0000
Physical address: 0x1000_0000
Size: 0x0020_0000
Region02 (System SRAM mirror : Non-cache)
Virtual address: 0x1020_0000
Physical address: 0x1000_0000
Size: 0x0020_0000
Note that if a bus master other than the CPU accesses the same resource, direct access to the physical address is required. For example, when setting the source/destination address for a DMA transfer, the virtual address must be converted to a physical address. If address translation is required within a driver, such as FSP's DMAC driver, the BSP APIs (R_BSP_MmuVatoPa, R_BSP_MmuPatoVa) are used to perform address translation. If address translation is required within a user application, these BSP APIs should be used. Refer to FSP Module (DMAC, USB, Ethernet) for specific implementation examples of BSP API.
Note
When using Cortex-R52 as the secondary core on the RZ/T2H for multi-core operation, set Cortex-R52 CPU0 ATCM via AXIS (0x20000000 - 0x2007FFFF) and Cortex-R52 CPU1 ATCM via AXIS (0x21000000 - 0x2107FFFF) to Device Memory.
The CPU-MMU assigns two virtual addresses with different cache attributes to a single physical region to enable both cached memory access and non-cached DMA access to a shared memory region.
Target memory regions:
System SRAM: normal and mirror regions
xSPIn CSm: normal and mirror regions (n=0,1 m=0,1)
CSn: normal and mirror regions (n=0,2,3,5)
Initial settings:
Normal regions: Inner/Outer Write-Back non-transient, Read/Write allocate
Mirror regions: Inner/Outer Non-Cacheable, Read/Write do not allocate
When using this CPU-MMU configuration, it is essential to maintain data consistency, processing order, and coherency. When accessing the target memory regions from a user application, ensure that cache cleaning and invalidation, as well as DMB barrier instructions, are executed to guarantee shared access. For more information, refer to the Arm Architecture Reference Manual.
Dynamic Memory Management Unit Setting(Dynamic Memory Mapping)
Glossary of key terms used in this document:
Static region: The memory range is programmed during startup process.
Dynamic region: The area has its properties changed during run-time to meet the desired requirements.
In addition to configuring MMU regions via BSP properties in the BSP tab, run-time configuration is also supported, offering greater flexibility. Please use the following BSP API function for configuring a dynamic region and reset the setting to initial value:
Note
- R_BSP_MemoryMap ()
- R_BSP_MemoryUnMap ()
Only one dynamic region can be configured at setup; consequently, once R_BSP_MemoryMap () has been executed, it cannot run again until R_BSP_MemoryUnMap () is performed.
Configure dynamic region in the r_mmu_pgtbl_cfg_t in the following file.
ca\bsp_mmu_core.h
Virtual address
Set the virtual address of the dynamic area. If the address is less than 4GB area, it must be aligned with 2M-bytes, and if it is more than 4GB area, it must be aligned with 1G-bytes.
Physical address
Set the physical address of the dynamic area. If the virtual address is less than 4GB, it must be aligned to 2MB. Also, the virtual address and bit21-bit0 must match.If the virtual address exceeds 4GB, it must be aligned to 1GB. Also, the virtual address and bit30-bit0 must match.
size
Set the size of the dynamic region. If the virtual address is less than 4GB area, it must be aligned with 2M-bytes, and if it is more than 4GB area, it must be aligned with 1G-bytes.
Note
If an unaligned virtual address, physical and size are set, these values will be dynamically configured to the nearest 2M-byte or 1G-byte boundary.
attribute
Configures the attribute properties of the dynamic memory mapping. All required properties must be specified by the user.
These setting value by using a macro of Access Permission, Shareability, Attribute Index and Other.
Unprivileged Execute Never (UXN) macro
Name
Description
BSP_UXN_EXECUTE_ENABLE
Can be executed in unprivileged mode
BSP_UXN_EXECUTE_DISABLE
Cannot run in unprivileged mode
Privileged Execute Never (PXN) macro
Name
Description
BSP_PXN_EXECUTE_ENABLE
Can be executed in privileged mode
BSP_PXN_EXECUTE_DISABLE
Cannot run in privileged mode
Shareability macro
Name
Description
BSP_NON_SHAREABLE
A domain limited to the local agent and do not require synchronization with other cores, processors, or devices.
BSP_INNER_SHAREABLE
A domain that is shared by other agents, but not necessarily all agent in the system.
BSP_OUTER_SHAREABLE
A domain that is shared by multiple agents that can consist of one or more Inner Shareable domains.
Access Permision macro
Name
Description
BSP_EL321RW_EL0NO
Unprivileged mode(EL1,EL2,EL3): read/write possible, Privileged mode(EL0): not accessible
BSP_EL321RW_EL0RW
Unprivileged mode(EL1,EL2,EL3): read/write possible, Privileged mode(EL0): read/write possible
BSP_EL321RO_EL0NO
Unprivileged mode(EL1,EL2,EL3): read only, Privileged mode(EL0): not accessible
BSP_EL321RO_EL0RO
Unprivileged mode(EL1,EL2,EL3): read only, Privileged mode(EL0): read only
Attribute Index maco
Name
Description
BSP_ATTRINDEX0
Attribute Index 0.
BSP_ATTRINDEX1
Attribute Index 1.
BSP_ATTRINDEX2
Attribute Index 2.
BSP_ATTRINDEX3
Attribute Index 3.
BSP_ATTRINDEX4
Attribute Index 4.
BSP_ATTRINDEX5
Attribute Index 5.
BSP_ATTRINDEX6
Attribute Index 6.
BSP_ATTRINDEX7
Attribute Index 7.
Regarding the memory attribute properties such as Memory type and Inner/Outer Attribute settings, these will be set up in CPU MMU|Attribute property in FSP Configuration tool.
Security bit(only EL3 and EL1)
Name
Description
BSP_NS_SECURE
Secure.
BSP_NS_NON_SECURE
Non Secure.
Other macro
Name
Description
BSP_REGION_ENABLE
Enable the region of the specified virtual address.
BSP_REGION_DISABLE
Disable the region of the specified virtual address.
Example of dynamically region allocated
The following pattern illustrates how a 2M-byte region is dynamaically allocated.
A 2M-byte aligned memory block
TrustZone Address Space Controller (TZC-400)
The TZC-400 module can be configured from the BSP properties of the RZ microprocessor containing the TZC-400.
TZC-400-0: DDR SDRAM A0/A1 I/F.
TZC-400-1: DDR SDRAM A4 I/F.
TZC-400-2: PCIE Unit 0/1.
TZC-400-3: DDR SDRAM R2 I/F.
TZC-400-4: DDR SDRAM R3 I/F.
TZC-400-5: SYSRAM unit 0/1/2/3.
TZC-400-6: BSC
TZC-400-7: xSPI unit 0/1.
TZC-400-8: Cortex-R52 CPU0/1 AXIS (TCM).
The configuration values are generated as macro values in bsp_mcu_tzc400_memory_cfg.h and reflected in the ARM core registers in the startup code.
The default settings of the TZC-400 modules allow access in unprivileged and privileged in non-secure and secure in region 0.
For example, in RZT2H device, when creating the access rule in TZC-400-0: DDR SDRAM A0/A1 I/F, the settings shown below are used:
Enter the filter unit in the Gatekeeper field.
Region 0: Enter the filter unit in the attribute field.
Region 0: Enable write control in attribute.
Region 0: Enable read control in attribute.
Region 0: Set ID (e.g. allow unprivileged and privileged access in non-secure, allow unprivileged and privileged access in secure) in NSAID read/write enable.
Note
When using Cortex-R52 as the secondary core on the RZ/T2H for multi-core operation, set filters 0 and 1 on the TZC-400-8 to enable access to the TCM of Cortex-R52 CPU0 and CPU1.
Module Reset
The reset state and the release can be set for each peripheral module. To secure processing after release from a module reset, dummy read the same register at sevral times after writing to initiate release from the module reset.
Note
Dummy reads are performed several times in the R_BSP_ModuleResetDisable function according to the RZ microprocessor manual. However, depending on the device used, the number of dummy reads for RTC and LCDC may not be met. In that case, please perform additional dummy read processing after API execution. For example, in the case of the RZT2H, the RTC requires 300 dummy reads and the LCDC requires 100 dummy reads.
Software Reset
Note
If the core that called the software reset function is different from the core you want to reset, you must execute the WFI instruction manually.
In Cortex-A55, the bit in Reset Status Register 0 (RSTSR0) is not set when a software reset occurs. If you want to determine if a software reset has occurred, use g_bsp_software_reset_occurred, which is defined in rzt/fsp/src/bsp/cmsis/Device/RENESAS/Source/ca/startup_core.c.
System Error Interrupt (SEI,NMI)
When a request signal is input to the SEI pin (or NMI pin), a System Error Interrupt occurs. The sequence to detect a System Error Interrupt is different for each core.
Note
Note that the initial devices of the RZ/T2 series refer to SEI as NMI. Since the subsequent documentation uniformly describe it as SEI, if you are using an initial device, please replace SEI with NMI.
Cortex-R52
The SEI pin is connected to SEI and VSEI in Cortex-R52 CPU0 and CPU1, and an asynchronous external abort occurs when a request signal is input.
The implementation method is described below.
Implement the SEI pin detection setting.
Enable the noise filter.
Set the noise filter sampling frequency divider ratio.
Set the detection mode.
Implement the Abort_Handler function.
Determine if the value of DFSR.status [5:0] is 0b10001 (Asynchronous external abort).
Register the SEI pin from the Pins tab in the FSP Configuration editor.
if (DSFR_ASYNCHRONOUS_EXTERNAL_ABORT == dsfr_status)
{
while (1)
{
/* SEI(SEI) interrupt occurred. */
}
}
}
Cortex-A55
The SEI pin is connected to Shared Peripheral Interrupt(SPI), and a SPI occurs when a request signal is input. It is possible to detect SEI by interrupt generation due to the event number of SPI.
The implementation method is described below.
Implement the SEI pin detection setting.
The settings are the same as for Cortex-R52.
Implement SEI interrupt enable setting.
Implement the SEI interrupt handler (sei_isr).
Register the SEI interrupt handler from Interrupts tab in the FSP Configuration editor.
Interrupts tab > New User Event > ICU > SEI (System Error Interrupt)
Enter the SEI interrupt handler name "sei_isr".
Register the SEI pin from the Pins tab in the FSP Configuration editor.
The settings are the same as for Cortex-R52.
Here is how the implementation example works.
Build and run this program.
Press the SEI pin on the board.
The program branches to the SEI interrupt handler and enters an infinite loop.
#define VECTOR_NUMBER_SEI ((IRQn_Type) 406) /* SEI (System error interrupt) */
The FSP applies the DDR parameter file generated by the DDR parameter generation tool (hereinafter referred to as "gen_tool"). The procedure for modifying the DDR parameter file is as follows.
Let's assume the file name of the file generated by gen_tool is "param_ddrinit_ref_lpddr4_r02p03.h".
Rename "param_ddrinit_ref_lpddr4_r02p03.h" to "board_ddr_param.h".
Replace the existing "board_ddr_param.h" file located in the "rzt/board/rzt2h_evb" folder with the new one.
Note
The folder path may vary depending on the board or device being used. For example, for a custom board, the path would be "rzt/board/custom".
Linker Script
To prevent build warnings, the GCC linker script separates the placement regions for .text and .data. (The same goes for .loader_text and .loader_data)
Below is a simplified version of fsp_ram_execution.ld.
.text is placed in RAM_TEXT, and .data is placed in RAM_DATA. The start address and size of both regions are the same.
Also, the start address of .data is set to the end address of .ARM.exidx. Without this, .data would be placed at the beginning of RAM_DATA and would overlap with .text.
SECTIONS
{
.text TEXT_ADDRESS:
{
_text_start = .;
*(.text*)
_text_end = .;
} > RAM_TEXT
.ARM.extab :
{
__extab_start = .;
*(.ARM.extab* .gnu.linkonce.armextab.*)
__extab_end = .;
} > RAM_TEXT
.ARM.exidx :
{
__exidx_start = .;
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
__exidx_end = .;
} > RAM_TEXT
.data __exidx_end :
{
_data_start = .;
*(.data*)
_data_end = .;
} > RAM_DATA
}
For example, if you want to move .ARM.exidx to the BTCM region, modify the end address of .ARM.extab to match the start address of .data.
SECTIONS
{
.text TEXT_ADDRESS:
{
_text_start = .;
*(.text*)
_text_end = .;
} > RAM_TEXT
.ARM.extab :
{
__extab_start = .;
*(.ARM.extab* .gnu.linkonce.armextab.*)
__extab_end = .;
} > RAM_TEXT
.ARM.exidx :
{
__exidx_start = .;
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
__exidx_end = .;
} > BTCM /* Changed from "RAM_TEXT" to "BTCM". */
.data __extab_end : /* Changed from "__exidx_end" to "__extab_end". */
{
_data_start = .;
*(.data*)
_data_end = .;
} > RAM_DATA
}
Pin Setting
When operating in multi-core, the primary and secondary core copy code and data from ROM to RAM.
Changing the pins accessed by the ROM boot during this copy process can cause it to fail. Specifically, changing the ROM boot pins in the primary's Pins tab may lead to this issue.
To work around this, the Pins tab preserves the ROM boot pin settings. Instead, configure the pins using the IOPORT driver's API on the user application side after each core's startup is complete.
Configuration
The BSP is heavily data driven with most features and functionality being configured based on the content from configuration files. Configuration files represent the settings specified by the user and are generated when the project is built and/or when the Generate Project Content button is clicked in the FSP Configuration editor.
Build Time Configurations for fsp_common
The following build time configurations are defined in fsp_cfg/bsp/bsp_cfg.h:
Configuration
Options
Default
Description
MCU Vcc (mV)
Value must between 0 and 3800 (3.8V)
3300
Some peripherals require different settings based on the supplied voltage.
Entering Vcc here (in mV) allows the relevant driver modules to configure the associated peripherals accordingly.
Parameter checking
Enabled
Disabled
Disabled
When enabled, parameter checking for the BSP is turned on.
In addition, any modules whose parameter checking configuration is set to 'Default (BSP)' will perform parameter checking as well.
Assert Failures
Return FSP_ERR_ASSERTION
Call fsp_error_log then Return FSP_ERR_ASSERTION
Use assert() to Halt Execution
Disable checks that would return FSP_ERR_ASSERTION
Support for soft reset.
If disabled, registers are assumed to be set to their default value during startup.
Port Protect
Disabled
Enabled
Enabled
Keep the write protection function related GPIO settings locked when they are not being modified.
If disabled they will be unlocked during startup.
Early BSP Initialization
Enabled
Disabled
Disabled
Enable this option to use BSP functions before C runtime initialization (BSP_WARM_START_RESET or BSP_WARM_START_POST_CLOCK).
Multiplex Interrupt
Enabled
Disabled
Disabled
Enable multiplex interrupt system-wide.
Duplication of resources
In the case of the secondary project (Non-primary cores), duplicate resource are indicated as the followings in Configuration tab when using resources that are used in the linked the primary (CR52_0 (CPU0) or CA55_0) project.
BSP
Settings marked as "Valid only for primary core" are executed only for the primary project.
Master MPU
TrustZone Address Space Controller (TZC-400)
Address Expander
Clocks
In secondary projects, this will be greyed out and cannot be set.
Pins
The secondary project does not see the pin settings that you set in the primary project.
Interrupts
There is no mutual exclusion control. If the user specifies an interrupt, be careful of resource overlaps.
Event Links
The secondary project does not see the event factor that you set in the primary project.
Stacks
Duplicate resource are indicated as red character that you set in the primary project.
Core Comparison
RZ/T2 uses Cortex-R52(CR52) and Cortex-A55(CA55) cores. The following is a cautionary execution when porting programs to different cores.
Specifications
CR52
CA55
Porting from CR52 to CA55
Porting from CA55 to CR52
Instruction set
AArch32 (32bit)
AArch64 (64bit)
Stack consumption doubles as CPU registers go from 32-bit to 64-bit.
-
Address space
4GB
32GB
Pointer type size changes from 32-bit to 64-bit.
Data placed in areas larger than 4 GB will need to be rearranged.
The non-cache section placed in System SRAM is allocated to a different area (Reserved) from the physical address as a virtual address. When handling physical addresses in user applications, address conversion is performed using the BSP API (R_BSP_MmuVatoPa, R_BSP_MmuPatoVa) that converts addresses.
This function is called before returning an error code. To stop on a runtime error, define fsp_error_log in user code and do required debugging (breakpoints, stack dump, etc) in this function.
All FSP error codes are returned using this macro. Calls FSP_ERROR_LOG function if condition "a" is false. Used to identify runtime errors in FSP functions.
In the event of an unrecoverable error the BSP will by default call the __BKPT() intrinsic function which will alert the user of the error. The user can override this default behavior by defining their own BSP_CFG_HANDLE_UNRECOVERABLE_ERROR macro.
This function is called at various points during the startup process. This function is declared as a weak symbol higher up in this file because it is meant to be overridden by a user implemented version. One of the main uses for this function is to call functional safety code during the startup process. To use this function just copy this function into your own code and modify it to meet your needs.
Parameters
[in]
event
Where the code currently is in the start up process
Note
All programs that are executed when a BSP_WARM_START_RESET, or BSP_WARM_START_POST_CLOCK event occurs must be placed in the LOADER section(BTCM for CR52 core, SystemRAM for CA55 core). These events occur before the copy of the application program in the startup code is executed, so the application program is on ROM and cannot be executed at that time. The FSP linker script specifies that the .warm_start section be placed in the LOADER section. Adding a section specification to the definition of a function or variable makes it easier to place it in the LOADER section.
Clean data cache by set/way. Clean means writing the cache data to memory and clear the dirty bits if there is a discrepancy between the cache and memory data.
This function is declared as a weak symbol because it is meant to be overridden by the user. To use this function just copy this function into your own code and modify it to meet your needs.
Delay for at least the specified duration in units and return.
Parameters
[in]
delay
The number of 'units' to delay.
[in]
units
The 'base' (bsp_delay_units_t) for the units specified. Valid values are: BSP_DELAY_UNITS_SECONDS, BSP_DELAY_UNITS_MILLISECONDS, BSP_DELAY_UNITS_MICROSECONDS.
For example:
At 200 MHz one cycle takes 1/200 microsecond or 5 nanoseconds.
At 800 MHz one cycle takes 1/800 microsecond or 1.25 nanoseconds.
Therefore one run through bsp_prv_software_delay_loop() takes: ~ (1.25 * BSP_DELAY_LOOP_CYCLES) or 5 ns. A delay of 2 us therefore requires 2000ns/5ns or 400 loops.
The 'theoretical' maximum delay that may be obtained is determined by a full 32 bit loop count and the system clock rate. @200MHz: ((0xFFFFFFFF loops * 4 cycles /loop) / 200000000) = 85 seconds. @800MHz: ((0xFFFFFFFF loops * 4 cycles /loop) / 800000000) = 21 seconds.
Note that requests for very large delays will be affected by rounding in the calculations and the actual delay achieved may be slightly longer. @200 MHz, for example, a request for 85 seconds will be closer to 86 seconds.
Note also that if the calculations result in a loop_cnt of zero, the bsp_prv_software_delay_loop() function is not called at all. In this case the requested delay is too small (nanoseconds) to be carried out by the loop itself, and the overhead associated with executing the code to just get to this point has certainly satisfied the requested delay.
Note
R_BSP_SoftwareDelay() obtains the system clock value by reading the SystemCoreClock variable. Therefore, R_BSP_SoftwareDelay() cannot be used until after the SystemCoreClock has been updated. The SystemCoreClock is updated by executing SystemCoreClockUpdate() in startup; users cannot call R_BSP_SoftwareDelay() inside R_BSP_WarmStart(BSP_WARM_START_RESET) and R_BSP_WarmStart(BSP_WARM_START_POST_CLOCK) since they are invoked before SystemCoreClockUpdate() in startup.
This function will delay for at least the specified duration. Due to overhead in calculating the correct number of loops to delay, very small delay values (generally 1-5 microseconds) may be significantly longer than specified. Approximate overhead for this function is as follows:
CR52: 94-117 cycles
If more accurate microsecond timing must be performed in software it is recommended to use bsp_prv_software_delay_loop() directly. In this case, use BSP_DELAY_LOOP_CYCLES or BSP_DELAY_LOOPS_CALCULATE() to convert a calculated delay cycle count to a number of software delay loops.
Delays may be longer than expected when compiler optimization is turned off.
Enable register protection. Registers that are protected cannot be written to. Register protection is enabled by using the Protect Register (PRCR) and the MPC's Write-Protect Register (PWPR).
Disable register protection. Registers that are protected cannot be written to. Register protection is disabled by using the Protect Register (PRCR) and the MPC's Write-Protect Register (PWPR).
Occur the CPU software reset. When using this function, the CPU reset state is automatically released after an elapsed time corresponding to the setting value in SCKCR2.DIVSELSUB bit.
After reset release is performed by the module control register, a dummy read is performed to allow access to other than the RTC and LCDC. This is done several times according to the RZ microprocessor manual. However, the dummy read count for the RTC and LCDC may not be met depending on the device used. In that case, please perform additional dummy read processing after API execution. For example, in the case of RZT2H, 300 dummy reads are required for RTC and 100 dummy reads are required for LCDC.
This assembly language routine takes roughly 4 cycles per loop. 2 additional cycles occur when the loop exits. The 'naked' attribute indicates that the specified function does not need prologue/epilogue sequences generated by the compiler.
Register a callback function for supported interrupts. If NULL is passed for the callback argument then any previously registered callbacks are unregistered.
Parameters
[in]
irq
Interrupt for which to register a callback.
[in]
p_callback
Pointer to function to call when interrupt occurs.
Set the values specified in the argument to EnableGrp0 bit, EnableGrp1NS bit, and EnableGrp1S bit of GICD_CTLR, to enable interrupts for any interrupt group.
Set the values specified in the argument to EnableGrp0 bit, EnableGrp1NS bit, and EnableGrp1S bit of GICD_CTLR, to disable interrupts for any interrupt group.
Set the values specified in the argument to ARE_S bit and ARE_NS bit of GICD_CTLR, to enable Affinity Routing for Secure state and/or Non-secure state.
Set affinity routing information that is SPI Affinity level and routing mode to GICD_IROUTERn.
Parameters
[in]
irq
Interrupt number ID.
[in]
route
Affinity route settings. Since it will be used as it is as the setting value of the Affinity level, write the value of Aff0 from bit 7 to bit 0, the value of Aff1 from bit 15 to bit 8, the value of Aff2 from bit 23 to bit 16, and the value of Aff3 from bit 39 to bit 32.
Get affinity routing information that is SPI Affinity level and routing mode by reads GICD_IROUTERn.
Parameters
[in]
irq
Interrupt number ID.
Return values
interrupt
routing information. Aff0 is stored in bit 7 to bit 0, Aff1 in bit 15 to bit 8, Aff2 in bit 23 to bit 16, Routing mode in bit 31, and Aff3 in bit 39 to bit 32.
Set SPI security group. The combination of the modifier bit of GICD_IGRPMODR and the status bit of GICD_IGROUPR determines whether the security group is Secure Group 0, Non-Secure Group 1, or Secure Group 1.
Sets SPI security group with each 32 interrupts (each line). The combination of the modifier bit of GICD_IGRPMODR and the status bit of GICD_IGROUPR determines whether the security group is Secure Group 0, Non-Secure Group 1, or Secure Group 1.
Parameters
[in]
line
Line of GICD_IGRPMODRn register. Line is the quotient of the interrupt ID divided by 32. For example, an interrupt with IDs 32 to 63 corresponds to line 1.
Set SPI security group for all GICD_IGRPMODRn register. The combination of the modifier bit of GICD_IGRPMODR and the status bit of GICD_IGROUPR determines whether the security group is Secure Group 0, Non-Secure Group 1, or Secure Group 1.
Enables Redistributor and configue power management by access GICR_PWRR and GICR_WAKER. This BSP sets GICR_WAKER.ProcessorSleep to 0, so wake_request signal wake-up the core when the core is powered off is disabled.
Set SGI and PPI security group. The combination of the modifier bit of GICR_IGRPMODR0 and the status bit of GICR_IGROUPR determines whether the security group is Secure Group 0, Non-Secure Group 1, or Secure Group 1.
Sets security group for all SGI and PPI. The combination of the modifier bit of GICR_IGRPMODR0 and the status bit of GICR_IGROUPR0 determines whether the security group is Secure Group 0, Non-Secure Group 1, or Secure Group 1.
