Porting Paulus on Renesas RL78F14

File structure

After installation of Paulus the source code is stored in the file structure shown in Table 1 describes the contents.

Table 1: File structure

The initialization of the CAN controller is done in module rl78f14 /rl78_ can.c.

In module rl78f14 /rl78_ init.c the I/O pins for the CAN interface have to be initialized.

In module rl78f14 /rl78_ init.c there must be the functions getBitRate() and getNodeId() available. Usually the CANopen network parameters are provided by reading jumpers or by loading from flash memory.

Development environment

Paulus on the platform Renesas RL78F14 was developed with the Renesas CS+ v8.02 (before named was CubeSuite). Implemented and tested was the Paulus on the Renesas Starterkit R5F10PPJ (with a R5F10PPJ CPU device typ).

Paulus configuration

In general the initialization function initializes only the absolutely necessary peripherals like clock system, CAN controller, memory management as needed by Paulus and a timer for Heartbeat or LSS. Nevertheless, there might be situations where it makes sense that Paulus initializes other functionalities which are later used by the application as well. As an example consider the serial interface for debug messages.

CAN bit rate

The CAN bit rate is coded by the index of the CAN bit timing table according to /CiA-305/. The index of the default CAN bit rate is specified about the compiler-define BITRATE_INDEX_<bit_rate> in /rl78f14/bl_config.h:

#define BL_USED_BITRATE_INDEX   BITRATE_INDEX_125K

The default CAN bit rate is 125 kbit/s and can be changed by LSS services. The LSS services are described in /Paulus_man/ and base on /CiA-305/. The supported CAN bit rates are depending on the clock of the CAN controller and are listed in /rl78f14 /rl78f14 _can.c.

Debug output

By the compiler-define DEBUG a debug output (printf) can be activated. But Debug output is not implemented. No usart interface available on evalboard. The compiler-define is set in file /rl78f14/bl_config.h:

#define DEBUG 1

In general the initialization function will initialize only the absolutely necessary peripherals like clock system, CAN controller, memory management as needed by Paulus. Nevertheless, there might be situations where it makes sense that Paulus initializes other functionalities which are later used by the application as well. As an example consider the serial interface for debug messages.

Generating application software

The application software consists of an application header and an application program.

Open

The application program has to be prepared for download by the following steps:

•     build the application program in binary format

•     calculate the CRC of the application program, build the application header and generate the application software to download

•     configure the start address of the application software in Paulus

Paulus checksum

The program paulus_cksum calculates the CRC checksum of the binary application program generates the application header and stores the application header and the application program in a new file. This file can be loaded in the device by Paulus.

Unused bytes in the application header are set to 0x00 with the RL78F14. The length of the application header is 256 bytes.

Example: The download file (s1_download.bin) for the application program s1_rl78f14.bin is generated about Windows console:

Besides checking the CRC Paulus checks also the size of the application header. A size of 0 is invalid. An application may destroy the ’valid’ information by overwriting the size with 0. That is always possible on the RL78F14 FLASH, because the byte content is 0xFF after erasing.

More detailed information from this tool can find in /Paulus_CRC/.

Start address

It is important that the start address of the application software in the flash memory and the information in the Paulus configuration in rl78f14/rl78_flash.h are identical. The application software is stored as a separate program in the flash memory additionally to the bootloader program. Therefore the application software is flashed to:

#define FLASH_PROGRAM_START_ADR  0x6000

The length of the application header is 256 byte. The program start of the application is at address (FLASH_PROGRAM_START_ADR + 256 bytes).

Memory

Shared RAM

The shared RAM for data exchange between bootloader and application starts at address 0xFFB00. The size of the shared RAM is specified in rl78f14/bl_interface.h by the compiler-define BL_JUMPCODE_SIZE. The shared memory is installed in rl78f14/bl_interface.h as follow:

#pragma location=0xFFB00

UNSIGNED8 jumpcode[BL_JUMPCODE_SIZE];

The keyword for the re-start of the application program is set in byte 0-3 of jumpcode. Paulus uses the keyword “APPL” or “BOOT” to start the application program, see /Paulus_man/.

Additional we need a function pointer for every interrupt vector used by the application.

The reason for this pointers is described in a special handling interrupt vectors.

Special handling interrupt vectors

The bootloader and the application must share the interrupt vectors because the RL78 interrupt vectors are located on a constant memory address. The interrupt vectors specify addresses of skeleton routines, which include function pointers located in RAM on interupt handlers.

The skeleton routines for the CAN interrupts and the timer interrupt for CANopen are defined in Paulus. Paulus initializes the function pointers on dummy interrupt handlers because Paulus does not use interrupts.

The skeleton routines and function pointers must be re-initialized in the application before the interrupts are enabled and used. If the application needs further or other interrupts then you have to adapt the skeleton routines and the function pointers and their initialization.

Example for the CAN-interrupt: (in file rl78f14/bl_interface.c)

Flash

The total size of the RL78F14 (R5F10PPJ) flash on evalboard is 256Kb. The current implementation of Paulus occupies a memory area of 24Kb from this. Therefore 232 Kb flash memory area available for the application software.

The RL78 interrupt vectors are located at the constant address 0x0000 followed by the code of Paulus. The Renesas Flash-Selfprogramming library is located at address 0x2000 into the bootloader area. The application area begins with code and const data at address 0x6000.

The flash area for configuration data of Paulus is located at the Flash address 0x5C00 and following. On this address and the following Paulus stores the node-ID and the CAN bit rate index during the execution of the LSS service “LSS store configuration“. The addresses are configurable in <target>/bl_interface.h:

#define FLASH_ADDRESS_NODEID           0x5C00

#define FLASH_ADDRESS_BITRATE_INDEX    0x5C01

After the next re-start Paulus read this flash addresses, saved the values in an own RAM variables and uses this node-ID and this CAN bit rate index for communication. The new CAN bit rate cannot be activated by NMT-Command Reset Application. If the LSS services are not used, Paulus uses the node-ID and CAN bit rate index configured in rl78f14 / bl_config.h.

Example application

CANopenSlave1 is an example for an application program. The directory example/ CANopenSlave1 contain the compiler project and the application-specific functions. For compilation the CANopen Library and the suitable driver package is necessary. The CANopen Library and the driver package belong not to the delivery scope of Paulus. The binary application software in example/ CANopenSlave1/bin/s1_rl78f14_csplus_download.bin can be used for a quick start.

The linker settings of this example project is adapted on these memory requirements.

See settings from CS+ / CC-RL (Build-Tool) / link options:

Open

For the jump into the application about Paulus, we need a fixed entry point, with a fixed address. This is be generated in section .startup. At this point in the code is placed the assembler file (appl_startup.asm) that performs the jump to the real startup routine (label _start). The real startup routine can then be variable in the code (section .text).

See file appl_startup.asm:

The fixed address for the application .startup section must match with the application entry point from Paulus. (e.g. FLASH_PROGRAM_START_ADR + 256 bytes = 0x6100).

In addition, the generated output file must be trimmed in the address area. This is necessary because the fixed CPU memory areas (such as Vector table, option bytes ...) are in the area of Paulus and can not be used twice or overwritten by the application. The start address should be the application entry point address.

See settings from CS+ / CC-RL (Build-Tool) / Hex output options:

This example has included source files bl_interface.c, bl_interface.h from bootloader. The application program can request an update by jumping back into Paulus by writing of the program control command start application program (value 1) on object 1F51h/1. The application program calls the macro BOOTLOADER_JUMP(APPL). This call is implemented in usr_301.c /sdoWrInd(). The application program stores the keyword “APPL” in the shared RAM and jumps into Paulus. Paulus is re-started and stays running until the application program is started by command.

References

Table 2: References