CHAPTER 10 SYSTEM CONFIGURATION MANAGEMENT FUNCTIONS
The system configuration management functions of the RI78V4 provides system initialization processing, which is required from the reset interrupt output until control is passed to the task, and version information referencing processing.
The following shows a processing flow from when a reset interrupt occurs until the control is passed to the task.
Boot processing is a routine dedicated to initialization processing that is extracted as a user-own coding module to initialize the minimum required hardware for the RI78V4 to perform processing. Boot processing is called from Interrupt Entry Processing that is assigned to the vector table address to which the CPU forcibly passes the control when a reset interrupt occurs.
Boot processing registration is realized by coding Interrupt Entry Processing (branch instruction to boot processing) to the vector table address to which the CPU forcibly passes control upon occurrence of a reset interrupt.
The code of Interrupt Entry Processing varies depending on whether boot processing is allocated to the near area or to the far area.
Write Boot processing as a function that does not include arguments and return values (function name: any name).
.PUBLIC _boot .EXTERN __kernel_start, _hdwinit, __init_ri_stackarea, _reset .SECTION .stack_bss, BSS ;Sets stack section _stackend: .DS 0x100 _stacktop: _boot .VECTOR 0x0000 .SECTION .text, TEXT _boot: SEL RB0 ;Sets register bank MOVW SP, #LOWW(_stacktop) ;Sets stack pointer SP CALL !!_reset ;Clears initial information items of RI78V4 MOVW HL, #LOWW(STARTOF(.kernel_data_init)) MOVW AX, #LOWW(STARTOF(.kernel_data_init) + SIZEOF(.kernel_data_init)) BR $L2_KERNEL_DATA L1_KERNEL_DATA: MOV [HL+0], #0 INCW HL L2_KERNEL_DATA: CMPW AX, HL BNZ $L1_KERNEL_DATA CALL !!__init_ri_stackarea ;Clears RAM area BR !!__kernel_start ;Jump to Kernel Initialization Module CLRW AX _exit: BR $exit |
Boot processing is a routine dedicated to initialization processing called from Interrupt Entry Processing without using the RI78V4. Therefore, note the following points when coding boot processing.
- Stack switching
Setting of stack pointer SP is not executed at the point when control is passed to boot processing.
To use a boot processing dedicated stack, setting of stack pointer SP must therefore be coded at the beginning of the boot processing.
Setting of stack pointer SP is not executed at the point when control is passed to boot processing.
To use a boot processing dedicated stack, setting of stack pointer SP must therefore be coded at the beginning of the boot processing.
- Interrupt status
The Kernel Initialization Module is not executed at the point when control is passed to boot processing. The system may therefore hang up when an interrupt is created before the processing is completed. To avoid this, explicitly prohibit acknowledgment of maskable interrupts by manipulating interrupt enable flag IE of program status word PSW during boot processing.
The Kernel Initialization Module is not executed at the point when control is passed to boot processing. The system may therefore hang up when an interrupt is created before the processing is completed. To avoid this, explicitly prohibit acknowledgment of maskable interrupts by manipulating interrupt enable flag IE of program status word PSW during boot processing.
- Register bank setting
The RI78V4 prohibits switching of a register bank that was set before __urx_start is called in boot processing to another register bank (except for the case when interrupt servicing not managed by the RI78V4).
The RI78V4 prohibits switching of a register bank that was set before __urx_start is called in boot processing to another register bank (except for the case when interrupt servicing not managed by the RI78V4).
- Initialization of RAM area (initialization of memory area without initial value, copying of initialization data)
Note Setting of stack pointer SP is required only when a stack dedicated to boot processing is used in boot processing.
System dependence information is the header file as the user own cording part which need for RI78V4 processing (file name : usrown.h).
- Basic form of system dependence information
When describes system dependence information, uses the prescribed file name (usrown.h), the prescribed macro name (KERNEL_USR_TMCNTREG, KERNEL_USR_TMCMPREG).
The following shows the basic form of system dependent information using C language
The following shows the list of the information which should be defined as system dependence information.
When describes system dependence information, uses the prescribed file name (usrown.h), the prescribed macro name (KERNEL_USR_TMCNTREG, KERNEL_USR_TMCMPREG).
The following shows the basic form of system dependent information using C language
#include <kernel_id.h> /*System information header file definition*/ #define KERNEL_USR_TMCNTREG 0x0180 /*I/O address */ #define KERNEL_USR_TMCMPREG 0xff18 /*I/O address */ |
The following shows the list of the information which should be defined as system dependence information.
- Definition of system information header file
The inclusion of system information header file output by CF78V4
The inclusion of system information header file output by CF78V4
Note Only the case selected "Taking in long statistics by software trace mode" is needed description (Property panel -> [Task Analyzer] tab -> [Trace] -> [Selection of trace mode])
- Information of the clock timer
Macro definition of the I/O address of the clock timer and the I/O address of the compare register.
Macro definition of the I/O address of the clock timer and the I/O address of the compare register.
Note Only the case selected "Taking in long statistics by software trace mode" is needed description (Property panel -> [Task Analyzer] tab -> [Trace] -> [Selection of trace mode])
The initialization routine is a routine dedicated to initialization processing that is extracted as a user-own coding module to initialize the hardware dependent on the user execution environment (such as the peripheral controller), and is called from the Kernel Initialization Module.
In the RI78V4, the method of registering an initialization routine is limited to "static registration by the Kernel Initialization Module".
Initialization routines therefore cannot be created dynamically using a method such as issuing a service call from a processing program.
- Static define
Static initialization routine registration is realized by coding initialization routines by using the prescribed function name init_handler.
The RI78V4 executes initialization routine registration processing based on relevant symbol information, using the Kernel Initialization Module, and handles the registered initialization routines as management targets.
Static initialization routine registration is realized by coding initialization routines by using the prescribed function name init_handler.
The RI78V4 executes initialization routine registration processing based on relevant symbol information, using the Kernel Initialization Module, and handles the registered initialization routines as management targets.
In the RI78V4, initialization routines registered statically by the Kernel Initialization Module cannot be unregistered dynamically using a method such as issuing a service call from a processing program.
Write initialization routines using void type functions that do not have arguments (function: init_handler).
Moreover, the RI78V4 executes "original pre-processing" when passing control to the initialization routine, as well as "original post-processing" when regaining control from the initialization routine.
- Coding method
Code initialization routines using C or assembly language in the format shown in "10.3.3 Basic form of initialization routine".
Code initialization routines using C or assembly language in the format shown in "10.3.3 Basic form of initialization routine".
- Stack switching
The RI78V4 executes processing to switch to the system stack when passing control to the initialization routine, and processing to switch to the stack for the Kernel Initialization Module when regaining control from the initialization routine.
The user is therefore not required to code processing related to stack switching in initialization routines.
The RI78V4 executes processing to switch to the system stack when passing control to the initialization routine, and processing to switch to the stack for the Kernel Initialization Module when regaining control from the initialization routine.
The user is therefore not required to code processing related to stack switching in initialization routines.
- Interrupt status
Maskable interrupt acknowledgement is prohibited in the RI78V4 when control is passed to the initialization routine.
Kernel Initialization Module is not completed at the point when control is passed to the initialization routine. The system may therefore hang up when acknowledgment of maskable interrupts is explicitly enabled within the initialization routine. Therefore, enabling maskable interrupt acknowledgment in the initialization routine is prohibited in the RI78V4.
Maskable interrupt acknowledgement is prohibited in the RI78V4 when control is passed to the initialization routine.
Kernel Initialization Module is not completed at the point when control is passed to the initialization routine. The system may therefore hang up when acknowledgment of maskable interrupts is explicitly enabled within the initialization routine. Therefore, enabling maskable interrupt acknowledgment in the initialization routine is prohibited in the RI78V4.
- Initialization of RAM area (initialization of memory area without initial value, copying of initialization data)
The kernel initialization module is a dedicated initialization processing routine provided for initializing the minimum required software for the RI78V4 to perform processing, and is called from Boot Processing.
Note The kernel initialization module is part of the functions provided by the RI78V4. The user therefore need not code the processing contents of the kernel initialization module.
Version information is referenced by issuing the following service call from the processing program.
- ref_ver
The service call stores version information packet (such as kernel maker's code) to the area specified by parameter pk_rver.
The following describes an example for coding this service call.
The service call stores version information packet (such as kernel maker's code) to the area specified by parameter pk_rver.
The following describes an example for coding this service call.
#include <kernel.h> /*Standard header file definition*/ #include <kernel_id.h> /*System information header file definition*/ void func_task ( VP_INT exinf ) { T_RVER pk_rver; /*Declares data structure*/ UH maker; /*Declares variable*/ UH prid; /*Declares variable*/ UH spver; /*Declares variable*/ UH prver; /*Declares variable*/ UH prno[4]; /*Declares variable*/ /* ............ */ ref_ver ( &pk_rver ); /*Reference version information*/ maker = pk_rver.maker; /*Reference Kernel maker's code*/ prid = pk_rver.prid; /*Reference identification number of the kernel*/ spver = pk_rver.spver; /*Reference version number of the ITRON Specification*/ prver = pk_rver.prver; /*Reference version number of the kernel*/ prno[0] = pk_rver.prno[0]; /*Reference management information of the kernel product (version type)*/ prno[1] = pk_rver.prno[1]; /*Reference management information of the kernel product (memory model)*/ /* ............ */ } |
Note For details about the version information packet, refer to "12.5.9 Version information packet".