4.2. CAN¶
4.2.1. About This Document¶
Document Title |
User Guide of MCAL CAN Driver |
Document Version |
Version 1.6 |
Company |
Texas Instruments |
Document Name |
CAN User Guide |
4.2.2. Revision History¶
Version # |
Date |
Revision History |
Status |
|---|---|---|---|
Version 1.0 |
28-Mar-2022 |
Initial Release. |
Approved |
Version 1.1 |
25 April 2022 |
Tested MCAN1 physically on CAN Analyzer and verified CAN frames, |
Approved |
Version 1.2 |
05 Aug 2022 |
Resolved CANFD Related Bugs. |
Approved |
Version 1.3 |
23 Dec 2022 |
CAN Example application testing procedure updated. |
Approved |
Version 1.4 |
6 May 2023 |
Can supported features are updated. |
Approved |
Version 1.5 |
12 Jun 2023 |
Updated as per HTML format. |
Approved |
Version 1.6 |
25 Aug 2023 |
Document release version column removed |
Approved |
4.2.3. Table of contents¶
4.2.4. Acronyms and Definitions¶
Acronyms and Definitions Used are presented in below table.
Acronyms |
Descriptions |
|---|---|
BSW |
Basic Software |
DET |
Default Error Tracer |
CAN |
Control Area Network |
MCU |
Micro Controller Unit |
OS |
Operating System |
4.2.5. Functional Overview¶
4.2.5.1. Brief Overview¶
This document describes the functionality, API and configuration of the AUTOSAR BSW module CAN.
Supported AUTOSAR Release |
4.3.1 |
Supported Configuration Variants |
Pre-Compile, Post-build |
Vendor ID |
CAN_VENDOR_ID (44) |
Module ID |
CAN_MODULE_ID (80) |
Supported Platform |
AM263x |
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.
4.2.5.1.1. Initialization¶
Can_Init () must be called to initialize the CAN driver at power on and sets controller independent init values. This will also set the controllers to CAN_CS_STOPPED.
4.2.5.1.2. States¶
There are 4 states in which the CAN hardware/driver can be:
CAN_CS_UNINT: This is the state when the Hardware is just started.
CAN_CS_STOPPED: This is the state in which Hardware is in when after the initialization routine is called. CAN controller be fully initialized but does not participate in the bus transactions.
CAN_CS_STARTED: This is the state in which hardware is in when it is fully operational i.e.., it is sending and receive messages from the bus on CAN network.
CAN_CS_SLEEP: This is the state in which the hardware is in when the controller is sleeping. Changing the mode via Can_SetControllerMode ().
Following modes changes are supported:
CAN_CS_STARTED
CAN_CS_STOPPED
CAN_CS_SLEEP
The figure below taken from the AUTOSAR specification shows the state transitions for different function calls and events:
Fig1: CAN channel states and state transitions
4.2.5.1.3. CAN operating modes¶
The CAN module has a very simple state machine, with the two states CAN_UNINIT and CAN_READY. After power-up/reset, the CAN module shall be in the state CAN_UNINIT.
Fig2: CAN driver modes
4.2.5.2. Supported and Not Supported Features¶
IP Supported Features |
AUTOSAR Supported Features |
Not Supported Features |
|---|---|---|
Conforms with ISO 11898-1:2015. |
4 CAN Controllers for AM263x |
Register Readback for MCAN controller |
Full CAN FD support (up to 64 data bytes). |
Supports transmission and reception of Classic. |
Support for pretend networking |
Up to 32 dedicated Transmit Buffers. |
frames through CAN (CAN FD Controller). |
CAN Wake mode is not supported. |
Configurable Transmit FIFO, up to 32 elements. |
Initialization of CAN controller HW. |
|
Configurable Transmit Queue, up to 32 elements. |
Transmitting of CAN Frames and confirmation. |
|
Up to 64 dedicated Receive Buffers. |
Reception of the CAN Frames. |
|
Two configurable Receive FIFOs, up to 64 elements each. |
Polling modes for Read / Write / BusOff confirmations. |
|
Up to 128 filter elements. |
Mailbox objects – Full and Basic filters for Rx. |
|
Internal Loopback mode for self-test. |
Use of OS Counter to check for timeouts. |
|
Maskable interrupts, two interrupt lines. |
Mixed Mode Operation. |
|
Parity/ECC support - Message RAM single error correction and double error detection (SECDED) mechanism. |
Triggered transmission API. |
|
Timestamp Counter. |
LPDU Callback function. |
4.2.5.3. Assumptions¶
None
4.2.5.4. Limitations¶
CAN Wake mode is not supported.
4.2.5.5. Design overview¶
Please refer SITARA MCU MCAL Architecture Document and MCAL: CAN Detailed Design Document provided as part of CSP.
4.2.5.6. File Structure¶
Static source C Files are defined below in the table.
Static source C Files |
Description |
|---|---|
Can.h |
Contains the API’s of the CAN driver to be used by upper layers |
Can_Priv.h |
Contains data structures and Internal function declarations |
Can_Irq.h |
Contains ISR function declaration |
mcan.h |
Contains hardware function definitions |
Can.c |
Implementation of the API’s for CAN driver |
Can_Priv.c |
Contains Internal Functions Definitions |
Can_Irq.c |
Contains ISR function definitions |
Can_Mcan.c |
Contains Internal Functions Definitions |
mcan.c |
Contains hardware Functions Definitions |
Plugin files are defined below in the table.
Plugin Files |
Descriptions |
|---|---|
Can_Cfg.h |
Contains the Precompile switches, Macros for CAN controllers, Hardware Objects etc. |
Can_PBcfg.c |
Contains all controllers Post-Build Configuration parameters |
Can_Cfg.c |
Contains all controllers Pre-Compile Configuration parameters |
The below diagram shows the files structure for the CAN driver.
Fig3: CAN header file include structure
4.2.6. Deviations to requirements (Requirement Traceability)¶
4.2.6.1. Module Requirements¶
Please refer Software Product Specification document provided as part of CSP.
4.2.6.2. Deviation of requirements against AUTOSAR specification requirements¶
Will be updated in future release
4.2.7. Integration Details¶
4.2.7.1. Dependency on Other Software Modules¶
4.2.7.1.1. MCU¶
The CAN Modules expects the MCU modules to enable the MCAN controller. The Clock configuration should be configured in CAN module to select the correct clock source in the parameter “ CanCpuClockRef ” ,
Fig4: Clock Reference in MCU module.
4.2.7.1.2. Port¶
The CAN Modules expects that pinmux is set correctly to configure the MCAN TX/RX pins for CAN mode. This is done by the PORT driver.
4.2.7.1.3. OS¶
An operating system can be used for task scheduling, interrupt handling, global suspend and restore of interrupts and creating of the Interrupt Vector Table. The CAN module may use AUTOSAR OS to suspend and restore global interrupts.
4.2.7.1.4. Error Handling module¶
4.2.7.1.4.1. DET¶
The CAN module depends on the DET (by default) to report development errors. Detection and reporting of development errors can be enabled or disabled by the switch CAN_DEV_ERROR_DETECT = STD_ON in Can_Cfg.h. The DET can be replaced optionally by an equivalent component which is responsible to recognize development errors, if no DET component is available.
AUTOSAR requires that API functions shall check the validity of their respective parameters. These checks are for development error reporting and can be enabled or disabled.
Type of Error |
Relevance |
Related Error Code |
Value |
|---|---|---|---|
API Service called with wrong parameter |
Development |
CAN_E_PARAM_POINTER |
0x01 |
API Service called with wrong parameter |
Development |
CAN_E_PARAM_HANDLE |
0x02 |
API Service called with wrong parameter |
Development |
CAN_E_PARAM_DATA_LENGTH |
0x03 |
API Service called with wrong parameter |
Development |
CAN_E_PARAM_CONTROLLER |
0x04 |
API Service used without initialization |
Development |
CAN_E_UNINIT |
0x05 |
Invalid transition for the current mode |
Development |
CAN_E_TRANSITION |
0x06 |
Parameter Baudrate has an invalid value |
Development |
CAN_E_PARAM_BAUDRATE |
0x07 |
Invalid ICOM Configuration Id |
Development |
CAN_E_ICOM_CONFIG_INVALID |
0x08 |
Invalid configuration set selection |
Development |
CAN_E_INIT_FAILED |
0x09 |
4.2.7.1.4.2. Runtime Errors¶
Type of Error |
Relevance |
Related Error Code |
Value |
|---|---|---|---|
Received CAN message is lost |
Runtime |
CAN_E_DATALOST |
0x01 |
4.2.7.1.4.3. DEM¶
By default, production code related errors are reported to the DEM using the service DEM_ReportErrorStatus().
The errors reported to DEM are described in the following table:
Error Code |
Description |
|
|---|---|---|
Assigned by DEM |
CAN_E_HARDWARE_ERROR |
This error is raised when CAN register setting timeout occurs. |
4.2.7.1.5. Callback Notification¶
At its configurable interfaces the CAN defines notifications that can be mapped to callback functions provided by other modules. The mapping is not statically defined by the CAN but can be performed at configuration time. The function prototypes that can be used for the configuration have to match the appropriate function prototype signatures, which are described in the following. Can_ErrorNotification: This is of type Can_ErrNotifyType which is defined in Can.h file. This is called to report back the ECC error status to the application when ECC error interrupt happens.
4.2.7.2. Hardware - Software - ISR API name mapping¶
Two interrupt routines are provided by the CAN driver. The ISR’s are in the file Can_Irq.c User might edit it for adapting for the suitable OS. The current support is for the NON-OS Interrupts structure. CAN interrupts are hooked up on the Interrupt 0 line (IE0).
Following are the CAN controllers, its respective ISRs for each CAN Controller in AM263x:
Can Controllers |
ISR Routines |
|
|---|---|---|
MCAN0 |
Can_0_Int0ISR() |
|
MCAN0 Error |
Can_0_Int1ISR() |
|
MCAN1 |
Can_1_Int0ISR() |
|
MCAN1 Error |
Can_1_Int1ISR() |
|
MCAN2 |
Can_2_Int0ISR() |
|
MCAN2 Error |
Can_2_Int1ISR() |
|
MCAN3 |
Can_3_Int0ISR() |
|
MCAN3 Error |
Can_3_Int1ISR() |
|
Can_0_Int0ISR For AM263x device, this ISR is called on detection of an event on interrupt line 0 for the MCAN0/MCANA controller. Transmission and reception related events including error events and ECC error events are managed in this ISR.
Can_0_Int1ISR For AM263x device, This function manages the ECC related events for MCAN0/MCANA module. The ECC events for MCAN1 can only be configured and detected via ESM module. So, for detecting the ECC errors for the MCAN0/MCANA module, the application needs to register and configure the ESM to generate interrupt for ECC Errors. This function can then be called to manage the ECC related events. Note: MCAN0/MCANA Interrupt line 1 can only be used for ECC and is not supported for normal interrupt functionality in the configurator
Can_1_Int0ISR For AM263x device, This ISR is called on detection of an event on interrupt line 0 of the MCAN1/MCANB controller. Transmission and reception related events including error events are managed in this ISR.
Can_1_Int1ISR For AM263x device, This function manages the ECC related events for MCAN1/MCANB module. The ECC events for MCAN can only be configured and detected via ESM module. So, for detecting the ECC errors for the MCAN module, the application needs to register and configure the ESM to generate interrupt for ECC Errors. This function can then be called to manage the ECC related events. Note: MCAN1/MCANB Interrupt line 1 can only be used for ECC and is not supported for normal interrupt functionality in the configurator
Can_2_Int0ISR For AM263x device, This ISR is called on detection of an event on interrupt line 0 of the MCAN2 controller. Transmission and reception related events including error events are managed in this ISR.
Can_2_Int1ISR_Fun For AM263x device, This function manages the ECC related events for MCAN2 module. The ECC events for MCAN can only be configured and detected via ESM module. So, for detecting the ECC errors for the MCAN module, the application needs to register and configure the ESM to generate interrupt for ECC Errors (for MCAN module). This function can then be called to manage the ECC related events. Note: MCAN2 Interrupt line 1 can only be used for ECC and is not supported for normal interrupt functionality in the configurator
Can_3_Int0ISR For AM263x device, This ISR is called on detection of an event on interrupt line 0 of the MCAN3 controller. Transmission and reception related events including error events are managed in this ISR.
Can_3_Int1ISR_Fun For AM263x device, This function manages the ECC related events for MCAN3 module. The ECC events for MCAN can only be configured and detected via ESM module. So, for detecting the ECC errors for the MCAN module, the application needs to register and configure the ESM to generate interrupt for ECC Errors (for MCAN module). This function can then be called to manage the ECC related events. Note: MCAN3 Interrupt line 1 can only be used for ECC and is not supported for normal interrupt functionality in the configurator
4.2.7.3. Scheduling Strategy¶
4.2.7.3.1. SchM¶
Beside the OS the BSW Scheduler provides functions that module CAN calls at begin and end of critical sections. The BSW scheduler can also call CAN Main functions.
4.2.7.3.2. Critical Sections¶
There is only one critical section in this driver. Within these sections all read /modify / write accesses to internal CAN status variables must be protected. Therefore, switching to tasks that also access CAN must be avoided and all CAN interrupts must be suspended. This is managed internally by CAN Driver.
4.2.8. API Description¶
4.2.8.1. Description of the API’s¶
Please refer MCAL_AM263_ApiGuide.CHM document provided as part of CSP.
4.2.8.2. API’s with Service ID¶
The following table presents the service IDs and the related services:
Service ID |
Service |
|---|---|
0x00 |
Can_Init |
0x01 |
Can_MainFunction_Write |
0x03 |
Can_SetControllerMode |
0x04 |
Can_DisableControllerInterrupts |
0x05 |
Can_EnableControllerInterrupts |
0x06 |
Can_Write |
0x07 |
Can_GetVersionInfo |
0x08 |
Can_MainFunction_Read |
0x09 |
Can_MainFunction_BusOff |
0x0A |
Can_MainFunction_Wakeup |
0x0B |
Can_CheckWakeup |
0x0C |
Can_MainFunction_Mode |
0x0F |
Can_SetBaudrate |
0x10 |
Can_DeInit |
0x11 |
Can_GetControllerErrorState |
0x12 |
Can_GetControllerMode |
0x14 |
Can_TestLoopBackModeEnable |
0x15 |
Can_TestLoopBackModeDisable |
0x16 |
Can_RegisterReadback |
4.2.8.3. Description on Non Standard API’s¶
Can_TestLoopBackModeEnable API–This function is non-autosar based and is used to enable the CAN loopback.
Can_TestLoopBackModeDisable API–This function is non-autosar based and is used to disable the CAN loopback.
Can_RegisterReadback API
This function is Non- Autosar based and is used to read the data from the registers of CAN. This functionality is enabled, if parameter CanRegisterReadbackAPI is TRUE (The Parameter sets CAN_REGISTER_READBACK_API Macro as STD_ON ).
4.2.9. Configuration Description¶
4.2.9.1. Configuration Variants¶
The CAN is configured through GUI in Post-Build and Pre-Compile Variants.
Variants |
Configured Files |
|---|---|
PostBuild |
Can_PBcfg.c , Can_Cfg.h |
Pre-Compile |
Can_Cfg.c , Can_Cfg.h |
4.2.9.2. Parameter Description¶
4.2.9.2.1. Standard Configuration¶
Standard Parameters |
Description |
Default Value |
Range |
Unit/Datatype |
|---|---|---|---|---|
CanControllerId |
This parameter provides the controller ID which is unique in a given CAN Driver. The value for this parameter starts with 0 and continue without any gaps |
0 |
0..255 |
INTEGER |
CanControllerActivation |
Defines if a CAN controller is used in the configuration |
FALSE |
TRUE FALSE |
BOOLEAN |
CanControllerBaseAddress |
Specifies the CAN controller base address. |
33816576 |
INTEGER |
|
CanWakeupProcessing |
Enables / disables API Can_MainFunction_Wakeup() for handling wakeup events in polling mode. |
INTERRUPT |
INTERRUPT POLLING |
INTEGER |
CanWakeupSupport |
CAN driver support for wakeup over CAN Bus |
FALSE |
TRUE FALSE |
INTEGER |
CanControllerBaudRate |
Specifies the baudrate of the controller in kbps |
500 |
0..2000 |
INTEGER |
CanControllerBaudRateConfigID |
Uniquely identifies a specific baud rate configuration. This ID is used by SetBaudrate API |
0 |
0..65535 |
INTEGER |
CanControllerPropSeg |
Specifies propagation delay in time quantas. |
8 |
0..255 |
INTEGER |
CanControllerSeg1 |
Specifies phase segment 1 in time quantas |
5 |
0..255 |
INTEGER |
CanControllerSeg2 |
Specifies phase segment 1 in time quantas |
4 |
0..255 |
INTEGER |
CanControllerSyncJumpWidth |
Specifies the synchronization jump width for the controller in time quantas |
1 |
0..255 |
INTEGER |
CanControllerFdBaudRate |
Specifies the data segment baud rate of the controller in kbps |
5000 |
0..16000 |
INTEGER |
CanControllerTrcvDelayCompensationOffset |
Specifies the Transceiver Delay Compensation Offset in ns. If not specified Transceiver Delay Compensation is disabled. |
180 |
0..400 |
INTEGER |
CanControllerTxBitRateSwitch |
Specifies if the bit rate switching shall be used for transmissions. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanFdPaddingValue |
Specifies the value which is used to pad unspecified data in CAN FD frames > 8 bytes for transmission. This is necessary due to the discrete possible values of the DLC if > 8 bytes. |
0 |
0..255 |
INTEGER |
CanHandleType |
Specifies the type (Full-CAN or Basic-CAN) of a hardware object. |
FULL |
BASIC FULL |
ENUMERATION |
CanHardwareObjectUsesPolling |
Enables polling of this hardware object. |
FALSE |
TRUE FALSE |
BOOLEAN |
CanHwObjectCount |
Number of hardware objects used to implement one HOH. In case of a HRH this parameter defines the number of elements in the hardware FIFO or the number of shadow buffers, in case of a HTH it defines the number of hardware objects used for multiplexed transmission or for a hardware FIFO used by a FullCAN HTH. |
1 |
1..65535 |
INTEGER |
CanIdType |
Specifies whether the IdValue is of type |
STANDARD |
EXTENDED MIXED STANDARD |
ENUMERATION |
CanObjectId |
|
0 |
0..65535 |
INTEGER |
CanObjectType |
Specifies if the HardwareObject is used as Transmit or as Receive object |
TRANSMIT |
RECEIVE TRANSMIT |
ENUMERATION |
CanTriggerTransmitEnable |
This parameter defines if or if not Can supports the trigger-transmit API for this handle. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanHwFilterCode |
Specifies (together with the filter mask) the identifiers range that passes the hardware filter. |
0 |
0..4294967295 |
INTEGER |
CanHwFilterMask |
Describes a mask for hardware-based filtering of CAN identifiers. The CAN identifiers of incoming messages are masked with the appropriate CanFilterMaskValue. Bits holding a 0 mean don't care, i.e. do not compare the message's identifier in the respective bit position. |
0 |
0..0xFFFFFFFF |
INTEGER |
CanDevErrorDetect |
Switches the Development Error Detection and Notification ON or OFF. |
FALSE |
TRUE FALSE |
BOOLEAN |
CanIdenticalIdCancellation |
Enables/disables cancellation of pending PDUs with identical ID. |
FALSE |
TRUE FALSE |
BOOLEAN |
CanIndex |
Specifies the InstanceId of this module instance. If only one instance is present it shall have the Id 0. |
0 |
0..255 |
INTEGER |
CanMainFunctionModePeriod |
This parameter describes the period for cyclic call to Can_MainFunction_Mode. Unit is seconds. |
10 |
0.001..65.535 |
FLOAT |
CanSetBaudrateApi |
The support of the Can_SetBaudrate API is optional.If this parameter is set to true the Can_SetBaudrate API shall be supported. Otherwise the API is not supported. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanTimeoutDuration |
Specifies the maximum time for blocking function until a timeout is detected. Unit is seconds |
10 |
0.001..65.535 |
FLOAT |
CanVersionInfoApi |
Switches the Can_GetVersionInfo() API ON or OFF. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanMainFunctionPeriod |
This parameter describes the period for cyclic call to Can_MainFunction_Read or Can_MainFunction_Write depending on the referring item. Unit is seconds |
0.001 |
0.001..65.535 |
Sec/FLOAT |
4.2.9.2.2. IP Specific Configuration¶
Standard Parameters |
Description |
Default Value |
Range |
Unit/DataType |
|---|---|---|---|---|
CanControllerInstance |
Selects Can Controller Instance. |
MCAN0 |
MCAN0 MCAN1 MCAN2 MCAN3 |
ENUMERATION |
CanErrorNotification |
Callback function for ECC Error and Parity error in case of AM273X |
NULL_PTR |
Not Applicable |
|
CanControllerType |
This parameter provides the controller Type. The value for this parameter is calculated by driver runtime |
0 |
0..255 |
INTEGER |
CanDisableAutoRetranmission |
Disable auto retransmission on xmit error |
TRUE |
TRUE FALSE |
BOOLEAN |
CanDeInitApi |
Adds / removes the service Can_DeInit() from the code. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanHardwareCancellation |
Specifies if hardware cancellation shall be supported.ON or OFF |
FALSE |
TRUE FALSE |
BOOLEAN |
CanDefaultOSCounterId |
Default Os Counter Id if node reference to OsCounter ref CanOsCounterRef is not set |
0 |
0..16 |
INTEGER |
CanMaxNrOfTxObjects |
Number of Transmit Objects |
3 |
0..3 |
INTEGER |
CanTypeofInterruptFunction |
Type of ISR function |
CAN_ISR_CAT2 |
CAN_ISR_VOID CAN_ISR_CAT1 CAN_ISR_CAT2 |
ENUMERATION |
CanLoopBackTest_Enable |
Enable/Disable LoopBack test API.If this parameter is set to true the LoopBack mode shall be supported which is used for internal testing. Otherwise the API is not supported. |
TRUE |
TRUE FALSE |
BOOLEAN |
CanMainFunctionReadPeriod |
This parameter describes the period for cyclic call to Can_MainFunction_Read. Unit is seconds. Different poll-cycles will be configurable if more than one CanMainFunctionReadPeriod is configured. In this case multiple Can_MainFunction_Read() will be provided by the CAN Driver module. |
0.001 |
0.001..65.535 |
FLOAT |
CanMainFunctionWritePeriod |
This parameter describes the period for cyclic call to Can_MainFunction_Write. Unit is seconds. Different poll-cycles will be configurable if more than one CanMainFunctionWritePeriod is configured. In this case multiple Can_MainFunction_Write() will be provided by the CAN Driver module. |
0.001 |
0.001..65.535 |
FLOAT |
CanDeviceVariant |
Select SOC variant .This parameter shall be used by driver to impose device specific constraints. The user guide shall detail the device specific constraints |
AM263x |
AM263x |
ENUMERATION |
4.2.9.3. Symbolic Names deviations¶
None
4.2.9.4. Configuration rules and constraints to enable plausibility checks¶
None
4.2.10. Memory Mapping¶
Memory Mapping Sections |
CAN_CODE |
CAN_CODE_ISR |
CAN_VAR_NO_INIT |
CAN_VAR_ZERO_INIT |
CAN_PBCFG |
CAN_PBCFG_ROOT |
|---|---|---|---|---|---|---|
CAN_START_SEC_VAR_INIT_UNSPECIFIED (.bss) |
X |
|||||
CAN_STOP_SEC_VAR_INIT_UNSPECIFIED |
X |
|||||
CAN_START_SEC_CODE_APPL (.text) |
X |
|||||
CAN_STOP_SEC_CODE_APPL |
X |
|||||
CAN_START_SEC_VAR_UNSPECIFIED (.bss) |
x |
|||||
CAN_STOP_SEC_VAR_UNSPECIFIED |
x |
|||||
CAN_START_SEC_CODE(.text) |
x |
|||||
CAN_STOP_SEC_CODE |
x |
|||||
CAN_START_SEC_PBCFG (.data) |
X |
|||||
CAN_STOP_SEC_PBCFG |
X |
|||||
CAN_START_SEC_PBCFG_ROOT (.const) |
X |
|||||
CAN_STOP_SEC_PBCFG_ROOT |
X |
4.2.11. Memory footprint¶
Please refer Memory Footprint for more details.
4.2.12. Performance¶
Can Performance [LINK]
4.2.13. Example Usage¶
4.2.13.1. Steps to build and run example¶
CAN example application demonstrating the MCAL CAN driver features is in folder <MCAL_ROOT>/examples/Can.
This application can be built from the build folder by giving “gmake –s can_app PLATFORM=am263.”
Once the build is completed we get a binary file, which is loaded in our controller and executed.
4.2.13.2. Document external set up Information¶
Locate the CAN-H and CAN-L pins on both the PCAN device and the board. Refer to the documentation or user manual for both the PCAN device and the board to find the correct pins.
Select appropriate cables with the necessary connectors to connect between the PCAN device and the board. Ensure the cables have the correct connectors to fit securely into both the PCAN device and board’s connectors.
Connect the CAN-H pin from the PCAN device to the corresponding CAN-H pin on the board using the chosen cable.
Connect the CAN-L pin from the PCAN device to the corresponding CAN-L pin on the board using the chosen cable.
Place a 120-ohm resistor between the CAN-H and CAN-L lines at the board end.
The resistor should be connected in parallel between the CAN-H and CAN-L lines, creating a termination point.
Open the PCAN configuration software on your PC. The software is usually provided by the manufacturer of the PCAN device.
Locate the settings for bit rate configuration.
Set the nominal bit rate to 1 Mbps and the data bit rate to 5 Mbps.
Apply the changes and save the configuration.
Ensure all connections are secure and properly plugged into their respective connectors on both the PCAN device and the board.
Before powering on the system, double-check all connections to ensure they are correctly made, and there are no loose or improperly connected cables.
After making the connections and configuring the PCAN device, power on both the board and the PCAN device.
Once the system is powered on, verify that the CAN communication is established between the board and the PCAN device.
4.2.13.3. Flow of the example application¶
By default, the CAN example runs in Loop Back mode.
For AM263x:
All 4 CAN Controllers transmit the data and then receive it through the Interrupt Service Routine (ISR).
After receiving the data, it is compared with the transmitted data.
If the received data mismatches the transmitted data, then the application fails.
External Loop back mode can be enabled by setting “CAN_LOOPBACK_ENABLE” in Can_Cfg.h to STD_OFF.
In External Loop Back mode, CAN communication can be tested using the PCAN debugger.
For AM263x “PROC110E2A” board:
MCAN1 pins are popped out, and MCAN1 is configured with a 1Mbps nominal bit-rate and 5 Mbps data bit-rate.
While running the example code in External Loop back mode:
First, it asks to select the CAN instance, where “m” corresponds to MCAN1/MCANB.
Then it asks to select the interrupt or polling method.
If interrupts are enabled for the instance in Can_PBcfg.c, then select the interrupt (“i”) method; otherwise, choose the Polling (“p”) method.
After selecting the method, options for transmission and reception will appear.
If the user chooses the transmit option, they are further prompted to select between standard and extended frames.
Selecting the standard option transmits a Standard CAN frame, while choosing the extended option transmits an extended frame to PCAN.
In receive mode, the controller is ready to receive CAN frames from PCAN.
4.2.13.4. Configuration used to test this example¶
All 4 Instances of CAN are configured.
All CAN controllers are configured with 1Mbps Arbitration bit rate and 5 Mbps of Data bit rate.
In total 16 Hardware Objects are configured, For each CAN controller 2 HTH and 2 HRH.
In Default example for Reception 0xC1 ID filter is configured for Polling Mode and 0xC0 ID filter is configured for Interrupt mode.
Please refer configuration parameters in below images for baudrate update
For 1Mbps and 5Mpbs:
For 500Kbps and 2.5Mpbs
4.2.13.5. Example Logs¶
AM263x
CanApp: Sample Application - STARTS !!!
CanAppgCanAppMcuClockConfig[0].Mcu_ClockSourceId = 4 gCanAppMcuClockConfig[0].Mcu_ClockDiv = 4
CanApp: CAN Loopback test
CanApp: Can Controller: MCAN0
CanAppCalling Can_Write
CanAppCan_Write ok
CanApp: Test Passed
CanApp: Can Controller: MCAN1
CanAppCalling Can_Write
CanAppCan_Write ok
CanApp: Test Passed
CanApp: Can Controller: MCAN2
CanAppCalling Can_Write
CanAppCan_Write ok
CanApp: Test Passed
CanApp: Can Controller: MCAN3
CanAppCalling Can_Write
CanAppCan_Write ok
CanApp: Test Passed
CAN Stack Usage: 764 bytes
CAN Test Passed!!!
4.2.14. FAQ’s¶
4.2.15. Test Report¶
Please refer AM26x CAN Driver Test Case Report provided as part of CSP.
4.2.16. References¶
4.2.17. TI Disclaimer¶
Texas Instruments and its subsidiaries (TI) reserve the right to make changes to their products or to discontinue any product or service without notice, and advise customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability.
TI warrants performance of its products to the specifications applicable at the time of sale in accordance with TI’s standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements.
Customers are responsible for their applications using TI components. In order to minimize risks associated with the customer’s applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards.
TI assumes no liability for applications assistance or customer product design. TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such products or services might be or are used. TI’s publication of information regarding any third party’s products or services does not constitute TI’s approval, license, warranty or endorsement thereof.
Reproduction of information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations and notices. Representation or reproduction o f this information with alteration voids all warranties provided for an associated TI product or service, is an unfair and deceptive business practice, and TI is not responsible nor liable for any such use.
Resale of TI’s products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service, is an unfair and deceptive business practice, and TI is not responsible nor liable for any such use.
Also see: Standard Terms and Conditions of Sale for Semiconductor Products https://www.ti.com/sc/docs/stdterms.htm
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265