This blog is in continuation with our earlier set of articles on interrupt architecture, ARM interrupt handling and ARM Cortex M interrupt handling. Renesas is a leading supplier in automotive domain and one of their offerings is the hugely popular RH850 series of MCU. Based on the V850 core, a 32-bit RISC ISA, the series had many MCUs suitable for different applications including body control, telematics, instrument clusters and so on. Interrupt handling in RH850 MCUs is a critical skill for developers building automotive-grade firmware on this platform. There are multi-core variants too available specially designed for Zonal E/E architecture. Some popular variants include RH850/F1KM-S1, RH850/F1KM-S2, RH850/F1KM-S4, RH850/F1KH-D8, RH850/U2A, RH850/C1M-Ax, RH850/D1M1A, RH850/D1L, RH850/E2H. Offered over different CPU core structures such as single, multiple, lock-step, and combination, RH850 MCUs enable high-performance and/or high-reliability requirements helping achieve ASIL-D level. Embien's cross-domain embedded services include RH850 firmware development and Renesas RH850 automotive software services for safety-critical applications.
In this blog, we will investigate interrupt handling in RH850 MCUs with RH850G3M core as reference. We will first introduce the CPU core, its register set, the RH850 exception model, and then provide examples about RH850 exception handling in practice.
RH850 CPU Core
Before we jump into interrupt handling in RH850 MCUs, it is essential to understand the core and the register set. The RH850 is powered by a 32-bit High performance core with thirty-two numbers of 32-bit general-purpose registers. The CPU can address up to 4 Giga bytes of both data and instruction space.
With respect to the operating mode, as with many architectures, it has two modes - Supervisor mode and User Mode. As the name implies, the Supervisor mode (SV) is a privileged mode that allows access to all the hardware functions and components. It can also configure the access for the lower user mode. The CPU starts up in this mode post reset. The User mode (UM) is a limited mode with no access to Supervisor-privileged instructions and address space to those set by SV.
Working in little endian mode, it can support access to different data width including Byte (8-bit data), Halfword (16-bit data), Word (32-bit data), Double-word (64-bit data) and Bit (1-bit data).
Often the CPU is accompanied by a few co-processors, especially the floating-point operation coprocessor (FPU). With support for IEEE754-compliant data types and exceptions, the FPU significantly accelerates single precision (32-bit) and double precision (64-bit) data processing.
RH850 Register Set
The below table captures the General-purpose registers (GPR) available in the CPU. Understanding the register set is foundational to implementing interrupt handling in RH850 MCUs correctly.
RH850 Register Set
Of these, the r0 is a register that always retains 0 and is used for operations that use 0. The r3 register is implicitly used by the PREPARE, DISPOSE, PUSHSP, and POPSP instructions, while r30 is used as a base pointer when the SLD instruction or SST instruction accesses memory.
The r1, r4, r5, and r31 are implicitly used by the assembler and C compiler while the other registers r6 to r29 are used as addresses and data variables.
The Program Counter (PC) contains the address of the instruction being executed. Apart from these GPRs there are many System Registers that determine and aid in instruction execution. They are grouped based on functionality such as group numbers 0 to 3, being related to basic functions, group numbers 4 to 7, related to the memory management function and group numbers 12 to 15 implemented as per CPU hardware specifications.
One notable SFRs is the PSW (Program Status Word) that contains various fields such as UM (User Mode vs Supervisor mode), Z (result of the last operation is 0), S (result of the last operation is negative), OV (Occurrence of Overflow). But the fields of our current interest in interrupt handling in RH850 MCUs are ID (disables the EI level exception handling) and NP (disables the FE level exception handling).
RH850 Exception Model
As with any architecture, the RH850 exception model supports exceptions and interrupts to suspend the current flow of instruction execution, handle the same and return to original flow. These could be from peripherals typically, indicating either reception or transmission of data or due to unexpected flow such as access errors.
To handle the priorities, the RH850 exception model defines 2 exception levels. EI level exceptions are used for regular user processing, interrupt servicing, and OS processing while the FE level exceptions are used to enable interrupts with a high degree of urgency for the system or exceptions from the memory management function that might occur during OS processing to be acknowledged. The FE exception level can be entered even when an EI level exception is being processed. The RH850 exception model is central to understanding RH850 exception handling at both hardware and firmware levels.
RH850 core leverages some special purpose registers to store contexts during RH850 exception handling. When an EI level exception occurs, the CPU saves the PC to EIPC, saves the PSW to EIPSW, stores the exception code in the EIIC register, updates the PWS and finally jumps to the exception handler. Similarly for the FE exceptions, the CPU saves the PC to FEPC, saves the PSW to FEPSW, stores the exception code in the FEIC register, updates the PWS and jumps to the exception handler. Thus, during RH850 exception handling it is possible to understand the exact source and interrupted instruction with these SFRs.
RH850 Exception Code
Each of the exceptions is assigned a unique code that will be used to identify the source. For example, the below table highlights some of the general codes common across all variants. These codes are essential reference material for anyone implementing interrupt handling in RH850 MCUs.
RH850 Exception Code
Beyond these, each of the specific implementations have exception codes specific to their peripheral set. For example, for RH850D1M1A, the table looks like below (or just the start of the long table).
RH850D1M1A Exception Codes
This table comes handy when writing exception handlers during interrupt handling in RH850 MCUs as described in the upcoming section.
RH850 Exception Handling
As described earlier, when an exception occurs the context is stored in EIPC/EIPSW/EIIC or FEPC/FEPSW/FEIC and the PC is set to the offset given in the above table. It is possible to assign the base address of the interrupt handling table with either RBASE (Reset vector base address) when PSW.EBV is zero or EBASE (Exception Handler vector base address) when PSW.EBV is one. This is the hardware foundation of RH850 exception handling for all peripheral and system-level exception sources.
With respect to the software definition of the vector table, an example implementation for GHS compiler is given below:
#define IRQ_TABLE_START 0x00000200u
.text
-------------------------------------------------------------------------------
------------- Add section '.intvect' to the linker command file
------------- at address 0x0000
-------------
------------- i.e. .intvect 0x0000:
-------------------------------------------------------------------------------
.section'.intvect',.text
.global _RESET
.offset 0x0000
#if (RESET_ENABLE > 0x00000000)
.extern _RESET
jr _RESET
#else
jr __unused_isr
#endif
.offset 0x0010
/* SYSERR exception */
jr __unused_isr
.offset 0x0020
/* Reserved exception */
jr __unused_isr
.offset 0x0030
/* FETRAP exception */
jr __unused_isr
.offset 0x0040
.extern _vPortYield
jr _vPortYield
.offset 0x0050
.extern _TRAP1
jr _TRAP1
.offset 0x00c0
/* MAE Misalignment exception */
jr __unused_isr
.offset (IRQ_TABLE_START+0x0014)
.extern _INTAWOT
.word _INTAWOT
.offset (IRQ_TABLE_START+0x0018)
.extern _INTP0
.word _INTP0
_RESET:
-- Initialization of the global pointer
mov __gp, gp
-- Initialization of the text pointer
mov __tp, tp
-- Initialization of the stack pointer
movhi hi(___ghsend_stack),zero,sp
movea lo(___ghsend_stack),sp,sp
-- 4-byte stack alignment
mov -4,r1
and r1,sp
-- Initialization of the interrupt base pointer
mov __ex_entry + IRQ_TABLE_START,r1
ldsr r1,intbp,1
-- First set EBASE register address
mov __ex_entry, r10
ldsr r10, EBASE, 1
-- then set 1 to PSW.EBV -> RBASE!=EBASE
stsr 5, r1, 0
ori 0x8000, r1, r2
ldsr r2, 5, 0
.....
jr __start
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
--- Interrupt service routine of unused interrupts
.global __unused_isr
__unused_isr:
br __unused_isr
-------------------------------------------------------------------------------
As it can be seen, with assembler directives, each of the exception handler addresses are placed continuously from the exception base address at offsets corresponding to the exception code. And the exception base address is loaded on to the EBASE register and PWS.EBV is set. For example, when an Always On timer exception occurs (with code 0x1005), the PC is loaded with address at offset 0x2014 as given in the previous table.
Now, in the C code, the handler can be defined as below:
#pragma ghs interrupt
void INTAWOT(void) {
//MY Interrupt handling
}
This function will create an ISR with necessary context saving and will exit with an EIRET instruction indicating it is returning from an EI exception handler.
Conclusion
While this blog covered GHS based RH850 exception handling, similar procedures can be followed in the open CS+ development environment as well.
Thus, interrupt handling in RH850 MCUs is quite straightforward once the RH850 exception model and exception codes are well understood. With powerful exception handling mechanisms backed up with rich RISC instruction set, RH850 firmware development enables both bare-metal and RTOS based systems with these CPUs. Renesas RH850 automotive software services teams at Embien have rich experience in working with RH850 MCUs across functional safety critical applications like ECUs, multi-core Zonal ECUs, Clusters, etc. Feel free to get in touch with us in case you have any questions or need support in Renesas based developments.