SYSTEM INITIALIZATION ROUTINE

CHAPTER 14 SYSTEM INITIALIZATION ROUTINE

This chapter describes the system initialization routine performed by the RI850V4.

14.1 Outline

The system initialization routine of the RI850V4 provides system initialization processing, which is required from the reset interrupt output until control is passed to the task.

The following shows a processing flow from when a reset interrupt occurs until the control is passed to the task.

Figure 14-1 Processing Flow (System Initialization)

14.2 User-Own Coding Module

To support various execution environments, the RI850V4 extracts from the system initialization processing the hardware-dependent processing (Boot processing) that is required to execute processing, as a user-own coding module. This enhances portability for various execution environments and facilitates customization as well.

14.2.1 Boot processing

This is a routine dedicated to initialization processing that is extracted as a user-own coding module to initialize the minimum required hardware for the RI850V4 to perform processing, and is called from Initialization routine.

- Basic form of boot processing
Code boot processing by using the void type function that has no arguments.
The following shows the basic form of boot processing in assembly.
     .public __boot
 
     .text   .cseg   text
 __boot :
 
     .........
 
     mov     #__kernel_start, r11       /*Jump to Kernel Initialization Module*/
     jarl    [r11], lp
- Internal processing of boot processing
Boot processing is a routine dedicated to initialization processing that is called from Initialization routine, without RI850V4 intervention.
Therefore, note the following points when coding boot processing.

- Coding method
Code boot processing using C or assembly language.
When coding in C, they can be coded in the same manner as ordinary functions coded.
When coding in assembly language, code them according to the calling rules prescribed in the compiler used.

- 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.

- Service call issue
Execution of the Kernel Initialization Module is not performed when boot processing is started. issue of service calls is therefore prohibited during boot processing.

The following lists processing that should be executed in boot processing.

1 ) Initializing the interrupt configuration register (INTCFG)

2 ) Setting of global pointer GP

3 ) Setting of element pointer EP

4 ) Setting stack pointer SP

5 ) Setting of text pointer TP (only when using the CCV850 compiler)

6 ) Initialization of ".kernel_data_init" section

7 ) Setting of the interrupt priority (manipulation of EIC.EIPn)

8 ) Selection of the interrupt vector method (manipulation of EIC.EITB)

9 ) Initialization of memory areas for uninitialized data (such as the bss section)

10 ) Initialization of Internal unit of CPU (such as the OS timer) and peripheral controllers (For initialization of the OS timer, see "9.2.1 Base clock timer interrupt".

11 ) Setting of the priority for the floating-point operation exception (only for the device incorporating the FPU)

12 ) Setting of the start address of the system information table in r6

13 ) Returning of control to the Kernel Initialization Module _kernel_start

Note 1 When initializing the interrupt configuration register (INTCFG), clear the ISPC bit to 0 to automatically update the ISPR value.

Note 2 If global pointer GP is modified outside the boot processing, correct operation is not guaranteed afterwards.

Note 3 When modifying element pointer EP in a processing program (such as a task or a cyclic handler), compiler option -Xep = callee must be specified (Property panel -> [Common Options] tabbed page -> [Register Mode] category -> [ep-register treatment] must be set to "Treat as callee-save").

Note 4 Setting of stack pointer sp is required only when the dedicated boot processing stack is used.

Note 5 The following shows sample codes for initializing ".kernel_data_init" section.

- CC-RH compiler
Use the RAM section area initialization function _INITSCT_RH in the CC-RH compiler to simplify the initialization code.
The following shows an example of assembly-language code for initializing ".kernel_data_init" section
.
 .section    ".INIT_BSEC.const", const
 
 .align      0x4
 
 .dw         #__s.kernel_data_init, #__e.kernel_data_init
 
 mov         r0, r6
 
 mov         r0, r7
 
 mov         #__s.INIT_BSEC.const, r8
 
 mov         #__e.INIT_BSEC.const, r9
 
 jarl        __INITSCT_RH, lp
- CCV850 compiler
First, define ".kernel_data_init" section (where the kernel initialization flag is allocated) with the CLEAR section attribute added in the link directive file so that the section is initialized in the boot processing.
The following shows a sample code in the link directive file.

MEMORY { ROM_MEMORY : ORIGIN = 0x00007000, LENGTH = 0x003f9000 RAM_MEMORY : ORIGIN = 0xfedf0000, LENGTH = 0x00010000 ............ } SECTIONS { ............ .kernel_data_initCLEAR :>RAM_MEMORY ............ }

Withthis definition, the ".kernel_data_init" section information is included in the runtime clear tables (__ghsbinfo_clear and __ghseinfo_clear) generated by the CCV850 compiler. The following shows a sample code for initializing the section area included in the runtime clear tables.
 /* initialize memory */
 meminit(void){
  	{
  		void **b = (void **)__ghsbinfo_clear;
  		void **e = (void **)__ghseinfo_clear;
 
  		while (b < e){
  			 void *s, *n, *v;
 
 			  s = (sint8 *)(*b++);
 			  v = *b++;
 			  n = *b++;
 			  memset(s, (sint32)v, (uint32)n);
   		}
  	}
 	............
Note 6 Manipulate within the Initialization routine the RINT bit in the reset vector base address (RBASE) and the RINT bit in the exception handler vector address (EBASE) to specify whether operation should be done in the reduced mode, which is necessary when using an entry file in the direct vector method.

Note 7 Manipulate within the Initialization routine the MKn bits (or EIMKn bits) in the EI level interrupt mask register (IMRm) to enable acceptance of EI level maskable interrupts.

Note 8 Set the priority of the floating-point operation exception to a higher value than the maximum priority of interrupts managed by the kernel.

14.2.2 System dependent information

System-dependent information is a header file (file name: userown.h) including various information that is required for the RI850V4, which is extracted as a user-own coding module.
- Basic form of system-dependent information
When coding system-dependent information, use a specified file name (userown.h) and specified macro names (KERNEL_USR_TMCNTREG and KERNEL_USR_BASETIME).
The following shows the basic form of system-dependent information in the C language.

#include <kernel_id.h> /*System information header file definition*/

#define KERNEL_USR_TMCNTREG 0xffec0004 /*I/O address*/

#define KERNEL_USR_BASETIME 250 /*time for one count (4MHz -> 250ns)*/
The following is a list of information that should be defined as system-dependent information.

- Definition of the system information header file
Include the system information header file output as a result of execution of the configurator for the system configuration file.

Note This information is necessary only when "Taking in long-statistics by software trace mode" is selected in the Property panel -> [Task Analyzer] tabbed page -> [Trace] category -> [Selection of trace mode].

- Basic clock timer information
Define as macros the I/O address (register base address + 0x4) for the counter register (OSTMn) and the time (in nanoseconds) for one count in the OS timer calculated according to the frequency of the OS timer operation.

Note This information is necessary only when "Taking in trace chart by software trace mode" or "Taking in long-statistics by software trace mode" is selected in the Property panel -> [Task Analyzer] tabbed page -> [Trace] category -> [Selection of trace mode].

14.3 Kernel Initialization Module

The kernel initialization module is a dedicated initialization processing routine provided for initializing the minimum required software for the RI850V4 to perform processing, and is called from Boot processing.

The following processing is executed in the kernel initialization module.

- Initializing management objects
Initializes the objects defined in the system configuration file (such as tasks and semaphores).

- Initializing the system time
Initializes the system time (to 0), which is updated in units of the Base clock interval: tim_base when an EI level maskable interrupt defined in the Base clock timer exception code: tim_intno occurs.

- Activating tasks
Moves the tasks whose Attribute: tskatr (such as coding language and initial activation state) is defined as TA_ACT from the DORMANT state to the READY state.

- Starting cyclic handlers
Moves the cyclic handlers whose Attribute: cycatr (such as coding language and initial activation state) is defined as TA_STA from the non-operational state (STP state) to the operational state (STA state).

- Calling initialization routines
Calls the initialization routines defined in the Initialization routine information in the order of definitions in the system configuration file.

- Returning control to the scheduler
Selects the most suitable one of the tasks placed in the READY state and moves the task from the READY state to the RUNNING state.

Note The kernel initialization module is included in the system initialization processing provided by the RI850V4. The user is not required to code the kernel initialization module.