Renesas RX600 Series Installation and operating instructions

APPLICATION NOTE
R01AN0339EU0203 Rev. 2.03 Page 1 of 29
Mar 23, 2013
RX600 Series
CAN Application Programming Interface
Introduction
This application note introduces the Renesas CAN Application Programming Interface and explains how to use it to
send, receive, and monitor data on the CAN bus. It also explains briefly some features of the CAN peripheral.
Bundled with this application note comes the CAN API driver source code files config_r_can_rapi.h, r_can_api.h, and
r_can_api.c. Note that there are alternative ways to write the driver functions. For example you may want to write your
own driver functions to tailor a specific behavior.
The RX CAN peripheral has 32 CAN mailboxes to read from and write to in order to communicate over CAN. These
mailboxes are message ‘buffers’ and will hold the CAN data frame until it is overwritten by another incoming frame, or
rewritten by the application. Each mailbox can be configured dynamically to transmit or receive. Usually, most are
configured to receive and a few to transmit.
A CAN API is also available from Renesas for the CAN equipped MCUs in the families R32C, M32C, M16C, R8C, for
SH RCAN-ET MCUs SH7286, SH7137, and for the SH7216. Most, if not all, CAN MCUs are available on Renesas
Starter Kit boards. Demonstration source code for the API is available for all these devices and runs the same demo
across all of these devices so that they can be connected and run together.
The term ‘mailbox’, or in some literature ‘message box’ or ‘message buffer’ refers to the physical location where
messages are stored inside the MCU’s CAN peripheral. In this document we will use the term ‘mailbox’.
Target Device
RX600 Series of MCUs with CAN.
R01AN0339EU0203
Rev. 2.03
Mar 23, 2013

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 2 of 29
Mar 23, 2013
Contents
1. CAN Basics.......................................................................................................................................3
2. The CAN Peripheral..........................................................................................................................3
3. Communication Layers .....................................................................................................................4
4. The Mailbox.......................................................................................................................................4
5. Using Extended ID ............................................................................................................................4
6. Adding the CAN API to Your Project.................................................................................................5
7. The CAN Config File .........................................................................................................................5
8. The CAN API.....................................................................................................................................6
9. CAN Interrupt Checklist...................................................................................................................25
10. Test Modes......................................................................................................................................25
11. Time Stamp.....................................................................................................................................28
12. CAN Sleep Mode.............................................................................................................................28
13. CAN FIFO........................................................................................................................................28
Website and Support...............................................................................................................................29
Revision Record......................................................................................................................................30
General Precautions in the Handling of MPU/MCU Products.................................................................31

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 3 of 29
Mar 23, 2013
1. CAN Basics
CAN was designed to provide reliable, error-free network communication for applications in which safety and real-time
operation cannot be compromised. Its main attributes can be summarized as follows:
• High reliability and noise immunity
• Fewer connections
• Flexible architecture
• Error handling through peripherals
• Low wiring cost
• Scalability
The MCU and bus connectors need only two pins. Therefore, a CAN network is more reliable than other networking
schemes that need more wires and connections. Adding new nodes is simple; just tap the bus wire at any point.
CAN is based on a “multiple master, multiple slave” topology. Message or Data Frames transmitted do not contain the
addresses of either the transmitting node or of any intended receiving node. This means that any node can act as master
or slave at any time. Messages can be broadcast, or sent between nodes depending on which nodes at a particular
moment are listening to a certain ID. New nodes can be added without having to update others. Such design flexibility
makes it practical for building intelligent, redundant, and easily reconfigured systems.
Bit rate determines the number of nodes that can be connected and cable length. Allowed CAN data bit rates are: 62.5,
125, 250, 500 Kbps and 1 Mbps. At the highest speed, the network can support 30 nodes on a 40-meter cable. At lower
speeds, the network can support more than 100 nodes on a 1000-meter cable.
The basic building blocks of a CAN network are a CAN microcontroller, the firmware to run it, a CAN transceiver to
drive and read the bus signal, and a physical bus media (2 wires). Choose a CAN MCUs with enough mailboxes to fit
your applications.
2. The CAN Peripheral
The Protocol Controller of the CAN peripheral in your CAN MCU must via the CAN Tx and Rx MCU pins be
connected to a bus transceiver located outside the chip. The Protocol Controller reads and writes to the peripheral
mailboxes depending on how they are configured. The configuration is done through the CAN Special Function
Registers described in your MCU’s HW manual. As the registers in the CAN peripheral must be configured and read in
the proper sequence to achieve useful communication, a CAN API greatly simplifies this – the API takes numerous
tedious issues and does them for you.
After initializing the peripheral, all you need to do is use the receive and transmit API calls, and on a regular basis
check for any CAN error states. If an error state is encountered the application can just wait and monitor for the
peripheral to recover, as the CAN peripheral takes itself on or off line depending on its state. After a recovery is
discovered, the application should restart.

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 4 of 29
Mar 23, 2013
3. Communication Layers
The figure below shows the CAN communication layers, with the application layer at the top and the hardware layer at
the bottom.
Figure 1. CAN physical and source code layers.
In this document we will not discuss any higher level protocols such as CANopen or DeviceNet. (For some Renesas
CAN MCUs there is a CANopen solution. Contact your sales representative.)
4. The Mailbox
When a CAN message is to be sent, it must first be written to a mailbox by the application firmware. It will then be sent
automatically as soon as the bus becomes idle, unless a message of lower ID is sent by another node. If a mailbox is
configured to receive, the message is written to the mailbox by the Protocol Controller and must be copied by the user,
using the API, to user memory area quickly to free the mailbox for the next message coming from the network.
The API calls will do all the writing to and from the mailbox for you. All you have to do is provide application data
frame structures which the API functions can write incoming messages to and copy outgoing messages from. It is
recommended to have a least one structure for outgoing messages, and one for incoming. For outgoing messages this
could be a local variable (on the stack). For incoming messages one for each mailbox is recommended. This CAN data
frame structure, of type can_std_frame_t, is provided by the API header file and has the following structure:
typedef struct
{
uint32_t id;
uint8_t dlc;
uint8_t data[8];
} can_frame_t;
Note that the timestamp is not included in this structure, but can easily be added.
Aside from CAN bus arbitration, priority is determined using the lowest mailbox number - except for SH (RCAN-ET)
where the highest mailbox has priority. This is true for both transmit and receive operations. If two mailboxes have
been set with the same CAN ID, the lowest mailbox number has the highest priority. Because of this, tf two mailboxes
are configured to receive with the same ID, one mailbox will never receive a message.
5. Using Extended ID
To use extended ID, the FRAME_ID_MODE must be set as explained in 0 below.
When Extended CAN is enabled, the API functions ending in ‘Xid’ can be called. These functions will automatically
cause the ID field of the CAN mailbox to be formatted to use extended ID. In other words the user need only call these
Xid-functions, and the ID value passed in the can_frame_t structure will be sent as a 29-bit ID (instead of 11-bit).

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 5 of 29
Mar 23, 2013
6. Adding the CAN API to Your Project
Follow the steps below to add the CAN API code to your project. These steps assume that the Flash API has already
been added to your project.
1. Copy the r_can_api directory (packaged with this application note) to your project directory.
2. Add the file r_can_api.c to your project.
3. Add an include path to the r_can_api directory.
4. Add an include path to the r_can_api\src directory.
5. Configure the middleware with config_r_can_api.h.
7. The CAN Config File
It may be necessary to make modifications to the config_r_can_rapi.h file to customize the application
for the way you wish to run it. For example, there is the option of running in CAN polled mode or CAN
interrupt mode. config_r_can_rapi.h is the place where this is selected.
Do not change anything in the r_can_api.c file, which contains the Renesas CAN API functions for your Renesas
MCU.
Interrupts vs. Polling
USE_CAN_POLL
Include the macro USE_CAN_POLL if you want to poll CAN mailboxes for messages received and sent. Do not
include to use the CAN interrupts.
CAN Interrupt Settings
CAN0_INT_LVL
Sets the CAN interrupt level.
USE_CAN_API_SEARCH
Not implemented in the latest code releases to not cause confusion with the existing example code. If you have many
mailboxes configured and alot of CAN traffic, you may want to consider using this feature. Please see the MCU
hardware manual.
Max Time to Poll a Register
MAX_CANREG_POLLCYCLES
Max loops to poll a CAN register bit for expected value. If you are using polled mode, and If you wish to wait a certain
time to check that a mailbox has recieved a frame, increase this value. This can be set to a very low value, but do not set
to zero or the mailbox may not be chacded at all.!
Transceiver Control Pin Mapping
TRANSCEIVER STANDBY, TRANSCEIVER ENABLE
Specify where you have the transceiver control pins connected. Some transceivers may have other control pins. You
would have to configure this yourself.
Using Standard/Extended ID
FRAME_ID_MODE
Select what type of CAN ID type to enable in the driver, that is, usage of 11-bit or 29-bit IDs.
FRAME_ID_MODE can be set to STD_ID_MODE, EXT_ID_MODE, or MIXED_ID_MODE. The first two settings
enable only those functions belonging to that ID mode. If it is set to mixed mode, the whole API becomes available. It is
preferable to not set mixed mode for the driver if it is to be used in a network using only one ID type. Messages with the
wrong ID type for the network will only cause wasted bandwidth (no node will receive them).

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 6 of 29
Mar 23, 2013
CAN Bitrate Settings
See API R_CAN_SetBitrate below and the file config_r_can_rapi.h.
8. The CAN API
The API is a set of functions that allow you to use CAN without having to commit attention to all the details of setting
up the CAN peripheral, to be able to easily have your application communicate with other nodes on the network.
Figure 2. The CAN API functions.
Note that the hardware manual is the absolute reference for behavior.
The first group of functions (orange) in Figure 2 is used to initialize the CAN peripheral registers and configure the
MCU’s CAN and transceiver ports. The first function, R_CAN_Create, will by default invoke the rest of the
initialization functions.
The Transmit functions (blue) are used to set up a mailbox to transmit and to check that it actually was sent successfully.
The Receive functions (green) are used to set up a mailbox to receive and to retrieve a message from it.
The Error function (red) checks the CAN bus status of the node.
8.1 API Return Codes
R_CAN_OK Action completed successfully.
R_CAN_NOT_OK Action did not complete successfully.
Usually a more specific return code is used, see below.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_BAD_ACTION_TYPE No such action type exists for this function.
R_CAN_MSGLOST Message was overwritten or lost.
R_CAN_NO_SENTDATA No message was sent.
R_CAN_RXPOLL_TMO Polling for received message timed out.
Initialization, Port and Peripheral Control
R_CAN_Create (uint32_t ch_nr);
R_CAN_PortSet (uint32_t ch_nr, uint32_t
action_type
);
[action_type = ENABLE, DISABLE]
R_CAN_Control (uint32_t ch_nr, uint32_t
action_type
);
[action_type = ENTERSLEEP_CANMODE, EXITSLEEP_CANMODE, RESET_CANMODE,
HALT_CANMODE, OPERATE_CANMODE, CANPORT_TEST_LISTEN_ONLY,
CANPORT_TEST_0_EXT_LOOPBACK, CANPORT_TEST_1_INT_LOOPBACK,
CANPORT_RETURN_TO_NORMAL]
R_CAN_SetBitrate (uint32_t ch_nr);
Send
R_CAN_TxSet (uint32_t ch_nr, uint32_t mbox_nr, can_std_frame_t* frame_p, uint32_t frame_type);
R_CAN_TxSetXid (uint32_t ch_nr, uint32_t mbox_nr, can_frame_t* frame_p, uint32_t frame_type);
R_CAN_Tx (uint32_t ch_nr, uint32_t mbox_nr);
R_CAN_TxCheck (uint32_t ch_nr, uint32_t mbox_nr);
R_CAN_TxStopMsg (uint32_t ch_nr, uint32_t mbox_nr);
Receive
R_CAN_RxSet (uint32_t ch_nr, uint32_t mbox_nr, uint32_t stid,
uint
32_t frame_type);
R_CAN_RxSetXid (uint32_t ch_nr, uint32_t mbox_nr, uint32_t xid, uint32_t frame_type);
R_CAN_RxRead (uint32_t ch_nr, uint32_t mbox_nr, can_std_frame_t* frame_p);
R_CAN_RxPoll (uint32_t ch_nr, uint32_t mbox_nr);
R_CAN_RxSetMask (uint32_t ch_nr, uint32_t sid_mask_value, uint32_t mask_reg_nr);
Error Check
R_CAN_CheckErr (uint32_t ch_nr);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 7 of 29
Mar 23, 2013
R_CAN_SW_WAKEUP_ERR The CAN peripheral did not wake up from Sleep mode.
R_CAN_SW_SLEEP_ERR The CAN peripheral did enter Sleep mode.
R_CAN_SW_HALT_ERR The CAN peripheral did not enter Halt mode.
R_CAN_SW_RST_ERR The CAN peripheral did not enter Reset mode.
R_CAN_SW_TSRC_ERR Time Stamp error.
R_CAN_SW_SET_TX_TMO Waiting for previous transmission to finish timed out.
R_CAN_SW_SET_RX_TMO Waiting for previous reception to complete timed out.
R_CAN_SW_ABORT_ERR Wait for abort timed out.
R_CAN_MODULE_STOP_ERR Whole CAN peripheral is in stop state (low power). Perhaps the PRCR
register was not used to unlock the module stop register.
CAN bus status return codes
R_CAN_STATUS_ERROR_ACTIVE Bus Status: Normal operation.
R_CAN_STATUS_ERROR_PASSIVE Bus Status: The node has sent at least 127 Error frames for either
the Transmit Error Counter, or the Receive Error Counter.
R_CAN_STATUS_BUSOFF Bus Status: The node’s Transmit Error Counter has surpassed 255
due to the node’s failure to transmit correctly.

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 8 of 29
Mar 23, 2013
R_CAN_Create
Initializes the CAN peripheral, sets bitrate, masks, mailbox defaults and configures
CAN interrupts
This function will by default invoke the rest of the initialization functions. It also sets the CAN interrupt levels. It will
also call all other relevant set-up functions such as
•R_CAN_SetBitrate()
•R_CAN_RxSetMask ()
•R_CAN_PortSet ()
Format
uint32_t R_CAN_Create(const uint32_t ch_nr);
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. The number of available channels
depends on part. 1-4 channels may be available.
Return Values
R_CAN_OK Action completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_SW_RST_ERR The CAN peripheral did not enter Reset mode.
R_CAN_MODULE_STOP_ERR Whole CAN peripheral is in stop state (low power). Perhaps the PRCR
register was not used to unlock the module stop register.
See also R_CAN_Control return values.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
This function wakes the peripheral from CAN Sleep mode and puts it in CAN Reset mode. It configures the mailboxes
with these default settings:
•Overwrite an unread mailbox data when new frames arrive
•Sets the device to use ID priority (normal CAN behavior, not the optional mailbox number priority).
•Sets all mailboxes’ masks invalid.
R_CAN_Create calls the R_CAN_SetBitrate function and configures CAN interrupts if USE_CAN_POLL is
commented in config_r_can_rapi.h.
Before returning, it clears all mailboxes, sets the peripheral into Operation mode, and clears any errors.
Example
/* Init CAN. */
api_status = R_CAN_Create(0);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 9 of 29
Mar 23, 2013
R_CAN_PortSet
Configures the MCU and transceiver port pins
This function is responsible for configuring the MCU and transceiver port pins. Transceiver port pins such as Enable
will vary depending on design, and this function must then be modified.
The function is also used to enter the CAN port test modes, such as Listen Only.
Format
uint32_t R_CAN_PortSet( const uint32_t ch_nr,
const uint32_t action_type );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. The number of available channels
depends on part. 1-4 channels may be available.
action_type Port actions:
ENABLE Enable the CAN port pins and the CAN transceiver.
DISABLE Disable the CAN port pins and the CAN transceiver.
CANPORT_TEST_LISTEN_ONLY Set to Listen Only mode. No Acks or Error frames are
sent. See 10.3.
CANPORT_TEST_0_EXT_LOOPBACK Use external bus and loopback. Not tested!
CANPORT_TEST_1_INT_LOOPBACK Only internal mailbox communication.
CANPORT_RETURN_TO_NORMAL Return to normal port usage.
Return Values
R_CAN_OK Action completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_BAD_ACTION_TYPE No such action type exists for this function.
R_CAN_SW_HALT_ERR The CAN peripheral did not enter Halt mode.
R_CAN_SW_RST_ERR The CAN peripheral did not enter Reset mode.
See also R_CAN_Control return values.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
Make sure this function is called before and after any default port set up function is used (e.g. ‘hwsetup’). Otherwise,
an output high/low on an MCU CAN port pin could affect the bus. (You may discover when debugging that a hard reset
on a node could cause other nodes to go into error mode. The reason may be that all ports were set as default output
hi/low before CAN reconfigures the ports. For a brief period of time, the ports will then be output low and disrupt the
CAN bus voltage level.)
You may have to change/add transceiver port pins according to your transceiver.
Example
/* Normal CAN bus usage. */
R_CAN_PortSet(0, ENABLE);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 10 of 29
Mar 23, 2013
R_CAN_Control
Set CAN operating modes
Controls transition to CAN operating modes determined by the CAN Control register. For example, the Halt mode
should be used to later configure a receive mailbox.
Format
uint32_t R_CAN_Control( const uint32_t ch_nr,
const uint32_t action_type );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. The number of available channels
depends on part. 1-4 channels may be available.
action_type Peripheral actions:
EXITSLEEP_CANMODE Exit CAN Sleep mode, the default state when the
peripheral starts up. See 12.
ENTERSLEEP_CANMODE Enter CAN Sleep mode to save power.
RESET_CANMODE Put the CAN peripheral into Reset mode.
HALT_CANMODE Put the CAN peripheral into Halt mode. CAN peripheral
is still connected to the but stops communicating.
OPERATE_CANMODE Put the CAN peripheral into normal Operation mode.
Return Values
R_CAN_OK Action completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_BAD_ACTION_TYPE No such action type exists for this function.
R_CAN_SW_WAKEUP_ERR The CAN peripheral did not wake up from Sleep mode.
R_CAN_SW_SLEEP_ERR The CAN peripheral did not enter Sleep mode.
R_CAN_SW_RST_ERR The CAN peripheral did not enter Halt mode.
R_CAN_SW_HALT_ERR The CAN peripheral did not enter Halt mode.
R_CAN_SW_RST_ERR The CAN peripheral did not enter Reset mode.
See also R_CAN_PortSet return values.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
Other than calling this API to enter Halt mode, CAN mode transitions are called via the other API functions
automatically. For example, the default mode when starting up is CAN Sleep mode. Use the API to switch to
other operating modes, for example first ‘Exit Sleep’ followed by ‘Reset‘ to initialize the CAN registers for
bitrate and interrupts, then enter ‘Halt’ mode to configure mailboxes.
Example
/* Normal CAN bus usage. */
result = R_CAN_Control(0, OPERATE_CANMODE); //Check that result is = R_CAN_OK.

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 11 of 29
Mar 23, 2013
R_CAN_SetBitrate
Sets the CAN bitrate (communication speed)
The baud rate and bit timing must always be set during the configuration process. It can be changed later on if reset
mode is entered.
Format
void R_CAN_SetBitrate(const uint32_t ch_nr);
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
Return Values
-
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
A Time quanta, Tq, is one bit-time of the CAN system clock, fcanclk. This is not the CAN bit-time but the internal
clock period of the CAN peripheral. This CAN system clock in turn is determined by (twice) the Baud Rate
Prescaler value and the peripheral bus clock, fclk, to create the CAN system clock.
Setting the baud rate or data speed on the CAN bus requires some understanding of CAN bit timing and MCU
frequency, as well as reading hardware manual figures and tables. The default bitrate setting of the API is
500kB, and unless the MCU clock or peripheral frequencies are changed, it is sufficient to just call the function.
One bit time is divided into a number of Time Quanta, Tqtot. One Time Quantum is equal to the period of the CAN
clock. Each bitrate register is then given a certain number of Tq of the total of Tq that make up one CAN bit
period.
Formulas to calculate the bitrate register settings.
PCLK is the peripheral clock frequency.
fcan = PCLK
The prescaler scales the CAN peripheral clock down with a factor.
fcanclk = fcan/prescaler
One Time Quantum is one clock period of the CAN clock.
Tq =1/fcanclk
Tqtot is the total number of CAN peripheral clock cycles during one CAN bit time and is by the peripheral built by
the sum of the “time segments” and “SS” which is always 1.
Tqtot = TSEG1 + TSEG2 + SS (TSEG1 must be > TSEG2)
The bitrate is then
Bitrate = fcanclk/Tqtot
SS is always 1. SJW is often given by the bus administrator. Select 1 <= SJW <= 4.
See CONFIG_R_CAN_RAPI.H for more details.
Example
/* Set bitrate as defined in config_r_can_rapi.h. */
R_CAN_SetBitrate(0);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 12 of 29
Mar 23, 2013
R_CAN_TxSet and R_CAN_TxSetXid
Set up a mailbox to transmit
R_CAN_TxSet will write to a mailbox the specified ID, data length and data frame payload, then set the mailbox to
transmit mode and send a frame onto the bus by calling R_CAN_Tx().
R_CAN_TxSetXid does the same, except if this function is used, the ID will be a 29-bit ID.
Format
uint32_t R_CAN_TxSet( const uint32_t ch_nr,
const uint32_t mbox_nr,
const can_frame_t* frame_p,
const uint32_t frame_type );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Mailbox to use.
frame_p* Pointer to a data frame structure in memory. It is an address to the data
structure containing the ID, DLC and data that constitute the dataframe
the mailbox will transmit.
frame_type DATA_FRAME Send a normal data frame.
REMOTE_FRAME Send a remote data frame request.
Return Values
R_CAN_OK The mailbox was set up for transmission.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_BAD_ACTION_TYPE No such action type exists for this function.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
This function first waits for any previous transmission of the specified mailbox to complete. It then interrupt disables
the mailbox temporarily when setting up the mailbox: Sets the ID value for the mailbox, the Data Length Code
indicated by frame_p, selects dataframe or remote frame request and finally copies the data frame payload bytes (0-7)
into the mailbox. The mailbox is interrupt enabled again unless USE_CAN_POLL was defined. Finally R_CAN_Tx is
called to deliver the message.
Example
#define MY_TX_SLOT 7
can_std_frame_t my_tx_dataframe;
my_tx_dataframe.id = 1;
my_tx_dataframe.dlc = 2;
my_tx_dataframe.data[0] = 0xAA;
my_tx_dataframe.data[1] = 0xBB;
/* Send my frame. */
api_status = R_CAN_TxSet(0, MY_TX_SLOT, &my_tx_dataframe, DATA_FRAME);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 13 of 29
Mar 23, 2013
R_CAN_Tx
Starts actual message transmission onto the CAN bus
This API will wait until the mailbox finishes handling a prior frame, then set the mailbox to transmit mode.
Format
uint32_t R_CAN_Tx( const uint32_t ch_nr,
const uint32_t mbox_nr );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to use.
Return Values
R_CAN_OK The mailbox was set to transmit a previously configured mailbox.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_SW_SET_TX_TMO Waiting for previous transmission to finish timed out.
R_CAN_SW_SET_RX_TMO Waiting for previous reception to complete timed out.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
R_CAN_TxSet must have been called at least once for this mailbox after system start to set up the mailbox content, as
this function only tells the mailbox to send its content.
Example
#define MY_TX_SLOT 7
/* Send mailbox content. This mailbox is presumed to have been set up to send some time
in the past. */
R_CAN_Tx(0, MY_TX_SLOT);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 14 of 29
Mar 23, 2013
R_CAN_TxCheck
Check for successful data frame transmission.
Use to check a mailbox for a successful data frame transmission.
Format
uint32_t R_CAN_TxCheck( const uint32_t ch_nr,
const uint32_t mbox_nr );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to use.
Return Values
R_CAN_OK Transmission was completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_MSGLOST Message was overwritten or lost.
R_CAN_NO_SENTDATA No message was sent.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
This function is only needed if an application needs to verify that a message has been transmitted for example so that it
can progress a state machine, or if messages are sent back-to-back. With CAN’s level of transport control built into the
silicon, it can reasonably be assumed that once a mailbox has been asked to send with the API that the message will
indeed be sent. Safest if of course to use this function after a transmission.
Example
/*** TRANSMITTED a particular frame? */
api_status = R_CAN_TxCheck(0, CANBOX_TX);
if (api_status == R_CAN_OK)
{
/* Notify main application. */
message_x_sent_flag = TRUE;
}

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 15 of 29
Mar 23, 2013
R_CAN_TxStopMsg
Stop a mailbox that has been asked to transmit a frame
Format
uint32_t R_CAN_TxStopMsg( const uint32_t ch_nr,
const uint32_t mbox_nr );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to use.
Return Values
R_CAN_OK Action completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_SW_ABORT_ERR Waiting for an abort timed out.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
This function clears the mailbox control flags so that a transmission is stopped (TrmReq is set to 0.) A software counter
then waits for an abort a maximum period of time.
If the message was not stopped, R_CAN_SW_ABORT_ERR is returned. Note that the cause of this could be that the
message was already sent.
Example
R_CAN_TxStopMsg(0, MY_TX_SLOT);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 16 of 29
Mar 23, 2013
R_CAN_RxSet and R_CAN_RxSetXid
Set up a mailbox to receive
R_CAN_RxSet The API sets up a given mailbox to receive data frames with the given CAN ID. Incoming data frames
with the same ID will be stored in the mailbox.
R_CAN_RxSetXid does the same thing, except if this function is used, the ID will be a 29-bit ID.
Format
uint32_t R_CAN_RxSet( const uint32_t ch_nr,
const uint32_t mbox_nr,
const uint32_t id,
const uint32_t frame_type );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to use.
sid 0-7FFhThe standard CAN ID which the mailbox should receive.
frame_type DATA_FRAME Send a normal data frame.
REMOTE_FRAME Send a remote data frame request.
Return Values
R_CAN_OK Action completed successfully.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_SW_SET_TX_TMO Waiting for previous transmission to finish timed out.
R_CAN_SW_SET_RX_TMO Waiting for previous reception to complete timed out.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
The function will first wait for any previous transmission/reception to complete, then temporarily interrupt disable
the mailbox. It sets the mailbox to the given standard ID value, and whether to receive normal CAN dataframes or
remote frame requests.
Example
#define MY_RX_SLOT 8
#define SID_FAN_SPEED 0x10
R_CAN_RxSet(0, MY_RX_SLOT, SID_FAN_SPEED, DATA_FRAME);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 17 of 29
Mar 23, 2013
R_CAN_RxPoll
Checks if a mailbox has received a message
Format
uint32_t R_CAN_RxPoll( const uint32_t ch_nr,
const uint32_t mbox_nr );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to check.
Return Values
R_CAN_OK There is a message waiting.
R_CAN_NOT_OK No message waiting or pending.
R_CAN_RXPOLL_TMO Message pending but timed out.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
When a mailbox is set up to receive certain messages, it is important to determine when it has finished receiving
successfully. There are two methods for doing this:
1. Polling. Call the API regularly to check for new messages. USE_CAN_POLL must be defined in the CAN
configuration file. If there is a message use R_CAN_RxRead to fetch it.
2. Using the CAN receive interrupt (USE_CAN_POLL not defined): Use this API to check which mailbox
received. Then notify the application.
The function returns R_CAN_OK if new data was found in the mailbox.
Example
See example in R_CAN_RxRead.

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 18 of 29
Mar 23, 2013
R_CAN_RxRead
Read the CAN data frame content from a mailbox
The API checks if a given mailbox has received a message. If so, a copy of the mailbox’s dataframe will be written to
the given structure.
Format
uint32_t R_CAN_RxRead( const uint32_t ch_nr,
const uint32_t mbox_nr,
can_std_frame_t * const frame_p );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to check.
frame_p *Refers to a pointer to a data frame structure in memory.
It is an address to the data structure into which the function will place a
copy of the mailbox’s received CAN dataframe.
Return Values
R_CAN_OK There is a message waiting.
R_CAN_SW_BAD_MBX Bad mailbox number.
R_CAN_BAD_CH_NR The channel number does not exist.
R_CAN_MSGLOST Message was overwritten or lost.
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
Use R_CAN_PollRxCAN() first to check whether the mailbox has received a message.
This function is used to fetch the message from a mailbox, either when using polled mode or from a CAN receive
interrupt.
Example
#define MY_RX_SLOT 8
can_std_frame_t my_rx_dataframe;
api_status = R_CAN_RxPoll(0, CANBOX_RX_DIAG);
if (api_status == R_CAN_OK)
R_CAN_RxRead(0, CANBOX_RX_DIAG, &my_rx_dataframe);

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 19 of 29
Mar 23, 2013
R_CAN_RxSetMask
Sets the CAN ID Acceptance Masks
To accept only one ID, set mask to all ones. To accept all messages, set mask to all zeros. To accept a range of
messages, set the corresponding ID bits to zero.
Format
void R_CAN_RxSetMask( const uint32_t ch_nr,
const uint32_t mbox_nr,
const uint32_t sid_mask_value );
Arguments
ch_nr 0,1,2,3 Which CAN bus to use. 1-4 channels may be available.
mbox_nr 0-32 Which CAN mailbox to check.
sid_mask_value 0-7FFhMask value.
Return Values
-
Properties
Prototyped in r_can_api.h
Implemented in r_can_api.c
Comments
Receive mailboxes can use a mask to filter out one or a range of message CAN IDs. The mask enables mailboxes to
accept a broader range of messages than just the single message ID that is set in the mailbox’s ID field.
There is one mask for mailbox 0-3, one for 4-7, … Remember therefore that changing a mask can very well affect
the behavior of adjacent mailboxes.
- Each '0' in the mask means "mask this bit", or “don't look at that bit”; accept anything.
- Each '1' means check if the CAN-ID bit in this position matches the CAN-ID of the mailbox.
How to set a mask
Lets say the CAN-IDs you want to receive in a mailbox is 700-704husing standard 11-bit ID:
Hex representation Bit representation
0x700 011100000000b
0x701 011100000001b
0x702 011100000010b
0x703 011100000011b
0x704 011100000100b
The mailbox will only accept frames with an ID that matches the positions whose mask value is 1. If we want to
accept all of above, we set the mask as
011111111000b, or 07F8h.
The CAN receive filter will only look at bit positions b11 (MSB), to b3 (LSB) and whether these match the receive
ID of the mailbox.
If we then set a mailbox to receive ID 0x700 (0x700-0x707 will give the same result) it will accept IDs 0x700 to
0x707. 0x705 to 0x707 must later be ignored ‘manually’ by the application software.

RX600 Series CAN Application Programming Interface
R01AN0339EU0203 Rev. 2.03 Page 20 of 29
Mar 23, 2013
Fast filtering of messages with Acceptance Filter Support
If you have used a mask to receive a broad range of message IDs, you must filter for the actual desired messages
with firmware. To increase the speed of this search one may use the Acceptance Filter Support instead.
The Acceptance Filter Support Unit (ASU) provides a faster search compared to software filtering of messages
using a mask (with the R_CAN_RxSetMask API). Software filtering can be time consuming as the Standard
ID bits are rearranged and not stored as a normal word in memory. Another problem could be that the
acceptance mask may not be able to be set to receive the particular combination of messages you want. If you
set the mask to accept all messages you may have to ‘waste’ time by checking a long list of the messages using
software for each incoming ID. This manual filtering’ would also involve having all the IDs in a readable
format. An efficient solution in such cases is to use the Acceptance Filter Support Unit.
To use it, one writes the CAN-ID as it is stored in the message box into the ASU. When read back from the ASU
register it reads:
Bit 0-7 = Table Address Search Info, ‘ASI’
Bit 8-15 = Bit Search Information, ‘BSI’. SID0-3 has now been converted to a bit position to enable faster
table searches. Use the output to search through a table.
Figure 3. The Acceptance Filter Support Unit (ASU). When read, the representation of the ID
is formatted to enable a fast search through a table. This provides a faster response than a
search through a ‘normal’ array of CAN IDs.
The search table. A table must be prepared by the user to check whether an ID is of interest to the application. The
firmware must search the table at each byte address ASI and bit position BSI. If a bit BSI-value is set in the
user’s table, the bit pattern matches the BSI pattern of the register which means the address is of interest to the
node, and the frame should be processed by the application.
See REJ05B0276 “CAN Application Note” for more information on how to use the ASU. (Download from
www.renesas.com,