Can User Guide


This document details AUTOSAR BSW CAN module implementation

  • Supported AUTOSAR Release : 4.3.1
  • Supported Configuration Variants : Post-build, Pre-Compile
  • Vendor ID : CAN_VENDOR_ID (44)
  • Module ID : CAN_MODULE_ID (80)

The CAN driver provides services for basic transmission and reception of CAN frames in both interrupt and polling mode. These components can be used by an application.

CAN Driver Architecture/Design

Please refer the CAN design, which is included as part of release (Can Design Document)

Functional Description

The CAN module initializes and controls the internal CAN Controllers of the microcontroller. It provides services to write, read, and configure mailboxes of the Can controllers

Programming of clock source for the can, is beyond the scope of this document. The driver expects user of this module has programmed required clock source.

Back To Top

CAN Instance ID mapping and ISR mapping

16 CAN instances are supported on J7ES and 20 on J7VCL/J7AEP/J7AHP by this driver implementation (2 instances in MCU domain and rest in MAIN domain). The following table lists the mapping between instance of can and controllerId of the configurator

CAN Instance Id Can Instance Associated ISR
0 MCU CAN 0 Can_0_Int0ISR
1 MCU CAN 1 Can_1_Int0ISR
2 MAIN CAN 0 Can_2_Int0ISR
3 MAIN CAN 1 Can_3_Int0ISR
4 MAIN CAN 2 Can_4_Int0ISR
5 MAIN CAN 3 Can_5_Int0ISR
6 MAIN CAN 4 Can_6_Int0ISR
7 MAIN CAN 5 Can_7_Int0ISR
8 MAIN CAN 6 Can_8_Int0ISR
9 MAIN CAN 7 Can_9_Int0ISR
10 MAIN CAN 8 Can_10_Int0ISR
11 MAIN CAN 9 Can_11_Int0ISR
12 MAIN CAN 10 Can_12_Int0ISR
13 MAIN CAN 11 Can_13_Int0ISR
14 MAIN CAN 12 Can_14_Int0ISR
15 MAIN CAN 13 Can_15_Int0ISR
16 MAIN CAN 14 Can_16_Int0ISR (J7VCL/J7AEP/J7AHP)
17 MAIN CAN 15 Can_17_Int0ISR (J7VCL/J7AEP/J7AHP)
18 MAIN CAN 16 Can_18_Int0ISR (J7VCL/J7AEP/J7AHP)
19 MAIN CAN 17 Can_19_Int0ISR (J7VCL/J7AEP/J7AHP)

Back To Top


The CAN Driver implementation supports multiple configuration variants (refer section Introduction), the driver expects generated Can_Cfg.h to be present as (File Structure). Please refer (Build) to specify path to generated configuration. The associated can configuration generated files Can_Cfg.c and Can_PBcfg.c to be present as show (File Structure)

NOTE: Always use configurator tool for MCAL configuration generation.

The following section details on the un-supported features and additional features added.

Variance / Deviation from the specification


Wakeup functionality is not supported, this configuration parameter will NOT enable Can Wakeup Functionality.


Wakeup functionality is not supported, this configuration parameter will NOT enable Can Wakeup Functionality.


ICOM feature is not supported and CanIcomGeneral configuration parameters are not supported.


TTCAN feature is not supported and hence CanIfSupportTTCAN parameter is not supported.


The optional trigger-transmit API's are not supported in this release.


The optional configuration parameter CanLPduReceiveCalloutFunction is not supported in this release.


Can_ChangeBaudrate API's cannot be turned OFF via CAN_CHANGE_BAUDRATE_API.


SWS_Can_00442 states that The API name of Can_MainFunction_Read() shall obey the following pattern:

  • Can_MainFunction_Read_0()
  • Can_MainFunction_Read_1() ... and so on, if more than one period (see ECUC_Can_00358) is supported. It's not clear on the expected use. Also, specification say's we can have only one poll function for read and write. Hence this requirement is not implemented.

Similarly same w.r.o requirement SWS_Can_00441.


In function Can_SetControllerMode if maximum time CanTimeoutDuration is elapsed, DEM error CAN_E_HARDWARE_ERROR is reported.(Refer SWS_Can_00372 for details).


Can_SetControllerMode(CAN_T_WAKEUP) will not wait for a "limited time" and will update the state to STOPPED immediately. (Refer SWS_Can_00268 for details).

Implementation Specific Configurations

This driver implementation introduces below listed configurable options

Please refer the CAN design section NON Standard configurable parameters (Refer to Design Document provided in CSP), which is included as part of release (Can Design Document)

Back To Top

Non Standard Service APIs


As noted from the previous MCAL implementation, some of the critical configuration registers could potentially be corrupted by other entities (s/w or h/w). One of the recommended detection methods would be to periodically read-back the configuration and confirm configuration is consistent. The service API defined below shall be implemented to enable this detection

Description Comments
Service Name Can_RegisterReadback Can potentially be turned OFF (Refer to Design Document provided in CSP)
Syntax uint32 Can_RegisterReadback ( Can_HWUnitType HWUnit, P2VAR(Can_RegisterReadbackType, AUTOMATIC, CAN_APPL_DATA) RegRbPtr) E_OK: Register read back has been done, E_NOT_OK: Register read back failed
Service ID NA
Sync / Async Sync
Reentrancy Reentrant
Parameter in HWUnit CAN Hardware microcontroller peripheral unit ID. If this is invalid, then the API will return E_NOT_OK.
Parameters out RegRbPtr - Pointer to where to store the readback values. If this pointer is NULL_PTR, then the API will return E_NOT_OK.
Return Value Std_ReturnType E_OK, E_NOT_OK


This service will enable CAN loopback mode.

Description Comments
Service Name Can_TestLoopBackModeEnable Can potentially be turned OFF (Refer to Design Document provided in CSP)
Syntax uint32 Can_TestLoopBackModeEnable(uint8 Controller, uint8 Mode)
Service ID 18
Sync / Async Sync
Reentrancy Reentrant
Parameter in Controller CAN Controller to enable loopback mode.
Parameter in Mode Mode : 0 - Digital Loopback, 1 - Analog Loopback
Return Value Std_ReturnType E_OK : Loopback enable successfully E_NOT_OK : Loopback enable failed

Back To Top

Interrupt Configuration

The Driver doesn’t register any interrupt service routine(ISR), it’s expected that consumer of this driver registers the required interrupt handler.

For every CAN instance an ISR needs to be registered. The Interrupt number associated with instance of the CAN is detailed in TRM. Please refer CanApp_InterruptConfig () in CAN demo application.

Refer section (CAN Instance ID mapping and ISR mapping), for association between instance ID and ISR

Back To Top


The driver doesn't configure the functional clock and power for the CAN modules. It's expected that secondary boot loader(SBL) power-up the required modules. Please refer SBL documentation.

Back To Top

Build and Running the Application

Please follow steps detailed in section (Build) to build library or example

Back To Top

Steps to run example application

Please follow steps detailed in section (Build) to build example

Back To Top

Memory Mapping

Various objects of this implementation (e.g. variables, functions, constants) are defined under different sections. The linker command file at (Examples Linker File (Select memory location to hold example binary)) defines separate section for these objects. When the driver is integrated, its expected that these sections are created and placed in appropriate memory locations. (Locations of these objects depend on the system design and performance needs)


NOTE: It is adviced to use of MPU at the OS level verification through the use of System level Testing. Check Autosar recommendation memory segment placements are followed.

Back To Top


This driver implementation has been validated with cache enabled. For optimal performance it’s recommended to place (Memory Mapping) sections in cache enabled memory area.

Back To Top

Dependencies on SW Modules

NOTE: Pin Muxing should be initialized before initializing the Can module.


This implementation depends on the DET in order to report development errors and can be turned OFF. Refer section (Development Error Reporting) for detailed error codes.

Back To Top


This implementation requires one level of exclusive access to guard critical sections. Invokes SchM_Enter_Can_CAN_EXCLUSIVE_AREA_0 (), SchM_Exit_Can_CAN_EXCLUSIVE_AREA_0 () to enter critical section and exit.

In the example implementation (File Structure SchM_Can.c) , all the interrupts on CPU are disabled. However, disabling of the enabled CAN interrupt should suffice.

Back To Top

File Structure

Detailed Directory Structure
  1. Driver implemented by : Can.h, Can_Irq.h, Can.c, Can_Priv.c,Can_Mcan.c Can_Irq.c and Can_Priv.h
  2. Example Configuration by : Can_Cfg.h, Can_Cfg.c and Can_PBcfg.c
  3. Example Application by : CanApp.c

Back To Top

Error Handling

NOTE: Interrupts required for error detection shall be enabled all the time.

Development Error Reporting

Development errors are reported to the DET using the service Det_ReportError(), when enabled. The driver interface (Can.h File Structure) lists the SID

Back To Top

Error codes

Development Error

Back To Top

Production Code Error Reporting

Production error are reported to DEM via the service DEM_ReportErrorStatus(). In addition to standard errors, this implementation reports "CAN_E_HARDWARE_ERROR" when CAN hardware register read/write fails.

Back To Top

API Description

The AUTOSAR BSW Can Driver specification details the APIs required for Can Driver. Please refer to (Refer to Design Document provided in CSP) for detailed API description. Also refer to (Non Standard Service APIs) for non-standard APIs which are included in this implemented.

Refer API Documentation for details Back To Top

Example Application

The example application demonstrate use of CAN module, the list below identifies key steps performed the example. The configuration file is present at (File Structure)

  • Initializes “Result Status Flag”
  • CanApp_Startup ()
    • Builds interrupt list and registers ISR for enabled CAN instances
  • CanApp_PowerAndClkSrc ()
    • Dummy function for now.
  • CanApp_PlatformInit ()
    • Pinmux configuration required for internal loopback testing mode
      • Write 0x08050007 to specific pad config control register for the MCAN trasceiver pin. Further details can be found under Device Configuration > Control Module in TRM.
      • Confirm the CAN transceiver is enabled by performing a read and compare on the same pin.
    • Enables CAN Transceiver connected to CAN instances.Please note that for internal loopback testing this is not applicable.
  • CanApp_LoopbackTest ()
    • For each enabled instance
      • Initialize CAN hardware
      • Setup PDU info to tranmist
      • Set CAN controller mode to START
      • Enable loopback mode
      • Trigger CAN transmission
      • Wait for transmission completion
      • Check for Tx and Rx confirmation success
      • Set CAN controller mode to STOP
      • Disable loopback mode
      • Compare received message Id and Data with PDU Info
  • Checks for error status, stack corruption and prints result

Back To Top

Example Log

    CAN_APP: Sample Application - STARTS !!!
    CAN_APP: Variant - Pre Compile being used !!!
    CAN_APP: Successfully Enabled CAN Transceiver Main Domain Inst 4,9,11!!!
    CAN_APP: Successfully Enabled CAN Transceiver MCU MCAN0!!!
    CAN_APP: Successfully Enabled CAN Transceiver MCU MCAN1!!!
    CAN_APP: Message Id Received a0 Message Length is 64     
    CAN_APP: Can Controller Instance MCAN 0 Internal LoopBack Mode Test Passed
    CAN_APP: Message Id Received 800000b0 Message Length is 64   
    CAN_APP: Can Controller Instance MCAN 1 Internal LoopBack Mode Test Passed
    CAN_APP: Message Id Received c0 Message Length is 64     
    CAN_APP: Can Controller Instance MCAN 2 Internal LoopBack Mode Test Passed
    CAN Stack Usage: 856 bytes
    CAN_APP: CAN Test Passed!!!

Back To Top


Back To Top

Document Revision History

Revision Date Author Description Status
0.1 15 Oct 2018 Sunil M S First version Pending Review
0.2 22 Oct 2018 Sunil M S Addressed review comments Approved
0.3 27 Dec 2018 Vibha Pant Pin Mux Information added Approved
0.4 16 Oct 2018 Sujith S Added Logs from J721E testing Approved
0.5 02 Nov 2020 Nikki S J7200 updated Approved
0.6 17 Mar 2022 Rohit T Removed J721E & J7200 specific contents Approved
0.7 08 dec 2022 Subham swain J7AEP updated Approved
0.8 07 Feb Subham swain J7AHP updated Approved