Porting Paulus on Renesas RA6M5

File structure

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

Table 1: description of directories

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

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

In module ra6m5/ 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 of Renesas RA6M5 was developed with the Renesas e2studio v2022-04 (GCC
compiler) on Board Renesas EK-RA6M5.

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 / ra6m5 /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 /ra6m5/ra6m5 _can.c. The value FFh for segment2 marks unsupported CAN bit rates.

Heartbeat producer

The clock for the activation of Heartbeat producer messages is generated by timer Systick with a period of
1 ms. This is a hard setting in module ra6m5 / ra6m5_init.c. The device default heartbeat tick is 2s.

Read Identity object 0x1018 from NVM

If the user needs the values for the identity object from Paulus (Vendor-ID, Product code, Revision number, Serial number) in different devices with different values then the following define must be activated.

#define BL_IDENTITY_OBJECT_1018_READ_FROM_NVM

If this activated, in the startup from Paulus the data for this object are read from a predefined flash area. The address from this area is defined:

#define BL_CONF_IDENTITY_BLOCK     0x00007200 /* default address */

The user must ensure that his desired data is written on this address. This is possible for example with a Flash Programmer tool.

Debug output

By the compiler-define BL_DEBUG a debug output is prepared but not implemented. The compiler-define is set in file /ra6m5 /bl_config.h:

#define BL_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, see Figure 2.

Open

Figure 1: structure of application software

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

•  develop your application in a working state, include the interface sources (bl_interface.c and
  necessary headers) of the bootloader in the application project

• configure the start address of the application software in Paulus, see chapter 2.2

• shift the flash start address of your application according to the memory allocation described

• 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, see chapter 2.1

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 ra6m5. The length of the application
header is 0x200 bytes. The input file (s1_renesas_ra6m5.bin) for this tool is a raw binary. This can be
generated via e2studio.
Example: The download file for the application program s1_ra6m5_download.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 ra6m5 FLASH, because the byte content is 0x00 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 ra6m5/ra6m5_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   0x00008000u // default configuration

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

Memory

Shared RAM

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

/* jumpcode placed on ram address 0x20000000 /
/ only used for GCC */
attribute((section (".my_ram"))) 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/.

Flash

The total size of the ra6m5 flash is 2Mb (type R7FA6M5BH3CFC). The current implementation of Paulus
occupies a memory area of 32Kb from this. Therefore 2016Kb (less 0x200 byte crc header) flash memory
area available for the application software.

Open

Figure 2: Flash memory mapping

On power-on, as soon as execution control goes to the default reset handler, the boot up sequence
executes and execution control jumps to the user boot code. The boot code always starts in the paulus, this
decides whether the application is started.
The flash area for LSS configuration data of Paulus is located at address 0x00007000 (default address,
adaptable by user). 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 0x00007000
#define FLASH_ADDRESS_BITRATE_INDEX 0x00007001

/* additional need some bytes in RAM for NodeId and bitrateIndex saved in a special section */

/* need some bytes in Flash, NodeId and bitrateIndex saved in a special section */

__attribute__((section (".my_ram"))) UNSIGNED8 flashNodeId=0xFF; /*  read from flash address */

__attribute__((section (".my_ram"))) UNSIGNED8 bitrateIndex=0xFF; /* read from next flash address */

After the next re-start Paulus 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 ra6m5/bl_config.h.

For the additional feature “Read Identity object 0x1018 from NVM” the following struct is prepared:

The Paulus fills this struct in startup with the data from the predefined flash area. Starting at address
0x00007200 and following (4 x u32 values). Previously the data was written on these addresses e.g. via a
simple write operation in the e2studio Debug session:

Filled with example data:

UNSIGNED32 identity_block.VendorId       = 0x00000034;       

UNSIGNED32 identity_block.ProductCode    = 0x00000011;   

UNSIGNED32 identity_block.RevisionNumber = 0x0000102A; 

UNSIGNED32 identity_block.SerialNumber   = 0x00000001;

After reading the data in the struct these are used for CANopen communication (e.g read items from object 0x1018 - especially for the LSS service).

Example application 

CANopenSlave1 is an example for an application program. The directory example/
CANopenSlave1_RA6M5/ /examples/s1_ra6m5 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_RA6M5/bin/s1_ra6m5_download.bin can be used for a
quick start.
The linker file of this example project is adapted on these memory requirements.
See e2studio memory and sections screens from linker-file (fsp.ld) from example:

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