Synergy Software Package User's Manual
CAN Driver

CAN HAL Module Introduction

The CAN HAL module provides a high-level API for CAN network applications and supports the CAN peripherals available on the Synergy microcontroller hardware. A user-callback function must be defined, which the driver will invoke when transmit, receive or error interrupts are received. The callback returns with a parameter which indicates the channel, mailbox and event.

CAN HAL Module Features

  • Supports both standard (11-bit) and extended (29-bit) messaging formats
  • Support for bit timing configuration as defined in the CAN specification
  • Supports up to 32 transmit or receive mailboxes with standard or extended ID frames
  • Receive mailboxes can be configured to capture either data or remote CAN Frames
  • Receive mailboxes can be configured to receive a range of IDs using mailbox masks
  • Supports a user-callback function when transmit, receive, or error interrupts are received
CAN_BD.png
CAN HAL Module Block Diagram

CAN Hardware support details

The following hardware features are, or are not, supported by SSP for CAN:

Legend:

Symbol Meaning
Available (Tested)
Not Available (Not tested/not functional or both)
N/A Not supported by MCU 
MCU
Group
Programmable
Bit Rate
Support up
to 32
Mailboxes
Mailbox
Normal
Mode
Mailbox
FIFO Mode
Support for
Data Frame
Reception
Support for
Remote
Frame
Reception
S124
S128
S1JA
S3A1
S3A3
S3A6
S3A7
S5D3
S5D5
S5D9
S7G2
MCU
Group
Programmable one-shot
reception
Overwrite
mode
reception
Overrun mode
reception
Support all 8 Acceptance
Masks
Support Masks
independently enabled
or disabled for each Mailbox
S124
S128
S1JA
S3A1
S3A3
S3A6
S3A7
S5D3
S5D5
S5D9
S7G2
MCU
Group
Support for
transmission
request abort
Mode
transition
for bus-off:
ISO11898-1
specification
-compliant
Mode transition
for bus-off:
Automatic invoking of
CAN halt mode on bus-off entry
Mode transition for bus-off: Automatic invoking of CAN halt mode on bus-off end Mode
transition for
bus-off:
Invoking of
CAN halt mode
through software
Mode
transition
for bus-off:
Transition
to error active
state through software.
S124
S128
S1JA
S3A1
S3A3
S3A6
S3A7
S5D3
S5D5
S5D9
S7G2
MCU
Group
Monitoring
of all CAN
bus errors
{Stuff, Form, ACK,
15-bit CRC,
Bit error, ACK Delimiter}
Detection of
all transition
to error states {error warning,
error passive,
bus-off entry, and bus-off Recovery}
Support
Interrupt
Sources
{Receive
FIFO,
Transmit FIFO }
Support
Interrupt
Sources
{Reception
complete.
Transmission
complete,
Error interrupts}
Support
CAN sleep
mode 1
{stop CAN
clock}
Support all 3 software units {Acceptance filter support, Mailbox search support, including receive mailbox search, transmit mailbox search, and message lost Search, Channel search support}
S124
S128
S1JA
S3A1
S3A3
S3A6
S3A7
S5D3
S5D5
S5D9
S7G2
MCU
Group
CAN
Source
Clock: PCLKB
CAN
Source
Clock:
CANMCLK
Support all 3 Test
Modes {Listen-only, Self-Test 1 (external loopback), Self Test
2 (internal loopback)}
Module-stop
Function
Support
Standard
CAN (11 bit)
Support
Extended
CAN (29 bit)
S124 N/A
S128 N/A
S1JA N/A
S3A1
S3A3
S3A6
S3A7
S5D3
S5D5
S5D9
S7G2

CAN HAL Module APIs Overview

The CAN HAL defines APIs for opening, closing, writing (transmitting) and reading (receiving) CAN data; it also provides some additional functions to assist in processing more complex commands. A complete list of the available APIs, an example API call and a short description of each can be found in the following table. A table of status return values follows the API summary table.

CAN HAL Module API Summary

Function Name Example API Call and Description
open g_can0.p_api->open(g_can0.p_ctrl, g_can0.p_cfg)
The open API configures CAN Channel 0. This function must be called before any other CAN functions.
Note: This call is made automatically during system initialization, prior to entering the users thread. Unless the user closes the module, open will not need to be called.
close g_can0.p_api->close(g_can0.p_ctrl)
The close API handles the clean-up of internal driver data.
read g_can0.p_api->read (g_can0.p_ctrl, p_args->mailbox, &receiveFrame)
The read API reads received CAN data.
write g_can0.p_api->write (g_can0.p_ctrl, 0, &transmitFrame)
The write API write data into the CAN transmit frame buffer and send it out.
control g_can0.p_api->control(g_can0.p_ctrl, CAN_COMMAND_MODE_SWITCH, &mode);
withcan_mode_t mode = CAN_MODE_LOOPBACK_INTERNAL;
The control API will be able to change the CAN mode of operation.
infoGet g_can0.p_api->infoGet(g_can0.p_ctrl, p_info)
The infoGet API retrieves the CAN mode of operation.
versionGet g_can0.p_api->versionGet(version)
The versionGet API retrieves the module version information.
Note
For more complete descriptions of operation and definitions for the function data structures, typedefs, defines, API data, API structures, and function variables, review the SSP User's Manual API References for the associated module.

Status Return Values

Name Description
SSP_SUCCESS API Call Successful.
SSP_ERR_INVALID_ARGUMENT Parameter has invalid value.
SSP_ERR_HW_LOCKED Lock already owned by another user.
SSP_ERR_CAN_MODE_SWITCH_FAILED Channel failed to switch modes.
SSP_ERR_CAN_INIT_FAILED Channel failed to initialize.
SSP_ERR_ASSERTION Null pointer presented.
SSP_ERR_NOT_OPEN Port is not open.
SSP_ERR_CAN_DATA_UNAVAILABLE No data available.
SSP_ERR_CAN_TRANSMIT_MAILBOX Mailbox is not setup for receive.
SSP_ERR_CAN_TRANSMIT_NOT_READY Transmit in progress, cannot write data at this time.
SSP_ERR_CAN_RECEIVE_MAILBOX Mailbox is setup for receive and cannot send.
Note
Lower-level drivers may return common error codes. Refer to the SSP User's Manual API References for the associated module for a definition of all relevant status return values.

CAN HAL Module Operational Overview

The CAN HAL module controls the CAN peripherals on Synergy microcontrollers according to the user configuration. The API provides open, close, read, write, control and information functions. The driver allows for bit-timing configuration as defined in the CAN specification; it can be configured for up to 32 transmit or receive mailboxes with standard or extended ID frames. Receive mailboxes can be configured to capture either data or remote CAN frames. The user callback is invoked with the channel, mailbox and event information when a transmit, receive or error interrupt occurs.

Using the CAN IDs and Masks

Each CAN Mailbox configured to receive messages has an ID and Mask set. Incoming messages will be placed in the lowest mailbox where the following is true:

Incoming ID & Mailbox Mask == Mailbox ID & Mailbox Mask

Example 1: A mailbox with an ID of 0x25 and a mask of 0x1FFFFFFF can receive messages with IDs of 0x25.

Example 2: A mailbox with an ID of 0x25 and a mask of 0x1FFFFFF0 can receive messages with IDs of 0x20 through 0x2F.

Using the CAN HAL Module Test Modes

The CAN Module has three test modes, listen only, external loopback and internal loopback.

  • In the listen only mode valid data frames and remote frames can be received. However, only recessive bits can be sent on the CAN bus. The ACK bit, overload flag, and active error flag cannot be sent. Listen only mode can be used for baud rate detection
  • In the external loopback mode the protocol module treats its own transmitted messages as those received by the CAN transceiver and stores them into the receive mailbox. To be independent from external stimulation, the protocol module generates the ACK bit. Connect the CTX and CRX pins to the transceiver.
  • The internal loopback mode is similar to the external loopback mode except the protocol controller performs internal loopback from the internal CTX pin to the internal CRX pin. The input value of the external CRX pin is ignored. The external CTX pin outputs only recessive bits. The CTX and CRX pins are not required to be connected to the CAN bus or any external device.

Changing the CAN HAL Module Operating Modes

The CAN Module can be switched between modes using the can_api_t::control API. Pass CAN_COMMAND_MODE_SWITCH and a pointer to a can_mode_t variable set to the desired mode into the can_api_t::control API.

Mode can_mode_t value Reason for use
Normal CAN_MODE_NORMAL Normal operation mode
Internal Loopback CAN_MODE_LOOPBACK_INTERNAL Internal loopback testing
External Loopback CAN_MODE_LOOPBACK_EXTERNAL External loopback testing
Listen Only CAN_MODE_LISTEN Baud rate detection
Halt CAN_MODE_HALT Mailbox configuration and test mode setting
Sleep CAN_MODE_SLEEP Stops the clock supply to the CAN module reducing current consumption
Exit Sleep CAN_MODE_EXIT_SLEEP Internal use only
Reset CAN_MODE_RESET Communication configuration

Example usage:

    /* Switch the device into internal loopback mode for easy testing. */
    ssp_err_t error = g_can0.p_api->control(g_can0.p_ctrl, CAN_COMMAND_MODE_SWITCH, &mode);

CAN HAL Module Important Operational Notes and Limitations

CAN HAL Module Operational Notes

  • The user application must start the main-clock oscillator (CANMCLK or XTAL) at run-time using the CGC Interface if it has not already started (for example, if it is not used as the MCU clock source.)
  • For S7, S5, S3 and S1 MCUs, the following clock restriction must be satisfied for the CAN HAL module when the clock source is the main-clock oscillator (CANMCLK).fPCLKB >= fCANCLK (XTAL / Baud Rate Prescaler)
  • For S7, S5 and S3 MCUs, the source of the peripheral module clocks must be PLL for the CAN HAL module when the clock source is PCLKB.
  • For S3 MCUs, the clock frequency ratio of PCLKA and PCLKB must be 2:1 when using the CAN HAL module. Operation is not guaranteed for other settings.
  • For S1 MCUs, the clock frequency ratio of ICLK and PCLKB must be 2:1 when using the CAN HAL module. Operation is not guaranteed for other settings.
  • SJW (Synchronization Jump Width) is often given by the bus administrator. Select 1 <= SJW <= 4.
  • Time segment and SJW settings must adhere to the following constraints: TS1 > TS2 >= SJW.

CAN HAL Module Limitations

  • Refer to the latest SSP Release Notes for any additional operational limitations for this module.

Including the CAN HAL Module in an Application

This section describes how to include the CAN HAL Module in an application using the SSP configurator.

Note
This section assumes you are familiar with creating a project, adding threads, adding a stack to a thread and configuring a block within the stack. If you are unfamiliar with any of these items, refer to the first few chapters of the SSP User's Manual to learn how to manage each of these important steps in creating SSP-based applications.

To add the CAN Driver to an application, simply add it to a thread using the stacks selection sequence given in the following table. (The default name for the CAN Driver is g_can0. This name can be changed in the associated Properties window.)

CAN HAL Module Selection Sequence

Resource ISDE Tab Stacks Selection Sequence
g_can0 CAN Driver on r_can Threads New Stack> Driver> Connectivity> CAN Driver on r_can

When the CAN Driver on r_can is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.

CAN_MS.png
CAN HAL Module Stack

Configuring the CAN HAL Module

The CAN HAL Module must be configured by the user for the desired operation. The available configuration settings and defaults for all the user-accessible properties are given in the properties tab within the SSP configurator and are shown in the following tables for easy reference. Only properties that can be changed without causing conflicts are available for modification. Other properties are locked and not available for changes and are identified with a lock icon for the locked property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous manual approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP Configurator and are shown in the following tables for easy reference.

Note
You may want to open your ISDE, create the module and explore the property settings in parallel with looking over the following configuration table settings. This will help orient you and can be a useful 'hands-on' approach to learning the ins and outs of developing with SSP.

Configuration Settings for the CAN HAL Module on r_can

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP
Enable or disable parameter error checking.
Name g_can0 Specify CAN Module instance name.
Channel 0 Specify if the CAN channel is to use 0 or 1 (S7G2 only).
Baud Rate Prescaler 5 Specify the baud rate prescaler (0-1023). See CAN Bit Rate Calculation.
Time Segment 1 4 Time Quanta thru 16 Time Quanta

Default: 15 Time Quanta
Specify the time segment 1 value (4-16). See CAN Bit Rate Calculation.
Time Segment 2 2 Time Quanta thru 8 Time Quanta

Default: 8 Time Quanta
Specify the time segment 2 value (2-8). See CAN Bit Rate Calculation.
Synchronization Jump Width 1 Time Quanta thru 4 Time Quanta

Default: 2 Time Quanta
Specify the Synchronization Jump Width value (1-4). See CAN Bit Rate Calculation.
Clock Source PCLKB (S7G2 and S3A7 only), CAN MCLK

Default: CAN MCLK
CAN clock source, CANMCLK or PCLKB (S7G2 and S3A7 only).
Callback NULL A user callback function can be registered in open. If this callback function is provided, it is called from the interrupt service routine (ISR) each time any interrupt occurs.  

Warning: Since the callback is called from an ISR, care should be taken not to use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system.
Overwrite/Overrun Mode Overwrite Mode, Overrun Mode

Default: Overwrite Mode
Select whether receive mailbox will be overwritten or overrun if data is not read in time.
Standard or Extended ID Mode Standard ID Mode, Extended ID Mode

Default: Standard ID Mode
Select whether the driver will be using CAN standard or extended IDs.
Number of Mailboxes 4, 8, 16, 32 Mailboxes

Default: 32 Mailboxes
Select 4, 8, 16 or 32 mailboxes.
Mailbox 0-31 ID 0-31 Select the receive ID for mailbox 0, between 0 and 0x7ff when using standard IDs, between 0 and 0x1FFFFFFF when using extended IDs. Value is not used when the mailbox is set as transmit type.
Mailbox 0 Type Receive Mailbox, Transmit Mailbox

Default: Transmit Mailbox
Select whether the mailbox is used for receive or transmit.
Mailbox 1-31 Type Receive Mailbox, Transmit Mailbox

Default: Receive Mailbox
Select whether the mailbox is used for receive or transmit.
Mailbox 0 Frame Type Data Mailbox, Remote Mailbox

Default: Remote Mailbox
Select whether the mailbox is used to capture data frames or remote frames (receive only).
Mailbox 1-31 Frame Type Data Mailbox, Remote Mailbox

Default: Data Mailbox
Select whether the mailbox is used to capture data frames or remote frames (receive only).
Mailbox 0-3 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 0-3. See Setting the Mailbox Group Masks.
Mailbox 4-7 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 4-7. See Setting the Mailbox Group Masks.
Mailbox 8-11 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 8-11. See Setting the Mailbox Group Masks.
Mailbox 12-15 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 12-15. See Setting the Mailbox Group Masks.
Mailbox 16-19 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 16-19. See Setting the Mailbox Group Masks.
Mailbox 20-23 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 20-23. See Setting the Mailbox Group Masks.
Mailbox 24-27 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 24-27. See Setting the Mailbox Group Masks.
Mailbox 28-31 Group Mask 0x1FFFFFFF Select the Mask for mailboxes 28-31. See Setting the Mailbox Group Masks.
Error Interrupt Priority Priority 0 (highest), Priority 1:14, Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12
Specify the error interrupt priority 0-15 (required).
Receive Mailbox Interrupt Priority Priority 0 (highest), Priority 1:14, Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12
Specify the receive interrupt priority 0-15 (required).
Transmit Mailbox Interrupt Priority Priority 0 (highest), Priority 1:14, Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12
Specify the transmit interrupt priority 0-15 (required).
Note
The example settings and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

CAN HAL Module Clock Configuration

The CAN peripheral uses the CANMCLK (main-clock oscillator) or PCLKB (S7G2, S5D9, S5D5, S3A7 and S3A7 only) as its clock source (fCAN, CAN System Clock.) Using the PCLKB with the default of 60 MHz and the Synergy default, (S7G2 DK) CAN configuration will provide a CAN bit rate of 500 Kbit.

To set the PCLKB frequency, use the clock configurator in e2 studio.  To change the clock frequency at run-time, use the CGC Interface. Refer to the CGC module guide for more information on configuring clocks.

CAN HAL Module Pin Configuration

The CAN peripheral module uses the pins on the MCU to communicate to external devices connected on the CAN bus. Under Peripherals, select CAN and then CAN0 for channel 0 or CAN1 (S7G2 and S3A7 only) for channel 1. The operation mode for the channel must be enabled and the CRXn and CTXn pins must be selected to match your PC board layout. The pin configurator sets appropriate CAN pin configuration in the pin_cfg field for the associated pin. The following table illustrates the method for selecting the pins within the SSP configuration window and the subsequent table illustrates an example selection for the CAN pins.

Note
The operation mode selection determines what peripheral signals are available and what MCU pins are required.

Pin Selection for the CAN HAL Module on r_ can

Resource ISDE Tab Pin selection Sequence
CAN Pins Select Peripherals> CAN> CAN0
Note
The selection sequence assumes CAN0 is the desired hardware target for the driver.

Pin Configuration Settings for the CAN HAL Module on r_ can

Property Value Description
Operation Mode Disabled, Enabled Enable the mode to use CAN0.
CRX None, P202, P402
Default: P402
CAN0_CRX0.
CTX None, P203 P401
Default: P401
CAN0_CTX0.
Note
The example settings are for a project using the Synergy S7G2 MCU Group and the SK-S7G2 Kit. Other Synergy MCUs and Synergy Kits may have different available pin configuration settings.

CAN Bit Rate Calculation

A time quanta (Tq) is one bit-time of the CAN communication clock, fCANCLK. This is not the CAN bit-time but the internal clock period of the CAN peripheral. The frequency is determined by the baud-rate prescaler value and the CAN source clock, fCAN (CANMCLK or PCLKB). One bit-time is divided into a number of time quanta, Tqtot. One time quantum is equal to the period of the fCANCLK. Each bitrate register is then given a certain number of Tq of the total of Tq that make up one CAN-bit period. The default ISDE bitrate setting (S7G2 DK template) is 500 Kbps for a fCAN at 60 MHz (using PCLKB.)

The formulas to calculate the bitrate register settings are as follows:

fCAN = (fPCLKB or fCANMCLK)

The baud-rate prescaler scales the CAN peripheral clock down.

fCANCLK = fCAN/ Baud Rate Prescaler = 60 MHz (default)/ 5(default) = 12 MHz

One time quantum is one clock period of the CAN clock.

Tqtot =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) = 15 + 8 + 1 = 24 (default)

The bitrate is then:

Bitrate = fCANCLK/Tqtot = 12 MHz / 24 = 500 Kbps

Important notes:

  • The user application must start the main-clock oscillator (CANMCLK or XTAL) at run-time using the CGC Interface if it is not already started (for example, if it is not used as the MCU clock source.)
  • For S7G2, S3A7 and S124 MCUs, the following clock restriction must be satisfied for the CAN module when the clock source is the main-clock oscillator (CANMCLK): fPCLKB >= fCANMCLK
  • For S7G2 and S3A7 MCUs, the source of the peripheral module clocks must be PLL for the CAN HAL module when the clock source is PCLKB.
  • For S3A7 MCUs, the clock frequency ratio, PCLKA and PCLKB must be 2:1 when using the CAN HAL module. Operation is not guaranteed for other settings.
  • For S124 MCUs, the clock frequency ratio of ICLK and PCLKB must be 2:1 when using the CAN HAL module. Operation is not guaranteed for other settings.
  • SJW (Synchronization Jump Width) is often given by the bus administrator. Select 1 <= SJW <= 4.

Configurator sample values for different CAN bit-rate

fCAN (either PCLKB or CAN MCLK) Baud Rate Prescalar fCANCLK = fCAN / Baud Rate Prescalar Time Segment 1 (TSEG1) Time Segment 2 (TSEG2) Synchronization Jump Width (SS) Tqtot = TSEG1 + TSEG2 +SS Bitrate = fCA NCLK / Tqtot
240 10 24 15 8 1 24 1 Mbps
60 5 12 15 8 1 24 500 kbps
240 48 5 16 2 2 20 250 kbps
240 96 2.5 16 2 2 20 125 kbps

Setting the Mailbox Group Masks

There are 8 mailbox group-masks, one for each group of 4 mailboxes. These masks allow the mailboxes to be configured to receive more than one ID. If the mask is all ones (0x7ff for standard IDs or 0x1FFFFFFF for extended ID) the mailboxes within the group do not mask any bits of the ID, requiring all bits of the mailbox ID to match the mailbox ID before a message is captured. If any bits of the mask are set to zero, those bits will not be necessary to match the same bits of the mailbox ID. For example, if Mailbox ID 1 is set to 0x7ff and Mailbox 0-3 Group Mask is set to 0x7ff, mailbox 1 will only capture messages with the ID of 0x7ff. If the mailbox 0-3 group mask is set to 0x7fe, mailbox 1 will still capture messages with IDs of 0x7f but will also capture messages with IDs of 0x7fe.

Using the CAN HAL Module in an Application

A CAN application requires a minimum of two nodes to demonstrate CAN communication. One node can be a transmitter, while the other can be a receiver (or both can behave as transmitter and receiver.)

The typical steps in using the CAN HAL Module in an application are:

  1. Initialize the CAN HAL Module using the can_api_t::open API.
  2. (Optional) Enter internal loopback or external loopback test modes using can_api_t::control API.
  3. (Optional) Information about the module status, including bit rate, can be retrieved using the can_api_t::infoGet API.
  4. To transmit a message:
    1. Create and configure the CAN frame ensuring correct ID and frame type.
    2. Write the CAN frame to a mailbox configured in transmit mode using the can_api_t::write API.
  5. To receive a message:
    1. Read from a mailbox that has received a frame using the can_api_t::read API.
  6. Close the CAN HAL Module using the can_api_t::close API (if needed).

These common steps are illustrated in a typical operational flow diagram in the following figure:

CAN_TA.png
Flow Diagram of a Typical CAN HAL Module Application