Verify and correct all relevant configurations. Problems can be related to misconfiguration of basic software (bsw) modules or arise because of hardware issues. Please go through the following troubleshooting list, that most likely helps you to identify the root cause of your issue.
Are all pins of your CAN transceiver correctly connected to voltage supply?
- Please have a look at the specification of your transceiver to identify functionality of each pin of the transceiver and how it should be used. Please find an example for TJA1145 CAN Transceiver at .
- Jumpers on the evaluation board must be set correctly for each CAN channel you want to use. You find the description for each jumper inside of your evaluation board manual.
Can you measure any CAN communication at the transceiver?
- Please measure communication on CAN bus (Hi/Lo) and ECU (Rx/Tx) side of the transceiver to make sure the transceiver works correctly.
- If the signal you measure with an oscilloscope looks longer/shorter than the signal you are expecting, verify the CAN controller clocking.
Is the CAN Interrupt executed? (in case you use Interrupt mode in the CAN driver)
- If you do not see the Interrupt, no message is sent by the CAN controller. Please verify that you have chosen the correct interrupt source and priority in the Os configuration for your CAN Interrupt.
- For testing purposes, modify your CAN controller configuration to POLLING mode instead of INTERRUPT mode. Does this make the CAN communication work? If it does, your port configuration is correct. Otherwise, you should proof your port configuration to be correct for sure.
Does the function Can_Write() execute correctly?
- This function is called from higher layers, placing the CAN frame into the hardware buffer. If this function does not execute, your problem is located at higher layers of the stack. Please verify that CanIf_Transmit() gets executed and why Can_Write() is not called in this context.
- If Can_Write() is executed once, but then the buffer is full leading to an error in Development Error Tracer (Det), you should check you port configuration and the clocking of the CAN controller.
- Do you use a TriCore CPU? The Multi-CAN controller on Tricore CPUs has an additional selector specifying the Receive Input Selection of the physical CAN node. Please have a look at the processor manual to identify the correct selection (e.g. b_001).
The ECU runs into a Det after some time (with/without sending CAN frames)?
- Identify the module leading to the error using the AUTOSAR module list  using the ModuleId, which is provided inside the error. Afterwards identify the reason for the error using either the call stack in the debugger, the AUTOSAR SWS or the technical reference of the relevant module. Both documents describe the implemented Det errors – supporting you to solve the issue.
- In general, please enable Det service for all modules during development. It helps you to identify the root cause of problems, instead of the observed resulting problem.
- Do not deactivate Det services, if you experience a problem. The earlier you solve the issue, the less annoying it will be at the end.
Voltage supply of CAN transceiver is mostly not fixed on evaluation boards. Please verify, using the hardware manual of your evaluation board, that all jumpers are set correctly to power the relevant CAN transceiver.
CAN Controller uses a clock reference point defined in Mcu. Please make sure that this clock reference point references the clock used for the CAN controller (in Mcu configuration).
External oscillators should be preferred instead of using PLL clock for the CAN controller clock source inside of your Mcu configuration. The internal PLL might be less stable, which could lead to error frames sent by your ECU on the CAN bus.
Make sure that the port configuration matches the used CAN node in CAN controller. Additionally, not all combinations that are mentioned in the processor manual are enabled by your evaluation board, so please try to use multiple alternatives using different board pins.
Det services support you to identify misconfigurations and inconsistencies inside of your basic software modules during runtime. Please use this service – since it can save a lot of time searching for the reason of observed errors – for all available modules during development.
 AUTOSAR List of Basic Software Modules (ASR 4.3): https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_TR_BSWModuleList.pdf