CHAPTER 2 SYSTEM BUILDING
This chapter describes how to build a system (load module) that uses the functions provided by the RI600PX.
System building consists in the creation of a load module using the files (kernel library, etc.) installed on the user development environment (host machine) from the RI600PX's supply media.
The sample programs are stored in the following folder. The source files are stored in "appli" sub-folder.
In the RI600PX, the processing program is classified into the following five types, in accordance with the types and purposes of the processing that should be implemented.
- Tasks
A task is processing program that is not executed unless it is explicitly manipulated via service calls provided by the RI600PX, unlike other processing programs (interrupt handler, cyclic handler and alarm handler).
A task is processing program that is not executed unless it is explicitly manipulated via service calls provided by the RI600PX, unlike other processing programs (interrupt handler, cyclic handler and alarm handler).
- Task Exception Handling Routines
When task exception is requested to a task, the task exception handling routine defined for the task is invoked. The requested exception code is passed to the task exception handling routine.
When task exception is requested to a task, the task exception handling routine defined for the task is invoked. The requested exception code is passed to the task exception handling routine.
- Cyclic Handlers
The cyclic handler is a routine started for every specified cycle time.
The RI600PX handles the cyclic handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
The cyclic handler is a routine started for every specified cycle time.
The RI600PX handles the cyclic handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
- Alarm Handlers
The alarm handler is a routine started only once after the specified time.
The RI600PX handles the alarm handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
The alarm handler is a routine started only once after the specified time.
The RI600PX handles the alarm handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
- Interrupt Handlers
The interrupt handler is a routine started when an interrupt occurs.
The RI600PX handles the interrupt handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when an interrupt occurs, and the control is passed to the interrupt handler.
The interrupt handler is a routine started when an interrupt occurs.
The RI600PX handles the interrupt handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when an interrupt occurs, and the control is passed to the interrupt handler.
Note For details about the processing programs, refer to "CHAPTER 4 TASK MANAGEMENT FUNCTIONS", "CHAPTER 6 TASK EXCEPTION HANDLING FUNCTIONS", "CHAPTER 10 TIME MANAGEMENT FUNCTIONS", "CHAPTER 12 INTERRUPT MANAGEMENT FUNCTIONS".
Code the SYSTEM CONFIGURATION FILE required for creating information files that contain data to be provided for the RI600PX.
Note For details about the system configuration file, refer to "CHAPTER 20 SYSTEM CONFIGURATION FILE".
- Access Exception Handler (_RI_sys_access_exception( ) )
The access exception handler will be invoked when a task or task exception handling routine accesses the memory that has not been permitted.
The access exception handler will be invoked when a task or task exception handling routine accesses the memory that has not been permitted.
- Base Clock Timer Initialization Routine (_RI_init_cmt_knl( ))
The base clock timer initialization routine is called at starting the RI600PX.
The base clock timer initialization routine is called at starting the RI600PX.
- System down routine (_RI_sys_dwn__( ))
The system down routine is called when the system down occurs.
The system down routine is called when the system down occurs.
- Section information file (User-Own Coding Module)
Informations for uninitialized data sections and initialized data sections are defined in the section information file.
Informations for uninitialized data sections and initialized data sections are defined in the section information file.
Run a build on CubeSuite+ for files created in sections from "2.2 Coding Processing Programs" to "2.4 Coding User-Own Coding Module", and library files provided by the RI600PX and C compiler package, to create a load module.
Note See "RI Series Start", "CubeSuite+ Start" and the Release Notes of this product for details about creating a new project or loading an existing one.
Note See "CubeSuite+ RX Build" for details about adding or removing build target files for the project and updating the dependencies.
Note Specify "cfg" as the extension of the system configuration file name. If the extension is different, "cfg" is automatically added (for example, if you designate "aaa.c" as a file name, the file is named as "aaa.c.cfg").
Note 1 If the system configuration file is added to the Project Tree panel, the Realtime OS generated files node is appeared.
The following information files are appeared under the Realtime OS generated files node. However, these files are not generated at this point in time.
The following information files are appeared under the Realtime OS generated files node. However, these files are not generated at this point in time.
Note 2 When replacing the system configuration file, first remove the added system configuration file from the project, then add another one again.
Note 3 Although it is possible to add more than one system configuration files to a project, only the first file added is enabled. Note that if you remove the enabled file from the project, the remaining additional files will not be enabled; you must therefore add them again.
On the [System Configuration File Related Information] tab, set the output of realtime OS generation files, etc.
Set the options for the compiler, assembler, linker, and the like.
Please be sure to refer to "2.6 Build Options".
Please be sure to refer to "2.6 Build Options".
The service call information file (mrc files) are generated to the same folder as object files at compilation of the source files that includes kernel.h file.
The name of service calls used in the source files are outputted in the mrc files. It is necessary to input all files to the table generation utility mkritblpx. If there is a leaking in the input file, service call modules that application uses might not be linked. In this case, the system down will occur when the service call is issued.
On the other hand, if the mrc files which are generated in the past and which is invalid in now are input to the mkritblpx, the service call modules that are not used in the application may be linked. In this case, there is no problem in the operation of the RI600PX but the module size uselessly grows.
Specify "-ri600_preinit_mrc" compiler option for the source file that includes kernel.h file even if this option is not specified, there is no problem in the operation of the RI600PX but the service call module that is not used in the application may be linked.
When application libraries are used, the mrc files that is generated at compilation of the library source should be inputted to the mkritblpx. If this way is difficult for you, make mrc file where name of using service calls is described (see belows), and input the mrc file to the mkritblpx.
It is necessary to set "-nostuff" option for the boot processing file ("resetprg.c" in the sample project) like a mention in "17.2.3 Compiler option for boot processing file". If not, the RI600PX does not work correctly.
To set "-nostuff" option only for the boot processing file, please set any of the following in the [Individual Compile Options] tab of [Property] panel for the boot processing file. To set "-nostuff" option for all, please set any of the following in the [Compiler Options] tab of [Property] panel for [CC-RX (Build Tool)].
1 ) Set in the [Object] category
Like Figure 2-6, set "Yes" in [Allocates uninitialized variables to 4-byte boundary alignment sections], [Allocates initialized variables to 4-byte boundary alignment sections] and [Allocates const qualified variables to 4-byte boundary alignment sections].
Like Figure 2-6, set "Yes" in [Allocates uninitialized variables to 4-byte boundary alignment sections], [Allocates initialized variables to 4-byte boundary alignment sections] and [Allocates const qualified variables to 4-byte boundary alignment sections].
The kernel libraries are stored in the folders described in Table 2-1. Note, CubeSuite+ links the appropriate kernel library automatically, you need not consider the kernel libraries.
Note 1 <ri_root> indicates the installation folder of RI600PX.
The default folder is "C:\Program Files\Renesas Electronics\CubeSuite+\RI600PX".
The default folder is "C:\Program Files\Renesas Electronics\CubeSuite+\RI600PX".
Note 2 The kernel described in item-2 of Table 2-1 is linked when compiler V2.01.00 or later is used. In the case of others, the kernel library described in item-1 of Table 2-1 is linked.
1 ) Naming convention of sections
In order to arrange sections to suitable memory objects, defining the naming convention of sections like the following examples is recommended.
In order to arrange sections to suitable memory objects, defining the naming convention of sections like the following examples is recommended.
2 ) RI600PX sections
Table 2-2 shows RI600PX sections.
The application must not use the RI600PX except SURI_STACK and BURI_HEAP.
Table 2-2 shows RI600PX sections.
The application must not use the RI600PX except SURI_STACK and BURI_HEAP.
- Fixed-sized memory pool area created by the system configuration file (when the section is omitted)
|
The configurator cfg600px generates fixed vector table/exception vector table as FIX_INTERRUPT_VECTOR section according to the contents of definitions of "interrupt_fvector[]" in the system configuration file.
- At the time of RXv1 architecture use
In the RXv1 architecture, fixed vector table is being fixed to address 0xFFFFFF80. It is necessary to arrange the FIX_INTERRUPT_VECTOR section at address 0xFFFFFF80.
When the FIX_INTERRUPT_VECTOR section is not arranged to address 0xFFFFFF80, RI600PX does not operate correctly.
In the RXv1 architecture, fixed vector table is being fixed to address 0xFFFFFF80. It is necessary to arrange the FIX_INTERRUPT_VECTOR section at address 0xFFFFFF80.
When the FIX_INTERRUPT_VECTOR section is not arranged to address 0xFFFFFF80, RI600PX does not operate correctly.
- At the time of RXv2 architecture use
In the RXv2 architecture, the name of fixed vector table is changed into exception vector table, and can set up the start address by EXTB register. The initial value of EXTB register at the time of reset is 0xFFFFFF80, it is same as fixed interrupt vector table in RXv1 architecture.
Usually, please arrange the FIX_INTERRUPT_VECTOR section to address 0xFFFFFF80.
When the FIX_INTERRUPT_VECTOR section is not arranged to address 0xFFFFFF80, "interrupt_fvector[31]" (reset vector) in the system configuration file is ignored. Please generate the reset vector (address 0xFFFFFFFC) by the user side. And initialize EXTB register to the start address of FIX_INTERRUPT_VECTOR section in Boot processing function (PowerON_Reset_PC( ))
In the RXv2 architecture, the name of fixed vector table is changed into exception vector table, and can set up the start address by EXTB register. The initial value of EXTB register at the time of reset is 0xFFFFFF80, it is same as fixed interrupt vector table in RXv1 architecture.
Usually, please arrange the FIX_INTERRUPT_VECTOR section to address 0xFFFFFF80.
When the FIX_INTERRUPT_VECTOR section is not arranged to address 0xFFFFFF80, "interrupt_fvector[31]" (reset vector) in the system configuration file is ignored. Please generate the reset vector (address 0xFFFFFFFC) by the user side. And initialize EXTB register to the start address of FIX_INTERRUPT_VECTOR section in Boot processing function (PowerON_Reset_PC( ))
4 ) "aligned_section" linker option
The "aligned_section" linker option must be specified for following sections.
The "aligned_section" linker option must be specified for following sections.
5 ) Attention concerning L and W section
The L section is literal area, and the W section is switch statement branch table area. These section are generated by the compiler.
The name of these section cannot be changed by using "#pragma section" directive.
Please note it as follows when a function executes as a task and the L and W section may be generated by compiling the source file.
The L section is literal area, and the W section is switch statement branch table area. These section are generated by the compiler.
The name of these section cannot be changed by using "#pragma section" directive.
Please note it as follows when a function executes as a task and the L and W section may be generated by compiling the source file.
A ) All functions in the source file executes only as tasks which belong to same domain
Especially, there are no points of concern. The L and W section should be a memory object to be able to read from the domain.
Especially, there are no points of concern. The L and W section should be a memory object to be able to read from the domain.
B ) Functions in the source file executes as tasks which belong to separate domains
Because a different name cannot be given to literal area and switch table area of each function, it is impossible to divide these area to separate memory object. Therefore, separate functions in order to the domain at running to individual source file and apply (A), or the L and W section should be a memory object to be able to read from all domain.
Because a different name cannot be given to literal area and switch table area of each function, it is impossible to divide these area to separate memory object. Therefore, separate functions in order to the domain at running to individual source file and apply (A), or the L and W section should be a memory object to be able to read from all domain.
About sections described in DTBL of the Section information file (User-Own Coding Module), it is necessary to perform setting to map sections placed on ROM to sections placed on RAM by using "-rom" linker option. Set [Link Options] tab of [Property] panel for [CC-RX (Build Tool)] like Figure 2-8.
