TechnicalReference_Rh850_Rscans

Vector CAN Driver
Technical Reference

Renesas
RH850
RSCAN

Version 1.08.00

Authors
Torsten Kercher
Status
Released

Vector CAN Driver Technical Reference RH850 RSCAN

Document Information
History

Author
Date
Version  Remarks
Torsten Kercher  2013-05-27  1.00.00  Initial release (support F1L with GreenHills compiler)
Torsten Kercher  2013-07-18  1.01.00  Support R1L derivatives
Correct description of nested interrupt behavior
Torsten Kercher  2013-08-26  1.02.00  Support HighEnd features
Support WindRiver Diab compiler
Torsten Kercher  2013-10-16  1.03.00  Support R1M derivatives
Update referenced version of the R1x manual
Support external wakeup functionality
Update chapters 5, 6, 7.2.2
Torsten Kercher  2014-04-04  1.04.00  Support extended CAN RAM check
Support RSCAN RAM test
Support D1L, D1M, P1M derivatives
Update referenced version of the F1L manual
Torsten Kercher  2014-04-29  1.04.01  Update description of nested interrupt behavior
Torsten Kercher  2014-05-15  1.05.00  Support IAR compiler
Support F1H derivatives
Update expected loop durations in chapter 5
Torsten Kercher  2014-07-23  1.06.00  Support Renesas compiler
Support C1H, C1M, E1L, E1M derivatives
Update chapters 5, 9.4, 10.3
Update ref. versions of the F1L and F1H manuals
Torsten Kercher  2014-11-24  1.07.00  Support configuration of the used ‘CAN Interface’
Support F1M derivatives
Update chapters 5, 6, 7.2.9, 9.4, 10.3
Update ref. versions of the P1x and R1x manuals
Torsten Kercher  2015-08-19  1.08.00  Support F1K derivatives
Table 1-1   History of the document

Please note
We  have  configured  the  programs  in  accordance  with  your  specifications  in  the
  questionnaire.  Whereas  the  programs  do  support  other  configurations  than  the  one
specified  in  your  questionnaire,  Vector’s  release  of  the  programs  delivered  to  your
company  is  expressly  restricted  to  the  configuration  you  have  specified  in  the
questionnaire.

2015, Vector Informatik GmbH
Version: 1.08.00
2 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

1  Introduction
The concept of the CAN driver and the standardized interface between the CAN driver and
the  application  is  described  in  the  document  TechnicalReference_CANDriver.pdf.  The
CAN driver interface to the hardware is designed in a way that capabilities of the special
CAN chips can be utilized optimally. The interface to the application was made identical for
the  different  CAN  chips,  so  that  the  "higher"  layers  such  as  network  management,
transport protocols and especially the application would essentially be independent of the
particular CAN chip used.

This  document  describes  the  hardware  dependent  special  features  and  implementation
specifics of the Renesas RSCAN on the RH850 platform.
2015, Vector Informatik GmbH
Version: 1.08.00
5 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

2  Important References
The  following  table  summarizes  information  about  the  CAN  Driver.  It  gives  you  detailed
information  about  the  versions,  derivatives  and  compilers. As  very  important  information
the  documentations  of  the  hardware  manufacturers  are  listed. The  CAN  Driver  is  based
upon these documents in the given version.

Driver
Supported
Supported
Hardware Manufacturer Documents
Version
Version

  Compilers
Derivatives
3.15.xx,  GreenHills,
C1H
R01UH0414EJ0041, RH850/C1x,
Rev.0.41
RI 1.5
WindRiver Diab,  C1M
User’s Manual: Hardware
Feb 2014
Renesas,
D1L
R01UH0451EJ0041, RH850/D1L/D1M
Rev.0.41
IAR
D1M
Group, User’s Manual: Hardware
Jan 2014
E1L
R01UH0468JJ0040, RH850/E1L,
Rev.0.40
User’s Manual: Hardware
Dec 2013
E1M
R01UH0466JJ0040, RH850/E1M-S,
Rev.0.40
User’s Manual: Hardware
Dec 2013
F1H 1
R01UH0445EJ0011, RH850/F1H Group,  Rev.0.11
User’s Manual: Hardware
Apr 2014
F1K 1
R01UH0562EJ0050, RH850/F1K Group   Rev.0.50
User’s Manual: Hardware
Mar 2015
F1L
R01UH0390EJ0110, RH850/F1L Group,   Rev.1.10
User’s Manual: Hardware
Jun 2014
F1M
R01UH0518EJ0010, RH850/F1M Group,   Rev.0.10
User’s Manual: Hardware
Nov 2014
P1M
R01UH0436EJ0060, RH850/P1x Group,   Rev.0.60
User’s Manual: Hardware
Jul 2014
R1L
R01UH0411EJ0110, RH850/R1x Group,   Rev.1.10
R1M
User’s Manual: Hardware
Aug 2014

R01US0058EJ0020, RH850 Family,
Rev.0.20
User’s Manual: Software
Feb 2013
Table 2-1   Supported Hardware Overview

Driver Version: This is the current version of the CAN Driver. RI shows the version of the Reference
Implementation and therefore the functional scope of the CAN Driver.
Supported Compilers: List of compilers the CAN Driver is working with.
Supported Derivatives: List of derivatives the CAN Driver can be used on.
Hardware Manufacturer Documents: List of the documentation the CAN Driver is based on.
Version: Version of the documentation the CAN Driver is based on.


1 Only the first RSCAN unit (RSCAN0) is supported (physical channels CAN0-CAN5).
2015, Vector Informatik GmbH
Version: 1.08.00
6 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

3  Usage of Controller Features
3.1
[#hw_comObj] - Communication Objects
The generation tool supports a flexible allocation of message buffers:

Figure 3-1  Hardware Object Layout

Note
Figure  3-1  depicts  the  maximum  capacities  of  one  RSCAN  unit  -  the  actual  layout
  depends  on  the  used  derivative.  Refer  to  the  hardware  manual  to  get  the  number  of
supported physical channels to determine which Tx buffers are available. The amount
of  supported  Rx  buffers  (nRXMBmax)  equals  the  number  of  supported  physical
channels of the used RSCAN unit * 16.

2015, Vector Informatik GmbH
Version: 1.08.00
7 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Obj
Hw object  Log object  No. of
Comment
number
type
type
objects
These objects are used to receive
specific CAN messages. The user
defines statically (Generation Tool) that
a CAN message should be received in a
FullCAN message object. The

Generation Tool distributes the
0
messages to the FullCAN objects. Up to
0

Receive
Receive
-
nRxMBmax receive FullCAN objects can
-
buffer
FullCAN
nRXMBmax be configured per channel, but the sum
(nRXFC

-1)

over all receive FullCAN objects on all
= nRXFC
channels must not exceed nRxMBmax.
The receive buffers for the FullCAN
objects of all channels (sorted
ascending by the physical channel
index) are allocated continuously
starting from index 0.
These objects are not used. It depends
on the configuration of receive FullCAN
nRXFC
0
Receive

objects and nRxMBmax how many
-
Unused
buffer

-
receive buffers are not used. These
127

128
objects will not be configured, so they
don’t consume shared hardware buffers.
All other CAN messages (Application,
Diagnostics, Network Management) are
received via the BasicCAN objects.
Each object consists of one receive
FIFO buffer with a configurable amount
of acceptance filters and an individually
configurable FIFO depth (number of
allocated shared buffers). In general
0
there is one BasicCAN object per
128

-
channel, but by using the Multiple
-
Receive
Receive
8
BasicCAN feature the amount of used
(128 +

FIFO buffer  BasicCAN
BasicCAN objects can be configured.
nRXBC

-1)
= nRXBC
Up to 8 receive BasicCAN objects can
be configured per channel, but the sum
over all receive BasicCAN objects on all
channels must not exceed 8. The
receive FIFO buffers for the BasicCAN
objects of all channels (sorted
ascending by the physical channel
index) are allocated continuously
starting from index 128.
These objects are not used. It depends
on the configuration of receive
128 + nRXBC
0
Receive

BasicCAN objects how many receive
-
Unused
FIFO buffer

-
FIFO buffers are not used. These
135

8
objects will not be configured, so they
don’t consume shared hardware buffers.
2015, Vector Informatik GmbH
Version: 1.08.00
8 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Obj
Hw object  Log object  No. of
Comment
number
type
type
objects
The usage of Transmit / Receive FIFO
136
Transmit /
buffers is not supported by this driver.
-
Receive
Unused
24
These objects are always unused and
159
FIFO buffer
will not be configured, so they don’t
consume shared hardware buffers.
This object is used by CanTransmit()
to send several messages on the logical
Transmit
Transmit
1
160 + (n*16)

channel that is mapped to physical

buffer
Normal
per channel  channel n. If the transmit message
object is busy, the transmit request is
stored in a software queue.
This object is used by
0 or 1
Transmit
CanMsgTransmit() to send its
Low Level  per channel
161 + (n*16)

buffer
messages on the logical channel that is

Transmit

= nTXLL
mapped to physical channel n if the Low

Level transmit functionality is used.
These objects are used by
CanTransmit() to send a certain
message on the logical channel that is

161 + (n*16)
0
mapped to physical channel n. The user

+ nTXLL
defines statically (Generation Tool)
-
-
Transmit
Transmit
15
which CAN messages are located in

161 + (n*16) +  buffer
FullCAN
such Tx FullCAN objects. The
nTXLL +
per channel  Generation Tool distributes the
nTXFC(n)

-1
messages to the objects. Up to 15
= nTXFC(n)   transmit FullCAN objects can be
assigned per channel (up to 14 if the
Low Level transmit functionality is used).
161 + (n*16) +
These objects are not used. It depends
nTXLL +
0
on the configuration of transmit objects
nTXFC(n)
Transmit
how many transmit buffer objects are
Unused
-

-
buffer
15
not used. Additionally all transmit buffers
161 + (n*16)
per channel  of not supported or unused physical
+14
channels n are unused.
Table 3-1   Hardware Object Layout

nRxMBmax  Amount of RX buffers that is supported by the used derivative (see note above)
nRxFC
Number of used Rx FullCAN objects over all channels
nRxBC
Number of used Rx BasicCAN objects over all channels
n
Index of the physical channel
nTXLL
Number of Low Level transmit objects per channel (0 or 1)
nTXFC(n)
Number of used Tx FullCAN objects on the channel that is mapped to the physical channel n

2015, Vector Informatik GmbH
Version: 1.08.00
9 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Caution
The number of available transmit buffer objects per physical channel is constant. The
  receive buffers and FIFOs are shared over all channels and the availability per channel
is  restricted  as  explained  in  table  3-1.  Furthermore  the  internal  buffers  for  all  receive
objects  are  allocated  out  of  a common  buffer  pool  with  size  of  (number  of  supported
physical  channels  of  the  used  RSCAN  unit  *  64).  This  has  to  be  considered  when
configuring the number of the Rx FullCAN objects and the number and individual FIFO
depths of the Rx BasicCAN objects (refer to section 11.1.3 for further information and
details on how to configure the hardware objects).

3.2
Acceptance Filters
The hardware acceptance filters of the receive BasicCAN objects must allow reception of
all  messages  that  are  not  received  in  FullCAN  message  objects  and  additionally  all
messages  that  fit  in  a  configured  range  (e.g.  for  Network  Management,  Transport
Protocol).  The  generation  tool  offers  assistance  for  configuration.  The  number  of  used
filters  is  also  configurable  to  allow  efficient  hardware  filtering  to  minimize  unnecessary
CPU load.

Caution
The hardware supports a pool of acceptance filters with size of (number of supported
  physical channels of the used RSCAN unit * 64) that are used for Rx BasicCAN as well
as Rx FullCAN objects. This has to be considered when configuring the number of Rx
FullCAN objects and the number of filters per Rx BasicCAN object. See section 11.1.3
for further information and details on the configuration.

2015, Vector Informatik GmbH
Version: 1.08.00
10 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

4   [#hw_sleep] - SleepMode and WakeUp
The  driver  supports  sleep  and  wakeup  functionality.  With  the  function  CanSleep()  the
CAN controller enters sleep mode and leaves it with the function CanWakeUp() (internal
wakeup)  or  upon  a  falling  edge  respectively  dominant  level  on  the  Rx  pin  (external
wakeup).
Specify the Sleep/Wakeup option in the generation tool in order to use the Sleep/Wakeup
functionality.  If  this  option  is  not  enabled,  the  service  functions  CanSleep()  and
CanWakeUp() are empty and return kCanNotSupported.
4.1
Sleep
The  function  CanSleep()  changes  the  channel  from  communication  mode  via  reset
mode to stop mode. If the function is called during CAN communication, the reception or
transmission  is  terminated  before  it  is  completed  (the  same  applies  to  a  call  of
CanResetBusSleep()).
The return value kCanOk is always expected as these mode transitions do not depend on
external influences (e.g. the CAN bus level). However, if the function returns kCanFailed
(e.g. caused by a hardware loop cancellation, see chapter 5 for details) call CanSleep()
again or re-initialize the channel.
4.2
Internal Wakeup
The  function  CanWakeUp()  changes  the  channel  from  stop  mode  via  reset  mode  to
communication mode.
The return value kCanOk is always expected as these mode transitions do not depend on
external influences (e.g. the CAN bus level). However, if the function returns kCanFailed
(e.g. caused by a hardware loop cancellation, see chapter 5 for details) call CanWakeup()
again or re-initialize the channel.
4.3
External Wakeup
The external wakeup functionality is realized by external interrupts but fully handled by the
CAN driver in default configurations. The RSCAN itself does not provide any possibility of
detecting bus activity if  it is in  stop mode. Instead  the port configuration of  many  RH850
derivatives allows combining the CANn Rx pin with an external interrupt INTPm to be able
to  detect  a  CAN  event  even  if  the  driver  is  in  sleep  mode.  See  the  hardware
documentation of the actual derivative for details (Port x – Alternative Functions) and refer
to chapter 10 for implementation hints.
When the driver is in  sleep mode and a  CAN event is detected on the Rx pin a wakeup
interrupt is generated. It is also possible to detect this event by polling the interrupt request
flag without enabling the interrupt source. The ISR or the task function calls the application
function  ApplCanPreWakeUp()  (if  configured),  changes  the  channel  mode  via  reset
mode to communication mode and then calls ApplCanWakeUp().
2015, Vector Informatik GmbH
Version: 1.08.00
11 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Caution
If the Sleep/Wakeup functionality is enabled via the configuration tool both the internal
  and external wakeup are available  by default  and the CAN driver expects that the Rx
pin  of  each  used  CAN  channel  is  linked  with  an  external  interrupt  in  context  of  the
RH850  port  configuration  as  depicted  in  the  corresponding  hardware  manual.
Additionally  the  driver  expects  that  each  external  interrupt  source  is  assigned  to  the
lowest  possible  interrupt  channel  if  the  sources  are  multiplexed  (check  the  “INTC1
interrupt select register” if applicable).
If  this  configuration  is  not  possible  for  the  actual  derivative  (refer  to  the  hardware
documentation) or any respective external interrupt cannot be used exclusively by the
driver (write accesses to the corresponding interrupt control register, e.g. if any external
MCU  wakeup  handling  using  this  source  is  implemented),  the  external  wakeup
functionality must not be used.
In this case the Sleep/Wakeup functionality has to be disabled via the generation tool
or the external wakeup handling has to be deactivated by adding following to the user
configuration file:
#define C_ENABLE_EXTERNAL_WAKEUP_SUPPRESSION
Then  the  driver  does  not  access  the  external  interrupt  sources  and  only  the  internal
wakeup is possible (the driver does not wake up on bus activity).

Caution
The driver performs write accesses within the interrupt controller address space of the
  MCU if the external wakeup functionality is used. If wakeup processing is configured to
interrupt  the  corresponding  source  is  enabled  at  successful  sleep  transitions  and
disabled  during  wakeup  transitions.  Additionally  the  corresponding  interrupt  request
flag is cleared right before the interrupt is enabled; hence a wakeup event can only be
detected  after  the  sleep  transition  has  been  successfully  completed.  Refer  to  section
10.3 if an exclusive write access to the interrupt control registers is not possible. Please
note that the interrupt request flag also has to be cleared for polling configurations.

2015, Vector Informatik GmbH
Version: 1.08.00
12 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

5   [#hw_loop] - Hardware Loop Check
In  context  of  the  feature  Hardware  Loop  Check  (see  TechnicalReference_CANDriver,
chapter Hardware Loop Check) this CAN Driver provides the following timer identifications.
Refer to the hardware manual for a description of the RSCAN clock sources and additional
information  on  other  hardware  specifics  like  the  mode  transitions.  Please  note  that  the
expected loop durations  vary between individual derivatives. The given values depict the
worst case and may be lower for the actually used derivative.

Caution
Always significantly increase the given durations for the loop callout implementation to
  compensate additional software delays.

kCanLoopRamInit
This loop may be called within the function CanInitPowerOn() and is processed until
the  CAN  RAM  initialization  after  a  MCU  reset  has  finished.  This  is  necessary  as  this
initialization has to be completed before the  RSCAN  can be configured. As this loop is
not called in channel context the channel parameter has to be ignored.
The maximum  expected  duration  to  wait for  the  CAN  RAM  initialization  starts  from  the
time  of  the  MCU  reset  and  is  device  specific.  Refer  to  the  corresponding  hardware
manual (e.g.  section RSCAN Setting Procedure  –  Initial Settings) to get  the number of
required cycles of the pclk. If this loop is canceled try to call CanInitPowerOn() again
or reset the MCU.

kCanLoopInit
This  loop may  be  called  within  the function  CanInitPowerOn(). As  it  is  not  called  in
channel  context  the  channel  parameter  has  to  be  ignored.  The  loop  may  be  called
multiple times within this function and the possible occurrences are as follows:
  To protect the transition via global reset mode to global stop mode.
  To protect the transition to global reset mode.
  To protect transitions and settings in context of the global test mode (only active if the
RSCAN RAM test is enabled)
  To protect the transition to channel reset mode for each active channel.
  To protect the transition to global operation mode.

The duration for each mode transition in this context is expected to be two CAN bit times
at  highest  (of  the  lowest  communication  speed  of  the  channels  in  use).  If  any  loop
occurrence is canceled try to call CanInitPowerOn() again or reset the MCU.

2015, Vector Informatik GmbH
Version: 1.08.00
13 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

kCanLoopBusOffRecovery
This channel dependent loop may be called in CanInit() if the RSCAN is currently in
BusOff  state  and  is  processed  until  11  consecutive  recessive  bits  have  been  detected
128 times on the bus to ensure compliance to the BusOff recovery specification (see also
chapter 6).
The  maximum  expected  duration  is  1408  CAN  bit  times  on  a  recessive  bus,  128
message  times  including  inter-frame  space  on  a  communicative  bus  or  any  time  if
disturbances are present. There is no issue and nothing to do if the loop is canceled, but
the specified BusOff recovery time may not be met.

kCanLoopEnterResetMode
This  channel  dependent  loop  may  be  called  multiple  times  in  CanInit()  and  is
processed  as  long  as  the  CAN  cell  does  not  enter  channel  reset  mode,  respectively
channel operation mode.
The  maximum  expected  duration  of  each  loop  is  three  CAN  bit  times.  If  the  loop  is
canceled try to call CanInit() again. If the loop still doesn’t finish within the expected
time call CanInitPowerOn().

kCanLoopEnterOperationMode
This channel dependent loop is called in CanStart() and is processed as long as the
CAN cell does not enter channel operation mode.
The  maximum  expected  duration  of  the  loop  is  three  CAN  bit  times.  If  the  loop  is
canceled  try  to  call  CanStart()  again  or  invoke  CanInit().  If  the  loop  still  doesn’t
finish within the expected time call CanInitPowerOn().

kCanLoopEnterSleepMode
This  channel  dependent  loop  may  be  called  multiple  times  in  CanSleep()  and  is
processed  as  long  as  the  CAN  cell  does  not  enter  channel  reset  mode,  respectively
channel stop mode.
The maximum expected duration of the loop is two CAN bit times. If the loop is canceled
try to call CanSleep() again or invoke CanInit(). If the loop still doesn’t finish within
the expected time call CanInitPowerOn().

kCanLoopEnterWakeupMode
This  channel  dependent  loop  may  be  called  multiple  times  in  CanWakeUp()  and  is
processed  as  long  as  the  CAN  cell  does  not  enter  channel  reset  mode,  respectively
channel operation mode.
The  maximum  expected  duration  of  the  loop  is  three  CAN  bit  times.  If  the  loop  is
canceled try to call CanWakeUp() again or invoke CanInit(). If the loop still doesn’t
finish within the expected time call CanInitPowerOn().

2015, Vector Informatik GmbH
Version: 1.08.00
14 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

kCanLoopRxFcProcess
This  channel  depended  loop  may  be  called  in  CanFullCanMsgReceived()  and  is
processed  as  long  as  new  messages  are  received  by  the  current  receive  buffer  while
copying a previously received message to a temporary software buffer. This ensures that
always consistent and most recent data is indicated to the higher layers.
It is expected that the loop is called only one time. Please note that if the loop iterates at
all,  previously  received  messages  of  the  current  receive  buffer  are  discarded  without
further notification as data consistency cannot be ensured. There is no issue and nothing
to do if the loop is canceled, but the latest message is also discarded and the function
CanFullCanMsgReceived() returns without indicating any message at all.

2015, Vector Informatik GmbH
Version: 1.08.00
15 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

6  [#hw_busoff] - Bus off
In  case  of  a  BusOff  event  the  controller  automatically  changes  to  stop  mode  on  the
respective  channel.  There  is  no  automatic  recovery  as  specified  by  ISO11898-1;  the
application  has  to  restart  communication  following  the  description  in  the  Technical
Reference CAN driver, i.e. by calling CanResetBusOffStart/-End() which leads to a
call of CanInit().

Caution
Please note that if CanResetBusOffEnd() is called before 11 consecutive recessive
  bits have been detected 128 times on the bus, the function CanInit() waits until this
condition  is  met.  Reason  is  that  the  current  recovery  status  is  lost  during  re-
initialization.  It  may  not  be  acceptable  for  the  program  to  wait  until  the  hardware  has
recovered  as  this  delay  is  implemented  synchronously.  In  this  case  use  the  feature
“Hardware  Loop  Check”  to  control  the  behavior.  See  kCanLoopBusOffRecovery  in
chapter 5 for details.

2015, Vector Informatik GmbH
Version: 1.08.00
16 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

7  CAN Driver Features
7.1
[#hw_feature] - Feature List

Standard
HighEnd
Initialization
Power-On Initialization


Re-Initialization


Transmission
Transmit Request


Transmit Request Queue


Internal data copy mechanism


Pretransmit functions


Common confirmation function


Confirmation flag


Confirmation function


Offline Mode


Partial Offline Mode


Passive-Mode


Tx Observe mode


Dynamic TxObjects
ID



DLC



Data-Ptr


Full CAN Tx Objects


Cancellation in Hardware


Low Level Message Transmit
-

Reception
Receive function


Search algorithms
Linear



Table
-
-

Index



Hash


Range specific precopy functions
4
4
(min. 2, typ.4)
DLC check


Internal data copy mechanism


Generic precopy function


Precopy function


Indication flag


Indication function


Message not matched function


2015, Vector Informatik GmbH
Version: 1.08.00
17 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Overrun Notification


Full CAN overrun notification
-
-
Multiple Basic CAN
-

Rx Queue 2
-

Bus off
Notification function


Nested Recovery functions


Sleep Mode
Mode Change


Preparation


Notification function


Special Features
Status


Security Level


Assertions


Hardware loop check


Stop Mode


Support of OSEK operating


system
Polling Mode
Tx



Rx (FullCAN) 3



Rx (BasicCAN)



Error



Wakeup


Individual Polling 4
-

Multi channel


Support extended ID addressing


mode
Support mixed ID addressing


mode
Support access to error counters


Copy functions


CAN RAM check 5


Extended CAN RAM check 6


Table 7-1   CAN Driver Functionality


2 Consider that the Rx BasicCAN hardware FIFOs in combination with Rx BasicCAN polling might be a more
efficient alternative to the Rx Queue in many configurations.
3 Due to hardware limitations (no interrupt request can be generated for receive buffers) Rx FullCAN polling
is mandatory if Rx FullCAN objects are configured.
4 Due to hardware limitations (see note 3) all Rx FullCAN objects have to be polled.
5 Due to hardware limitations (no write access to Rx objects) only supported for Tx objects.
6 This feature is project specific and only available if explicitly ordered.
2015, Vector Informatik GmbH
Version: 1.08.00
18 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

7.2
Description of Hardware-related Features
7.2.1
[#hw_status] - Status
If a status is not supported, the related macro always returns false.
Status
Support
CanHwIsOk(state)

CanHwIsWarning(state)

CanHwIsPassive(state)

CanHwIsBusOff(state)

CanHwIsWakeup(state)

CanHwIsSleep(state)

CanHwIsStart(state)

CanHwIsStop(state)

CanIsOnline(state)

CanIsOffline(state)

Table 7-2   CAN Status
7.2.2
[#hw_stop] - Stop Mode
The service function CanStop() calls CanInit() and leaves the channel in reset mode,
where it is disconnected from the bus. If the function is called during CAN communication,
the reception or transmission is terminated before it is completed. This mode can be left by
calling CanStart(). Both transitions do not depend on external influences (e.g. the CAN
bus level), so the return value kCanOk is always expected. However, if the functions return
kCanFailed (e.g. caused by a hardware loop cancellation, see chapter 5 for details) call
CanStop() respectively CanStart() again or re-initialize the channel.

7.2.3
[#hw_int] - Control of CAN Interrupts
CAN interrupt locking is performed by modifying the interrupt request mask bits (MK) in the
control registers of the appropriate sources directly within the interrupt controller address
space of the MCU. Therefore the driver needs exclusive write access to all CAN related EI
level  interrupt  control  registers  (ICn).  If  the  Sleep/Wakeup  functionality  is  enabled  this
includes the ICn of external interrupt sources (see chapter 4).
Since  Rx  FIFO  interrupt  and  overrun  (global  error)  cannot  be  enabled  and  disabled  for
every  object  individually  they  are  disabled  globally  when  the  interrupts  of  at  least  one
controller are disabled and enabled globally if  the interrupts of no controller are disabled
anymore.
All CAN related ICn are initialized and then modified by the driver during runtime (interrupt
disable  and  restore).  The  priority  level  for  the  initialization  can  be  selected  via  the
configuration  tool  (all  CAN  interrupts  must  have  the  same  priority),  see  section  11.1.3.
Refer to chapter 10 for further information on CAN interrupts.
2015, Vector Informatik GmbH
Version: 1.08.00
19 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Caution
In standard configuration the driver needs exclusive write access to all CAN related EI
  level  interrupt  control  registers.  Refer  to  chapter  10  for  further  information  and
especially section 10.3 if an exclusive write access is not possible.

7.2.4
[#hw_cancel] - Cancel in Hardware

Yes  No
Has the CanTxTask() to be called by the application to handle the canceled
transmit request in the hardware?



Cancelling transmission of messages via CanCancelTransmit() or
CanCancelMsgTransmit():

Yes  No
ApplCanTxConfirmation() is only called for transmitted messages, successfully
canceled messages are not notified. That means the CAN driver is able to detect


whether a message is transmitted even if the application has tried to cancel.

7.2.5
Remote Frames
Remote Frames will not have any influence on  the communication because they  are not
received due to hardware filtering.

7.2.6
CAN RAM Check
The  CAN  driver  supports  a  check  of  the  CAN  mailboxes  which  is  performed  internally
every  time  the  function  CanInit()  is  called.  The  CAN  driver  verifies  that  no  used
mailboxes are corrupt. A mailbox is considered corrupt if predefined patterns are written to
the appropriate mailbox registers and read operations do not return the expected patterns.
If  a  corrupt  mailbox  is  found  the  function  ApplCanCorruptMailbox()  is  optionally
called to inform the application which mailbox is affected.
After  the  check  of  all  mailboxes  on  the  given  channel  the  CAN  driver  calls  the  function
ApplCanMemCheckFailed() if at least one corrupt mailbox was found. The application
can control whether the CAN driver disables communication on the current channel or not
by  means  of  the  return  value  of  the  call-back  function.  If  the  application  has  decided  to
disable the communication there is no possibility to enable the communication again until
the next call of CanInitPowerOn().

Caution
Due to hardware limitations (no write access for receive objects) the CAN RAM check
  is only supported for transmit mailboxes. Consider the behavioural differences of CAN
RAM check when it is used in combination with the extended CAN RAM check feature.

2015, Vector Informatik GmbH
Version: 1.08.00
20 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

The additional call-back function ApplCanCorruptMailbox() can only be activated via
the user configuration file - the settings are listed below. In case no user config file is used
(i.e. the mentioned switch is not defined) the feature is disabled.
Switch
Value
Description
C_ENABLE_NOTIFY_CORRUPT_MAILBOX

Activate call of ApplCanCorruptMailbox()
in case the CAN RAM check fails for a certain
mailbox.

7.2.7
Extended CAN RAM Check
The  extended RAM check provides an additional check of the CAN cell control  registers
RAM with extended API and modified standard CAN RAM check and driver behaviour.
The RSCAN control registers are differentiated between registers that have to be written in
global  reset  mode  (afterwards  referred  to  as  “global  registers”)  or  can  also  be  written  in
channel reset mode (afterwards referred to as “channel registers”). Since the transition to
global reset mode affects all channels, the global register RAM is checked only once within
CanInitPowerOn(). If the global register RAM is considered corrupt a call-back function
(see below) is issued to allow the application to control whether the driver initialization is
proceeded or not.
The  channel  register  and  mailbox  RAM  check  is  performed  within  the  function
CanInit(). The registers RAM check disables the complete channel communication if at
least  one  of  the  checked  registers  is  considered  corrupt. The  mailbox  RAM  check  (only
available for Tx objects) disables corrupt mailboxes so that no transmission is possible on
them.  In  both  cases  the  appropriate  call-backs  (see  below)  are  called  to  inform  the
application  about  the  failures.  Channels  and  mailboxes  can  be  re-enabled  by  the
application  using  the  extended API.  If  any  of  the  control  registers  check  or  the  mailbox
registers  check  fails  the  overall  RAM  check  call-back  ApplCanMemCheckFailed()  is
invoked.
More detailed information is given below; section 9.3 describes the API functions:
  If any of the global registers (e.g. global configuration registers, registers relating to the
configuration of receive objects and receive rules) are considered corrupt the function
ApplCanGlobalMemCheckFailed()  is  invoked  within  CanInitPowerOn().  If  this
function  returns  kCanEnableCommunication  the  initialization  is  continued  ignoring
the results of the check. If it returns kCanDisableCommunication the RSCAN is put
back  into  global  stop  mode  and  CanInitPowerOn()  returns  without  initializing  the
RSCAN.  The  check  of  the  channel  registers  RAM  is  also  not  performed  and
CanInitPowerOn() has to be called again to be able to use the CAN functionality in
this case (other CAN API functions must not be called until CanInitPowerOn() was
executed completely). The check is performed with every call of this function.
  If  any  of  the  channel  control  registers  are  considered  corrupt  the  function
ApplCanCorruptRegisters()  is  called  and  the  communication  on  the  given
channel is disabled. The CAN cell stays in stop mode whatever the general call-back
function ApplCanMemCheckFailed()  returns  and the  channel  is disconnected from
the Tx port pin.
2015, Vector Informatik GmbH
Version: 1.08.00
21 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

  If  a  corrupt  mailbox  is  found  it  is  disabled  by  the  driver  and  the  call-back  function
ApplCanCorruptMailbox()  is  invoked  (if  this  is  enabled  by  the  definition  of
C_ENABLE_NOTIFY_CORRUPT_MAILBOX).  In  this  case  (but  only  if  no  corrupt  CAN
control registers were found on the given channel) the application can decide whether
the  communication  on  the  channel  should  be  disabled  using  the  return  value  of  the
function ApplCanMemCheckFailed(), but the mailbox stays disabled anyway.
  If the communication on a channel was disabled previously it can be re-enabled using
the function CanEnableChannelCommunication().
  Mailboxes that were disabled by mailbox RAM check can be re-enabled by the function
CanEnableMailboxCommunication() (but  only if the communication on the given
channel is enabled).
  No  mailbox  or  register  RAM  check  is  performed  and  no  RAM  check  call-backs  are
invoked  if  CanInit()  is  called  by  CanResetBusOffEnd().  However,  all  previously
disabled channels or mailboxes stay disabled.

Caution
The  only  way  to re-enable  channel  or  mailbox  communication  is  to  use  the  functions
  CanEnableChannelCommunication(),  CanEnableMailboxCommunication()
or CanInitPowerOn().

The extended CAN RAM check feature needs the standard CAN RAM check functionality
to  be  activated.  The  following  settings  have  to  be  done  in  the  user  configuration  file.  In
case  no  user  config  file  is  used  (i.e.  the  mentioned  switch  is  not  defined)  the  feature  is
disabled. Please note that this is a project specific feature that might not be available and
C_ENABLE_CAN_RAM_CHECK_EXTENDED has no effect in this case.
Switch
Value  Description
C_ENABLE_CAN_RAM_CHECK_EXTENDED

Activate the extended CAN RAM check feature.

7.2.8
RSCAN ECC Configuration
In context of the RSCAN RAM error detection and correction (ECC) the driver provides the
additional  call-back  function  ApplCanEccConfiguration()  (see  section  9.2)  that  is
invoked by CanInitPowerOn() after the CAN RAM initialization is complete and before
the RSCAN is configured while the cell is in global stop mode. This gives the application
the possibility to configure the ECC behavior for  the RSCAN. The driver offers no further
support for this feature - any ECC configuration and handling has to be performed by the
application.
The following settings have to be done in the user configuration file. In case no user config
file is used (i.e. the mentioned switch is not defined) the feature is disabled.
Switch
Value  Description
C_ENABLE_ECC_CALLOUT

Activate call of ApplCanEccConfiguration().

2015, Vector Informatik GmbH
Version: 1.08.00
22 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

7.2.9
RSCAN RAM Test
The RSCAN provides a global test mode that enables the driver to perform a check of the
internal  RSCAN  RAM  that  is  not  accessible  during  normal  operation.  This  check  is
performed once  within  CanInitPowerOn().  Similar  to the  (extended)  CAN  RAM  check
the internal RAM is considered corrupt if predefined patterns are written to the appropriate
RAM  addresses  and  read  operations  do  not  return  the  expected  patterns.  If  any  corrupt
bits  are  found  the  call-back  function  ApplCanGlobalMemCheckFailed()  is  invoked
(see section 9.3). If this function returns kCanEnableCommunication the initialization is
continued  ignoring  the  results  of  the  check.  If  it  returns  kCanDisableCommunication
the RSCAN is put back into global stop mode and CanInitPowerOn() returns without
initializing the RSCAN. CanInitPowerOn() has to be called again to be able to use the
CAN  functionality  in  this  case  (other  CAN  API  functions  must  not  be  called  until
CanInitPowerOn()  was  executed  completely).  The  RAM  test  is  performed  with  every
call of this function.
If this test is used in combination with the (extended) CAN RAM check the coverage of the
latter one is reduced in order to save runtime.
  The receive rule registers are omitted by  the global register check within the function
CanInitPowerOn().
  The mailbox check is omitted if CanInit() is called out of CanInitPowerOn().

The following settings have to be done in the user configuration file. In case no user config
file is used (i.e. the first switch is not defined) the feature is disabled. The second switch is
only evaluated if C_ENABLE_CAN_HW_RAM_CHECK is defined.
Switch
Value
Description
C_ENABLE_CAN_HW_RAM_CHECK

Activate the RSCAN RAM test feature.
C_ENABLE_CAN_HW_RAM_CHECK_SIZE
32 .. 65504  The given number of bytes is checked by the
(bytes)
RAM test (always starting from the beginning
of the CAN RAM). The value must be a
multiple of 32 bytes and has to be valid for the
used derivative (refer to the corresponding
hardware manual).

Caution
Depending  on  the  size  of  RAM  to  be  checked,  used  compiler  options,  clock  settings
  and others this check might take up to several milliseconds. Suggestion is to verify the
runtime of CanInitPowerOn()in the actual project if this feature is enabled.

2015, Vector Informatik GmbH
Version: 1.08.00
23 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

8   [#hw_assert] – Assertions
The driver implements no specific assertions with additional error codes.
2015, Vector Informatik GmbH
Version: 1.08.00
24 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

9  API
9.1
Category
Single Receive Channels (SRC)

A “Single Receive Channel” CAN Driver supports one CAN
channel.)
Multiple Receive Channel (MRC)

A "Multiple Receive Channel" CAN Driver is typically
extended for multiple channels by adding an index to the
function parameter list (e.g. CanOnline() becomes
CanOnline(channel)) or by using the handle as a
channel indicator (e.g. CanTransmit(txHandle)).
Table 9-1   API Category

9.2
RSCAN ECC Configuration
In  context  of  the  RSCAN  ECC  feature  the  application  has  to  provide  following  call-back
function (see section 7.2.8 further information).

ApplCanEccConfiguration
Prototype
Single Receive Channel
void ApplCanEccConfiguration (void)
Multiple Receive Channel
void ApplCanEccConfiguration (void)
Parameter
-
-
Return code
-
-
Functional Description
This function is called by CanInitPowerOn() to allow the configuration of the RSCAN ECC functionality.
Particularities and Limitations
Only required if C_ENABLE_ECC_CALLOUT is defined.

2015, Vector Informatik GmbH
Version: 1.08.00
25 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

9.3
(Extended) CAN RAM Check

In context of the CAN RAM check feature the application has to provide following call-back
functions (see sections 7.2.6 and 7.2.7 for further information).

ApplCanMemCheckFailed
Prototype
Single Receive Channel
vuint8 ApplCanMemCheckFailed (void)
Multiple Receive Channel
vuint8 ApplCanMemCheckFailed (CanChannelHandle channel)
Parameter
This parameter specifies the CAN channel on which the memory check is
CanChannelHandle channel
performed.
Return code
vuint8
kCanEnableCommunication – Allow communication (see note in
“Particularities and Limitations”).
kCanDisableCommunication – Disable communication, no reception and
no transmission is performed.
Functional Description
This call-back function is invoked within CanInit() if the CAN driver has found at least one corrupt bit
within the CAN mailboxes RAM or (if extended CAN RAM check is enabled) at least one corrupt bit within
the channel control registers RAM. The application can decide whether the CAN driver allows further
communication by means of the return value.
Particularities and Limitations
Call context: If the feature Extended CAN RAM check is deactivated this function is called on task level or
within the BusOff interrupt; else only on task level.
Configuration: Required if the following setting is active:
C_ENABLE_CAN_RAM_CHECK
Important note: If the optional feature “Extended CAN RAM check” is activated
(C_ENABLE_CAN_RAM_CHECK_EXTENDED is defined) and the registers RAM check failed (call-back
function ApplCanCorruptRegisters() was called for the given channel), the communication on the
channel will be disabled, the CAN cell stays in stop mode and the return value of this function is ignored –
the communication will NOT be allowed even if the return value is kCanEnableCommunication.

2015, Vector Informatik GmbH
Version: 1.08.00
26 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

ApplCanCorruptMailbox
Prototype
Single Receive Channel
void ApplCanCorruptMailbox (CanObjectHandle hwObjHandle)
Multiple Receive Channel
void ApplCanCorruptMailbox (CanChannelHandle channel,
CanObjectHandle hwObjHandle)

      CanObjectHandle hwObjHandle )
Parameter
This parameter specifies the CAN channel on which the memory check is
CanChannelHandle channel
performed.
This parameter specifies the index of the corrupt mailbox.
CanObjectHandle

hwObjHandle
Return code
-
-
Functional Description
This function is called within CanInit() if the CAN driver has found a corrupt mailbox.
Particularities and Limitations
Call context: If the feature “Extended CAN RAM check” is deactivated this function is called on task level or
within the BusOff interrupt; else only on task level.
Configuration: Required if the following settings are active:
C_ENABLE_CAN_RAM_CHECK
C_ENABLE_NOTIFY_CORRUPT_MAILBOX

In case the feature extended CAN RAM check is enabled the following additional call-back
functions have to be provided by the application.

ApplCanCorruptRegisters
Prototype
Single Receive Channel
void ApplCanCorruptRegisters (void)
Multiple Receive Channel
void ApplCanCorruptRegisters (CanChannelHandle channel)
Parameter
This parameter specifies the CAN channel on which the memory check is
CanChannelHandle channel
performed.
Return code
-
-
Functional Description
This function is called if the CAN driver has found corrupt channel control registers.
Particularities and Limitations
Call context: This function is called out of task level within CanInit() on the given channel if the RAM
check is not suppressed. The RAM check is suppressed if CanInit() is called in scope of the functions
CanResetBusOffEnd()or (dependent on parameter) CanEnableChannelCommunication().
Configuration: Required if the following settings are active:
C_ENABLE_CAN_RAM_CHECK
C_ENABLE_CAN_RAM_CHECK_EXTENDED

2015, Vector Informatik GmbH
Version: 1.08.00
27 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

ApplCanGlobalMemCheckFailed
Prototype
Single Receive Channel
vuint8 ApplCanGlobalMemCheckFailed (void)
Multiple Receive Channel
vuint8 ApplCanGlobalMemCheckFailed (void)
Parameter
-
-
Return code
vuint8
kCanEnableCommunication – Continue initialization of the RSCAN.
kCanDisableCommunication – Stop initialization of the RSCAN.
Functional Description
This call-back function is invoked if the CAN driver has found at least one corrupt bit within the global control
registers RAM in context of the extended CAN RAM check or if any corrupt bit was found in context of the
RSCAN RAM test (see section 7.2.9). The application can decide whether the CAN driver proceeds with the
RSCAN initialization by means of the return value.
Particularities and Limitations
Call context: This function is called out of task level within CanInitPowerOn().
Configuration: Required if the following settings are active:
C_ENABLE_CAN_RAM_CHECK
C_ENABLE_CAN_RAM_CHECK_EXTENDED
or
C_ENABLE_CAN_HW_RAM_CHECK
Important note: Be aware of undefined runtime behavior if kCanEnableCommunication is returned as
the driver tries to initialize and communicate despite corrupt RAM was found. The application has to verify
the system in this case.

2015, Vector Informatik GmbH
Version: 1.08.00
28 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

The following service functions are provided by the driver in context of the extended CAN
RAM check feature.

CanEnableChannelCommunication
Prototype
Single Receive Channel
void CanEnableChannelCommunication (vuint8 suppressRamCheck)
void CanEnableChannelCommunication (CanChannelHandle channel,
Multiple Receive Channel
vuint8 suppressRamCheck)
Parameter
This parameter specifies the CAN channel that shall be re
CanChannelHandle channel
-enabled.
vuint8 suppressRamCheck
kCanTrue – RAM check will be suppressed while re-enabling the
communication on the channel.
kCanFalse – RAM check will be performed while re-enabling the
communication on the channel
Return code
-
-
Functional Description
The function re-enables the channel communication if it was disabled previously. It calls CanInit()
internally but all eventually disabled mailboxes stay disabled. If the RAM check is not suppressed it can fail
again and the appropriate call-back function is invoked in this case.
Particularities and Limitations
Restriction: Same restrictions as for a call of CanInit() apply.
Call context: This function is called by the application.
Configuration: Available if the following settings are active:
C_ENABLE_CAN_RAM_CHECK
C_ENABLE_CAN_RAM_CHECK_EXTENDED

2015, Vector Informatik GmbH
Version: 1.08.00
29 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

CanEnableMailboxCommunication
Prototype
Single Receive Channel
vuint8 CanEnableMailboxCommunication (CanObjectHandle

hwObjHandle)
Multiple Receive Channel
vuint8 CanEnableMailboxCommunication (CanChannelHandle channel,

CanObjectHandle hwObjHandle)
Parameter
This parameter specifies the CAN channel for which the mailbox shall be
CanChannelHandle channel
re-enabled.
The index of the mailbox to be re
CanObjectHandle
-enabled.
hwObjHandle
Return code
vuint8
kCanOk - Mailbox communication was re-enabled.
kCanFailed - Enabling of mailbox communication failed: hwObjHandle is
not a valid Tx mailbox, the mailbox was not disabled previously or the
communication on the channel is still disabled.
Functional Description
The function re-enables the mailbox communication that was disabled previously by the extended CAN
RAM check. Note that the mailbox RAM check is not performed in scope of this function call - the
application must guarantee that the mailbox is not corrupt.
Particularities and Limitations
Call context: This function is called by the application.
Configuration: Available if the following settings are active:
C_ENABLE_CAN_RAM_CHECK
C_ENABLE_CAN_RAM_CHECK_EXTENDED

2015, Vector Informatik GmbH
Version: 1.08.00
30 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

9.4
External CAN Interrupt Handling
These  call-back  functions  are  invoked  if  the  driver  does  not  perform  the  CAN  interrupt
handling. See section 10.3 for details.

ApplCanWriteIcr8
Prototype
Single Receive Channel
void ApplCanWriteIcr8 (vuint32 address, vuint8 value)
Multiple Receive Channel
void ApplCanWriteIcr8 (vuint32 address, vuint8 value)
Parameter
This parameter specifies the memory address the function has to write to.
vuint32 address
It is always part of the interrupt controller address space.
vuint8 value
This parameter specifies the value the function has to write.
Return code
-
-
Functional Description
This call-back is invoked by several driver functions and has to write one byte with the given value to the
given address.
Particularities and Limitations
Only required if C_ENABLE_INTC_ACCESS_BY_APPL is defined.
Always perform a byte access. The function has to be synchronous.

ApplCanReadIcr8
Prototype
Single Receive Channel
vuint8 ApplCanReadIcr8 (vuint32 address)
Multiple Receive Channel
vuint8 ApplCanReadIcr8 (vuint32 address)
Parameter
This parameter specifies the memory address the function has to read
vuint32 address
from. It is always part of the interrupt controller address space.
Return code
vuint8
The value that was read from the given address.
Functional Description
This call-back is invoked by several driver functions and has to read and return one byte from the given
address.
Particularities and Limitations
Only required if C_ENABLE_INTC_ACCESS_BY_APPL is defined.
Always perform a byte access. The function has to be synchronous.

2015, Vector Informatik GmbH
Version: 1.08.00
31 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

OsCanCanInterruptDisable
Prototype
Single Receive Channel
void OsCanCanInterruptDisable (void)
Multiple Receive Channel
void OsCanCanInterruptDisable (CanChannelHandle channel)
Parameter
This parameter specifies the logical CAN channel for which the interrupts
CanChannelHandle channel
shall be disabled.
Return code
-
-
Functional Description
This function is called by CanCanInterruptDisable() and has to disable the CAN interrupts on the
given channel.
Particularities and Limitations
Only required if C_ENABLE_OSEK_CAN_INTCTRL is defined.

OsCanCanInterruptRestore
Prototype
Single Receive Channel
void OsCanCanInterruptRestore (void)
Multiple Receive Channel
void OsCanCanInterruptRestore (CanChannelHandle channel)
Parameter
This parameter specifies the logical CAN channel for which the interrupts
CanChannelHandle channel
shall be restored.
Return code
-
-
Functional Description
This function is called by CanCanInterruptRestore() and has to restore the CAN interrupts on the
given channel.
Particularities and Limitations
Only required if C_ENABLE_OSEK_CAN_INTCTRL is defined.

2015, Vector Informatik GmbH
Version: 1.08.00
32 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

ApplCanWakeupInterruptDisable
Prototype
Single Receive Channel
void ApplCanWakeupInterruptDisable (vuint8 channel)
Multiple Receive Channel
void ApplCanWakeupInterruptDisable (vuint8 channel)
Parameter
This parameter specifies the logical CAN channel for which the wakeup
vuint8 channel
interrupt shall be disabled.
Return code
-
-
Functional Description
This function is called by CanWakeup() and CanInit() and has to disable the wakeup interrupt on
the given channel.
Particularities and Limitations
Only required if C_ENABLE_OSEK_CAN_INTCTRL and C_ENABLE_SLEEP_WAKEUP are defined and the
external wakeup is used.

ApplCanWakeupInterruptEnable
Prototype
Single Receive Channel
void ApplCanWakeupInterruptEnable (vuint8 channel)
Multiple Receive Channel
void ApplCanWakeupInterruptEnable (vuint8 channel)
Parameter
This parameter specifies the logical CAN channel for which the wakeup
vuint8 channel
interrupt shall be enabled.
Return code
-
-
Functional Description
This function is called by CanSleep() and has to enable the wakeup interrupt on the given channel.
Particularities and Limitations
Only required if C_ENABLE_OSEK_CAN_INTCTRL and C_ENABLE_SLEEP_WAKEUP are defined and the
external wakeup is used.

2015, Vector Informatik GmbH
Version: 1.08.00
33 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

ApplCanWakeupOccurred
Prototype
Single Receive Channel
vuint8 ApplCanWakeupOccurred (vuint8 channel)
Multiple Receive Channel
vuint8 ApplCanWakeupOccurred (vuint8 channel)
Parameter
This parameter specifies the logical CAN channel to check for a wakeup
vuint8 channel
occurrence.
Return code
CAN_NOT_OK: If no wakeup occurred on this channel
vuint8
CAN_OK: If a wakeup occurred on this channel
Functional Description
This function is called by CanWakeupTask() and has to check for a wakeup event on the given
channel.
Particularities and Limitations
Only required if C_ENABLE_OSEK_CAN_INTCTRL, C_ENABLE_SLEEP_WAKEUP and
C_ENABLE_WAKEUP_POLLING are defined and the external wakeup is used.

2015, Vector Informatik GmbH
Version: 1.08.00
34 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

10  Implementations Hints
10.1  Important Notes
1.  The  following  condition  will  lead  to  an  endless  recursion  in  the  CAN  Driver:
Recursive  call  of  'CanTransmit'  within  a  confirmation  routine,  if  the  CAN  Driver  has
been set into the passive state by CanSetPassive. Recommendations are:
>  NO CALL OF CanTransmit WITHIN CONFIRMATION-ROUTINES
>  PLEASE USE CanSetPassive ONLY ACCORDING TO THE DESCRIPTION

2.  Only  the  transmit  line  of  the  CAN  Driver  is  blocked  by  the  functions  CanOffline().
However, messages in the transmit buffer of the CAN-Chip, are still sent. For a reliable
prevention  of  this  fact,  call  function  CanInit()  after  calling  CanOffline().  The
order of the two function calls is urgently required, due to the fact, that CanInit() is
only allowed in offline mode.
3.  If the VStdLib interrupt-lock-level is used, the chosen priority level must be higher than
the  highest  level  of  any  functionality  of  the  CAN  Driver  (signal  access,  etc).  Keep  in
mind that smaller values represent higher priorities.
4.  Resetting  indication  flags  and  confirmation  flags  is  done  by  Read-Modify-Write.  The
application  is  responsible  for  consistency.  CanGlobalInterruptDisable()  and
CanGlobalInterruptRestore()  must  be  called  to  avoid  interruption  by  the  CAN.
Otherwise confirmations or indications can be lost.
5.  Port and general clock settings are not handled by the driver. This has to be performed
by  the  upper  layers  before  the  call  of  CanInitPowerOn().  Please  check  the
appropriate hardware manual of the used derivative for details regarding the hardware
specific  configuration  aspects.  The  CAN  clock  (fCAN)  for  baudrate  generation  can  be
selected via the configuration tool; refer to section 11.1.2.
6.  If  external  wakeup  support  is  used  the  port  configuration  (performed  by  the  upper
layers) has to be extended. Besides setting the correct port functions for CAN it has to
be  ensured  that  this  function  is  combined  with  the  respective  external  interrupt.
Additionally the edge/level detection has to be configured correctly to generate interrupt
requests  upon  detection  of  CAN  events  (e.g.  on  low  level  or  falling  edges)  on  the
corresponding  pins  (see  the  hardware  manual  for  details;  refer  to  the  filter  control
register for instance). If the external wakeup is used the control registers of the external
interrupts are also fully handled by the CAN driver in default configuration.
7.  When using GreenHills, IAR or Renesas compiler the ID bit of the PSW is cleared by
software when any category 1 interrupt service routine of the CAN driver is entered to
allow  nesting  of  interrupts.  For  other  compilers  the  default  platform  behavior  is  not
modified (the ID bit stays set) and the acknowledgement of further interrupt requests is
blocked when any driver ISR is processed. This default driver behavior for category 1
interrupts  can  be  changed  by  definition  of  C_DISABLE_NESTED_INTERRUPTS
respectively C_ENABLE_NESTED_INTERRUPTS via the user configuration file. Keep in
mind that enabling the feature is redundant if the compiler inserts code to allow nesting
of interrupts in general and always verify that the compiler generates correct code if the
feature is enabled.
2015, Vector Informatik GmbH
Version: 1.08.00
35 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

10.2  Interrupt Configuration
With  exception  of  the  CAN  related  EI  level  interrupt  control  registers  (ICn,  see  section
7.2.3) all further interrupt configuration within the interrupt controller address space of the
MCU has to be performed by the application before the call of CanInitPoweron().
The  default  implementation  configures  table  reference  as  the  way  to  determine  the
interrupt  vector  (TB  bit  in  ICn  registers  is  set).  The  application  has  to  take  care  about
referencing the CAN interrupt service routines in the interrupt vector table - the prototypes
are  exported in  the driver header file.  Please check the appropriate hardware  manual of
the used derivative for details regarding the hardware specific configuration aspects. Table
10-1 shows the provided  ISRs and the accordant interrupt  sources (n is the index of the
physical  channel).  Please  note  that  it  is  configuration  dependent  whether  a  particular
interrupt service routine is available (see remarks in table).

CAN interrupt
CAN interrupt
Provided service  Remarks
request name
request cause
routine
CAN RX FIFO
Used for BasicCAN reception if ‘Rx
INTRCANGRECC  interrupt
CanIsrRxFifo
BasicCan Polling’ is not enabled or

‘Individual Polling’ is configured.
CAN global error
INTRCANGERR
Used for Rx BasicCAN overrun if ‘Error

interrupt
CanIsrGlobalStatus

Polling’ is not enabled.
Used for transmission on physical
INTRCANnTRX
CANn TX interrupt
CanIsrTx_n
channel n if ‘Tx Polling’ is not enabled
or ‘Individual Polling’ is configured.
CANn TX/RX  FIFO
INTRCANnREC
RX complete interrupt -
This interrupt is not used.

Used for BusOff detection on physical
INTRCANnERR
CANn error interrupt
CanIsrStatus_n
channel n if ‘Error Polling’ is not
enabled.
Used for wakeup detection on physical
External interrupt
channel n if the Sleep/Wakeup
INTPm

(see chapter 4)
CanIsrWakeup_n
functionality is enabled, the external

wakeup is used and ‘Wakeup Polling’ is
not enabled.
Table 10-1   Interrupt Service Routines
If the INTC shall implement direct jumps to an address determined by the interrupt priority
level  (instead  of  table  reference)  the  switch  C_ENABLE_DIRECT_INTERRUPT_BRANCH
has to be defined via the user configuration file. (This setting affects the TB bit in the ICn
registers.) In this case the application has to implement a common service routine for all
CAN interrupts and jump to it from the corresponding address (refer to  hardware manual
for configuration aspects).
See below an implementation example for GreenHills compiler and a full interrupt system
with disabled Sleep/Wakeup functionality that uses physical channels 1 and 4; also refer to
the information in table 10-1 about the presence of the individual CAN interrupt functions.
Each driver routine must not be called if the CAN interrupts for the corresponding channel
(respectively  any  CAN  channel  for  the  global  handlers)  are  currently  disabled.  This  is
especially relevant if more than one channel is used or other interrupt sources also call the
common service routine. In general it is recommended to check the status of the MK bit in
2015, Vector Informatik GmbH
Version: 1.08.00
36 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

the  ICn  register  of  each  CAN  interrupt  source  before  invoking  the  corresponding  driver
routine as these bits directly indicate the status of the CAN interrupt lock mechanism. Any
driver routine may only be called if the corresponding interrupt source is enabled (MK bit
== 0). These actions may differ if the application handles the CAN interrupt disable/restore
mechanism (see section 10.3 below), but the requirements above must always be met.  If
the feature “Multiple Configurations” is used only functions corresponding to channels that
are used in the active identity should be called.

#pragma ghs interrupt
void CommonIsr_Prio_x ( void )
{
  /* handling for other interrupts that are assigned to
this priority and not handled by table reference */

  /* CAN interrupts */
  if (MK bit of INTRCANGRECC == 0) CanIsrRxFifo();
  if (MK bit of INTRCANGERR == 0) CanIsrGlobalStatus();
  if (MK bit of INTRCAN1ERR == 0) CanIsrStatus_1();
  if (MK bit of INTRCAN1TRX == 0) CanIsrTx_1();
  if (MK bit of INTRCAN4ERR == 0) CanIsrStatus_4();
  if (MK bit of INTRCAN4TRX == 0) CanIsrTx_4();

  /* handling for other interrupts that are assigned to
this priority and not handled by table reference */
}

Since  the  common  service  routine  is  already  qualified  as  an  ISR  to  the  compiler,  the
individual CAN interrupt routines have to be configured as void-void functions if this variant
is used. Therefore the switch C_ENABLE_ISRVOID additionally has to be defined via the
user configuration file (if category 1 CAN interrupts are used).

Caution
The  driver  performs  no  measures  to  ensure  the  correct  functionality  of  the  CAN
  interrupt disable/restore mechanism if it is bypassed by the common interrupt handler
when  C_ENABLE_DIRECT_INTERRUPT_BRANCH  is  defined.  Therefore  the  usage  of
this switch in not recommended in general and should only be defined if table reference
is not possible at all.

10.2.1  Configuration of Interrupt Vectors with IAR compiler
Instead  of a  manual  initialization  of  the  interrupt  vector  table  it  is  possible  to  let  the  IAR
compiler  set  up  the  table  by  using  the  #pragma  vector=xx  directive  (only  for  category  1
interrupts). This feature  can  be  enabled  via  the  user  configuration  file  by  defining  the  EI
level  interrupt  number  for  each  used  CAN  interrupt.  The  names  of  these  defines  are
derived from the corresponding ISR names.
See below an example for a full interrupt system with external wakeup support that uses
physical channels 2 and 5. Refer to the information in table 10-1 about the presence of the
individual CAN interrupt functions.

2015, Vector Informatik GmbH
Version: 1.08.00
37 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

#define C_CANISRRXFIFO_VECTOR         15
#define C_CANISRGLOBALSTATUS_VECTOR  14
#define C_CANISRTX_VECTOR_2           211
#define C_CANISRSTATUS_VECTOR_2       209
#define C_CANISRWAKEUP_VECTOR_2       31
#define C_CANISRTX_VECTOR_5           281
#define C_CANISRSTATUS_VECTOR_5       279
#define C_CANISRWAKEUP_VECTOR_5       36

Caution
This is an example and the necessary defines depend on the actual configuration. The
  interrupt numbers depend on the selected derivative; refer to the hardware manual to
get the respective values.

10.3  External CAN Interrupt Handling
There are several solutions if accesses to the EI level interrupt control registers (ICn) are
not possible or allowed for the driver (reasons may be restricted operating modes, memory
protection, bus guard functionalities or similar).
10.3.1  Hardware Access by Call-Back Functions
If the switch C_ENABLE_INTC_ACCESS_BY_APPL is defined via the user configuration file
the  driver  implementation  is  still  used  to  initialize  and  modify  all  ICn  as  described  in  the
previous sections, but all actual read and write accesses to the interrupt control registers
have to be performed by call-back functions.
The functions ApplCanWriteIcr8() and ApplCanReadIcr8() (see section 9.4 for the
API  definitions)  are  always  invoked  when  accessing  registers  of  the  interrupt  controller
(other  peripherals  are  not  accessed  by  the  driver).  These  functions  have  to  be
implemented by the application and perform the hardware access including any unlocking
mechanisms,  checks  for  the  given  addresses  or  similar.  It  is  expected  by  the  driver  that
every access is synchronous and always successfully performed.

Caution
An exclusive write access to the ICn as stated in the previous sections still has to be
  guaranteed.  If  any  access  is  not  successfully  performed  when  these  functions  are
called,  the  driver  has  to  be  re-initialized  by  calling  CanInitPowerOn()  as  correct
behavior cannot be ensured.

10.3.2  Interrupt Control by Application
If  an  exclusive  write  access  to the  CAN  related  ICn  is  not  possible  or  the  internal driver
mechanisms
that  are
described
above
are
not  applicable,
the
switch
C_ENABLE_OSEK_CAN_INTCTRL  can  be  defined  via  the  user  configuration  file.  In  this
case the application has to ensure proper initialization, disabling and restoring of the CAN
interrupt sources as the driver provides no support for these tasks at all. The registers of
the interrupt controller are never accessed by the driver.
2015, Vector Informatik GmbH
Version: 1.08.00
38 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

If  this  switch  is  defined  the  application  additionally  has  to  perform  the  initialization  of  all
necessary ICn before the call of CanInitPowerOn(). All used sources (see remarks in
table  10-1)  have  to  be  enabled  after  initialization  whereas  unused  sources  have  to  be
disabled.
In  context  of  the  CAN  interrupt  disable/restore  mechanism  the  driver  implements
application  call-back  functions  that  are  used  whenever  CanCanInterruptDisable()
or  CanCanInterruptRestore()  are  invoked  by  the  program  (see  section  9.4  for  the
API definitions). Suggestion is that the function OsCanCanInterruptDisable() saves
the value of the MK bit of the ICn of all used CAN interrupt sources that are linked to the
given  logical  channel  and  then  sets  these  MK  bits  to  1  in  order  to  disable  the  sources.
OsCanCanInterruptRestore()  should  restore  the  value  of  the  previously  saved  MK
bits for the given logical channel. Keep in mind that the right physical channel has to be
chosen based on the given logical channel (to get the right ICn) and that the receive FIFO
and global status interrupt are used by all channels, hence they should be disabled as long
as any channel’s interrupts are disabled.
If the Sleep/Wakeup functionality is enabled and the external wakeup is used please note
that the external wakeup interrupts always have to be disabled after initialization as these
sources are only enabled on demand. Also additional application call-back functions (see
section 9.4 for the API definitions) are invoked by the driver. This is relevant for interrupt
and polling systems as the external interrupt request flag has to be cleared independently
of the interrupt configuration.
ApplCanWakeupInterruptEnable()  is  always  invoked  in  context  of  CanSleep().
This function first has to clear the external interrupt request flag in the  corresponding ICn
and  then  –  only  if  wakeup  detection  is  performed  by  interrupts  –  enable  the  external
interrupt.  Keep  in  mind  that  depending  on  the  current  status  of  the  CAN  interrupt
disable/restore mechanism this has to be performed either by clearing the corresponding
mask bit in the respective hardware register or in the mask status that was saved by the
function  OsCanCanInterruptDisable().  ApplCanWakeupInterruptDisable()  is
only  invoked  if  wakeup  detection  is  performed  by  interrupts  in  context  of  CanWakeup(),
respectively  the  external  wakeup  handling,  and  in  CanInit().  This  function  has  to
disable the interrupt, depending on the current status of the CAN interrupt disable/restore
mechanism either by setting the corresponding mask bit in the hardware register or in the
saved  mask  status.  ApplCanWakeupOccurred()  is  called  in  context  of  the  function
CanWakeupTask() to check for the occurrence of a wakeup event (i.e. the presence of
the interrupt request flag) if the detection is performed by polling.
The implementation may differ but all CAN interrupts for the corresponding channel have
to  be  disabled  after  the  first  call  (keep  in  mind  that  nested  calls  can  occur)  of
OsCanCanInterruptDisable()  and  stay  disabled  until  the  last  nested  call  of
OsCanCanInterruptRestore()  that  has  to  restore  the  previous  interrupt  state.
ApplCanWakeupInterruptEnable()  and  ApplCanInterruptDisable()  have  to
enable and disable the wakeup interrupt for one channel but must not violate the general
CAN interrupt disable/restore mechanism. It is also important to clear the wakeup interrupt
request  flag  within  ApplCanWakeupInterruptEnable().  The  application  additionally
has to handle possible concurrent accesses to the ICn and ensure that those accesses do
not violate the conditions above.

2015, Vector Informatik GmbH
Version: 1.08.00
39 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Caution
The  definition  of  C_ENABLE_INTC_ACCESS_BY_APPL  is  recommended  if  interrupt
  control registers cannot be accessed by the driver. If C_ENABLE_OSEK_CAN_INTCTRL
is defined the driver performs no measures to ensure consistency of the interrupt lock
mechanism. Additionally the application has to ensure correct concurrent accesses to
the  ICn  and  has  to  handle  nested  calls  of  OsCanCanInterruptDisable()  and
OsCanCanInterruptRestore().  Therefore  the  usage  of  this  switch  is  not
recommended in general and should only be defined if the internal driver mechanisms
or the definition of C_ENABLE_INTC_ACCESS_BY_APPL are not possible at all.

2015, Vector Informatik GmbH
Version: 1.08.00
40 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11  Configuration
11.1  Configuration by GENy
The  driver  is  configured  with  the  help  of  the  configuration  tool  GENy.  This  section
describes  the  configuration  of  the  driver  specific  aspects.  The  configuration  options
common to all CAN drivers are described in TechnicalReference_CANDriver.pdf.

Note
To get further information please refer to the online help of the generation tool.

11.1.1  Platform Settings

Figure 11-1  GENy Platform Settings
Attribute
Supported
Description
Values
Preconfiguration

Select the pre-configuration file to use.
Micro
Hw_Rh850Cpu
Select the target platform.
Derivative
See Table 2-1
Select the specific derivative group.
Compiler
See Table 2-1
Select the used compiler.
Table 11-1   GENy Platform Settings

2015, Vector Informatik GmbH
Version: 1.08.00
41 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.1.2  Component Settings

Figure 11-2  GENy Component Settings
Attribute
Supported
Description
Values
CAN Interface
RSCAN,
Select the CAN interface that is incorporated by the used
RSCAN_FD
derivative - see the HW manual for information. This selection
is independent of the actual CAN-FD usage as the driver has
to handle general hardware differences for both variants.
Maximum number of
1 - 8
Enter the maximum number of physical CAN channels that
CAN channels
are supported by the used RSCAN unit of the actual
derivative. This value is independent from the number of
channels in the configuration but used to determine the
available hardware resources. Only if this value is correct the
tool can ensure valid configurations for the actual derivative.
Depending on the selected derivative not all values may be
available.
CAN external clock
true,
Enable this attribute to use the external clock input
source
false
(clk_xincan) as CAN clock (fCAN). If the attribute is disabled
clkc is used - this is the default selection. (This setting directly
affects the DCS bit in the global configuration register.)
Table 11-2   GENy Component Settings

2015, Vector Informatik GmbH
Version: 1.08.00
42 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.1.3  Channel-specific Settings

Figure 11-3  GENy Channel Specific Settings

Caution
The  sum  of  the  shared  buffers  used  to  allocate  the  receive  objects  over  all  channels
  must  not  exceed  (“Maximum  number  of  CAN  channels”    *  64)7.  This  includes  the  Rx
FullCAN  objects  (1  buffer  per  actually  assigned  object;  not  the  value  of  “Rx  FullCAN
object  allocation)  and  the  depth  of  all  Rx  BasicCAN  objects  (individually  configurable
amount of buffers, selected by the attribute “Rx Fifo depth”) on all channels.
The  sum  of  used  acceptance  filters  over  all  channels  must  not  exceed  (“Maximum
number of CAN channels” * 64)7. Each actually assigned Rx FullCAN object uses one
filter  and  each  Rx  BasicCAN  object  uses the  number  of filters  that  is  selected  by the
attribute “Filters per BasicCAN” on the corresponding channel.
The generation tool checks these and other restrictions (e.g. allowed selection for the
attribute “Physical controller”) to ensure valid configurations. Therefore it is mandatory
to enter a valid value for the attribute “Maximum number of CAN channels”7. Refer to
chapter 3 for additional information.


7 Refer to section 11.1.2 for the description of the attribute “Maximum number of CAN channels“.
2015, Vector Informatik GmbH
Version: 1.08.00
43 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

Attribute
Supported
Description
Values
BCFG
register value
The value for the Channel Configuration Register.
Acceptance Filter
-
Opens the acceptance filter dialog, see section 11.1.3.1. If
Configuration
several init structures are created this is only possible for the
first structure.
Bustiming
-
Opens the bustiming dialog to determine the value for BCFG,
Configuration
see section 11.1.3.2.
Physical controller
CAN 0 – CAN 7
Select the physical channel you want to assign to this logical
channel. The value is enumerated the same way as referenced
in the hardware manual. Depending on the selected derivative
and configuration of the attribute “Maximum number of CAN
channels” (see section 11.1.2) not all values may be available.
CAN interrupt priority  0 – 15
Select the interrupt priority level of this CAN channel’s interrupts
that are configured if the driver has interrupt control. Depending
on the selected derivative not all levels may be available. See
section 7.2.3 and chapter 10 for further information.
Rx FullCAN object
0 – nRXMBmax
You can configure as many receive FullCAN messages on this
allocation
channel as specified here. This value is used to limit the
selection for manual or automatic configuration - only the
actually arranged FullCAN objects will be configured in
hardware. The value of nRXMBmax equals “Maximum number
of CAN channels” * 16.
Filters per BasicCAN  1 – 128
Select how many acceptance filters will be assigned to each Rx
BasicCAN object on this channel; see section 11.1.3.1 for
details. Depending on the selected derivative not all values may
be available.
Rx Fifo process count  2 – 255
Select the maximum number of pending receive messages that
are processed for each Rx BasicCAN object within one polling
cycle respectively one interrupt occurrence. By adjusting this
value it can be ensured that high FIFO loads will be evenly
processed by the driver. Remaining messages are processed
within the next polling cycle respectively the interrupt of the next
received message on this channel. Select greater values if
overruns occur.
Rx Fifo depth
4, 8, 16, 32,
Individually configure the depth (amount of assigned shared
48, 64, 128
buffers) of every Rx FIFO, that is used as Rx BasicCAN object
on this channel.
Table 11-3   GENy Channel Specific Settings

Note
As  the  RSCAN  has  restrictions  regarding  the  receive  buffers  (e.g.  no  interrupt
  processing,  no  overrun  detection)  also  consider  configurations  without  Rx  FullCAN
objects. The large FIFO sizes and amount of filters that are possible for the BasicCAN
objects  give  similar  advantages  as  the  usage  of  FullCAN  objects.  For  many
configurations  this  can  be  an  alternative  that  above  all  is  more  effective  regarding
runtime and memory usage.

2015, Vector Informatik GmbH
Version: 1.08.00
44 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.1.3.1  Acceptance Filter Configuration

Figure 11-4  GENy Acceptance Filter Configuration
Attribute
Supported
Description
Values
Acceptance Filter
representation of
The configured BasicCAN filters are shown. Each ID-bit is
type, mask and
represented by “0/1/X”, meaning must match “0”, “1” or don’t
code
care “X”. The number of filters can be adjusted by the attribute
“Filters per BasicCAN” on the channel view.
Type
standard,
Select if the filter shall apply to standard or extended ID types.
extended
(Based on the database and configuration only one type may
be available.)
Mask / Code
register values
The register values for this filter that will be configured in
hardware.
Open filters
-
Open the filters completely to receive all messages.
Optimize
-
Configure the filters automatically to just receive IDs in the
database if possible. A large number of filters allow better
optimizations, but don’t configure more filters than the
optimization algorithm uses for message distribution.
“Use FullCAN” tries to put as many messages as possible in
FullCAN objects. Select the maximum number of available
objects by adjusting the attribute “Rx FullCAN object
allocation” on the channel view. This is useful when only a few
number of BasicCAN filters are configured for example.
Table 11-4   GENy Acceptance Filter Configuration
2015, Vector Informatik GmbH
Version: 1.08.00
45 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.1.3.1.1  Additional information if the feature “Multiple BasicCAN objects” is used
The dialog shows all BasicCAN acceptance filters for the respective channel. The amount
of filters equals the product of configured BasicCAN objects and the number of filters per
BasicCAN.  An  example  configuration  with  3  BasicCAN  objects  and  2  filters  per  object
results in 6 filters as shown in figure 11-5. The first 2 filters (in accordance with the attribute
“Filters per BasicCAN”) are assigned to the first BasicCAN object, the next 2 to the second
BasicCAN object and so on.

Figure 11-5  GENy Acceptance Filter Assignment
Please note that  a received message is stored in  the first  mailbox with a matching filter.
After  an  identifier  was  compared  against  the  FullCAN  filters,  it  is  compared  against  the
BasicCAN filters in the order that is depicted in the dialog. This has to be considered when
the  feature  “Multiple  BasicCAN  objects”  is  used.  If  filter  number  1  in  the  example  from
figure 11-5 was open (all bits “don’t care”), all non FullCAN standard identifiers would be
received by BasicCAN0 and BasicCAN2 would never receive any message.

Note
In  some  “Multiple  BasicCAN”  configurations  it  may  be  useful  to  assign  certain
  BasicCAN  messages  to  specific  hardware  objects  as  the  FIFO  depths  or  “Individual
Polling” settings can be adapted to the actual communication aspects for example. As
the  optimization  algorithms  don’t  consider  this  use  case  the  filters  have  to  be  edited
manually in this case.
Alternatively it is possible to configure and lock only several significant filters and then
use the optimization functionality. But after doing so always check the result because
manually configured filters may not always receive the pre-assigned identifiers as the
message could match an automatically assigned filter that is compared first. Focus on
filters with smaller numbers or add some “dummy filters” for earlier objects to achieve
better results.

2015, Vector Informatik GmbH
Version: 1.08.00
46 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.1.3.2  Bustiming Configuration

Figure 11-6  GENy Bustiming Configuration
Attribute
Supported
Description
Values
Clock
CAN clock
Set the clock frequency that is provided to the CAN cell for
baudrate generation (fCAN). Consider the setting of the
attribute “CAN external clock source” (see section 11.1.2).
Baudrate
baudrate
Set the baudrate to be used for this channel.
CAN BTR register
register value
Enter the value for the Channel Configuration Register (see
attribute BCFG in section 11.1.3).
Calculate
-
Calculate possible Channel Configuration Register settings
out of the entered baudrate or vice versa.
CAN_BTR, Sample,
-
Select specific channel configuration register values to adapt
BTL cycles, SJW
the sample point and sync phase to comply with your bus
physics.
Table 11-5   GENy Bustiming Configuration
2015, Vector Informatik GmbH
Version: 1.08.00
47 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

11.2  Manual Configuration
This section describes additional configuration options for special features that can only be
configured via the user configuration file.
  Define  C_DISABLE_NESTED_INTERRUPTS  or  C_ENABLE_NESTED_INTERRUPTS  to
control the nesting of the CAN interrupts. See section 10.1 for further information.
  Define  C_ENABLE_DIRECT_INTERRUPT_BRANCH  (and  if  needed  additionally
C_ENABLE_ISRVOID)  to  deactivate  table  reference  as  the  method  to  handle  CAN
interrupts. See section 10.2 for further information.
  Define  C_ENABLE_INTC_ACCESS_BY_APPL  or  C_ENABLE_OSEK_CAN_INTCTRL  to
prohibit  read  and  write  accesses  within  the  interrupt  controller  address  space.  See
section 10.3 for further information.
  Define C_ENABLE_EXTERNAL_WAKEUP_SUPPRESSION to disable the external wakeup
functionality. See chapter 4 for further information.
  See sections 7.2.6 to 7.2.9 for options that control different RAM test features.
  See  section  10.2.1  for  information  on  how  to  set  up  the  interrupt  vector  table  when
using IAR compiler.
2015, Vector Informatik GmbH
Version: 1.08.00
48 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

12  Known Issues / Limitations
1.  Due  to  hardware  limitations  the  feature  CAN  RAM  check  is  not  supported  for  receive
mailboxes (no write access is possible for these objects).
2.  Due to hardware limitations receive FullCANs cannot be processed in interrupt context
and no overruns can be detected for these objects.
3.  With  default  configuration  the  driver  needs  exclusive  write  access  to  all  EI  level
interrupt control registers (ICn) that are related to a CAN interrupt source (see section
7.2.3 and chapter 10 for further information.).
4.  Refer  to  chapter  4  for  restrictions  when  using  the  Sleep/Wakeup  functionality.
Additionally the global stop mode of the RSCAN is not supported.
5.  When using multiple initialization structures no multiple acceptance filter configurations
are  supported  by  the  driver.  The  filter  settings  are  always  derived  from  the  first
structure. Use several structures only to arrange multiple baudrate configurations.
6.  When using the feature Multiple ECU Configurations it is not supported to use a logical
channel in more than one identity. The only exception is the first logical channel which
can be present in any identity if it is also mapped to the physical channel CAN0. This
limitation  does  not  apply  to  the  usage  of  physical  channels:  Every  available  physical
channel can be used in any identity and the same physical channel can be used in as
many identities as needed (if it is referenced by different logical channels).
7.  For  derivatives  that  incorporate  multiple  RSCAN  units  only  the  first  one  (RSCAN0)  is
supported by the driver.

For  latest  information  about  issues  or  limitations  of  the  actually  used  derivative  please
contact the hardware manufacturer.

2015, Vector Informatik GmbH
Version: 1.08.00
49 /50
based on template version 3.2

Vector CAN Driver Technical Reference RH850 RSCAN

13  Contact
Visit our website for more information on

>  News
>  Products
>  Demo software
>  Support
>  Training data
>  Addresses

www.vector.com

2015, Vector Informatik GmbH
Version: 1.08.00
50 /50
based on template version 3.2

Document Outline

Last modified October 12, 2025: Initial commit (1fadfc4)