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. 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.
In this blog, we will investigate the interrupt model for these series of MCUs with RH850G3M core as reference. We will first introduce the CPU core, its register set, exception model and then provide examples about how to handle exceptions.
RH850 CPU Core
Before we jump into the interrupt handling in RH850, 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.

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 are ID (disables the EI level exception handling) and NP (disables the FE level exception handling).
RH850 Exception Model
As with any architecture, RH850 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, RH850 supports 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.
RH850 core leverages some special purpose registers to store contexts during 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 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.

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 for the Renesas 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.
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 /* Reservedexception */ 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 exception handling, similar procedures can be followed in the open CS+ development environment as well.
Thus, it is quite easy to handle the exception in the RH850 series of MCUs. With power exception handling mechanisms backed up with rich RISC instruction set, firmware developers can develop both bare-metal and RTOS based systems with these CPUs.
Embien has 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.