• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 115 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C2000-CGT: TMS320F28P650SK MCAN Classic CAN configuration issues, internal loopback test failure, and register access problems

Owen Yang
Prodigy 70 points

Part Number: C2000-CGT
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

 

TMS320F280P65SK7 MCAN Classic CAN configuration issues, internal loopback test failure, and register access problems.docx 

I. Problem Description

Currently, I am working with the TMS320F280P650SK7 microcontroller.
Due to project requirements, I need to utilize three channels of CAN communication interfaces simultaneously.
According to the F280P65x datasheet, the device features:

  • 1-ch DCAN
  • 2-ch MCAN

At present, the DCAN module has been successfully configured and is communicating normally.
I am now in the process of configuring the MCAN module.
My objective is to configure MCAN to operate in Classic CAN mode (without utilizing CAN FD features) and to verify its transmission and reception capabilities via the internal loopback mode first.

However, I have encountered the following issues:
The MCAN module fails to complete transmission and reception operations properly, and the internal loopback test is failing.

 

 

. Support Requested from TI

I would highly appreciate it if TI could help clarify and verify the following:

  1. Configuration Correctness: Is my current MCAN Classic CAN configuration sequence and setup correct?
  2. Root Cause Analysis: What are the potential or most common causes for the internal loopback test failure under this specific configuration?
  3. Recommended Practice: What is the officially recommended approach to configure MCAN on the F280P65x (e.g., via DriverLib or SysConfig)?
  4. Register-Level Access: Does the MCAN hardware architecture officially support direct, register-level structure access (like McanaRegs), or is it strictly constrained to APIs?
  5. Reference Examples: Are there any official MCAN Classic CAN reference examples or code snippets available for this device family?

Thank you very much for your time, guidance, and support.

  • 0
    TI__Mastermind 39963 points
    Hey Owen,
    Thank you for your patience, and apologies again for the delay while this thread was being routed to the right support queue.
    I had a chance to dig into this further, and here's a consolidated response covering the questions you raised regarding MCAN Classic CAN configuration on the TMS320F28P650SK7 (F28P65x family).
    1. Configuration Correctness / Recommended Practice
    For MCAN on F28P65x, TI's strong recommendation is to configure the module using SysConfig, since the MCAN initialization sequence has several ordering dependencies that are easy to get wrong when hand-coding with DriverLib alone. At a high level, the correct sequence is:
    • Enable the MCAN peripheral clock and bring the module out of reset.
    • Enter INIT mode (MCAN_setOpMode/CCCR.INIT = 1) and enable Configuration Change (CCCR.CCE = 1) before touching bit-timing, message RAM, or filter registers — writes to these registers are ignored by hardware unless CCE is set.
    • Configure the nominal bit time (MCAN_setBitTime).
    • For Classic CAN only, make sure FDOE (FD Operation Enable) and BRSE (Bit Rate Switch Enable) in CCCR are left disabled — this is what keeps the module in Classic CAN frame format rather than CAN FD.
    • Configure the Message RAM layout (TX buffers/FIFO, RX FIFO0/FIFO1, and the Standard/Extended ID filter lists) — on F28P65x this RAM is shared/partitioned per instance, so double check your allocation doesn't overlap or exceed the available Message RAM size for the device.
    • Add at least one filter element (MCAN_addMessageIDFilter) with an "accept"/store action — a very common gotcha is that with no filters configured, all Classic CAN frames are silently rejected (this affects loopback tests too, since even in loopback the frame still passes through acceptance filtering unless global filter config is set to accept all).
    • Set the desired test/loopback mode before exiting INIT: for internal loopback, CCCR.TEST = 1 and TEST.LBCK = 1, with MCAN configured for internal loopback (in DriverLib this is exposed via MCAN_selectMode/MCAN_lpbkModeControl depending on SDK version).
    • Finally, clear CCCR.INIT to exit initialization mode and start normal operation (MCAN_startModule).
    2. Most Common Root Causes for Internal Loopback Failure
    From what we typically see in the field, internal loopback failures on MCAN almost always trace back to one of these:
    • CCE not set when programming bit-timing/filter/Message RAM registers (writes silently ignored).
    • No filter elements configured, or the global filter configuration (NMF - "Non-Matching Frames") set to reject rather than accept.
    • FDOE/BRSE left enabled unintentionally, putting the module in FD framing when you intended Classic CAN — this can cause CRC/format mismatches during loopback.
    • Message RAM base address/offsets misconfigured or overlapping between TX/RX regions.
    • Loopback mode bit (TEST.LBCK) set after exiting INIT mode rather than before — this needs to happen while CCCR.INIT/CCE = 1.
    • Clock configuration for the MCAN module (mcan_clk) not enabled/sourced correctly, which can cause the module to appear "stuck" in INIT or never complete a transmit.
    3. Register-Level Access (McanaRegs)
    The MCAN module is memory-mapped, and the bit-field header (McanaRegs) does exist and can technically be accessed directly. However, recommendation is to use the DriverLib APIs rather than direct register access. The main reason is that several MCAN registers are gated by the CCCR.INIT/CCE state machine — writing them out of sequence (or forgetting to toggle INIT/CCE around Message RAM configuration) is a frequent source of silent failures, and DriverLib enforces the correct ordering for you. Direct register access is not "unsupported," but it puts the burden of sequencing correctness entirely on your code.
    4. Reference Examples
    For Classic CAN specifically:
    • C2000Ware added a dedicated "Classic CAN communication using MCAN + MCAN Rx/Tx" example for F28003x in a recent release. Since the MCAN peripheral IP (Bosch M_CAN) is common across the F28003x/F28P55x/F28P65x/F280015x family, this example is a good structural reference even though it targets a different device — the CCCR/bit-timing/filter setup pattern carries over directly.
    • On F28P65x itself, C2000Ware includes MCAN examples for timestamping and multi-buffer receive under driverlib/f28p65x/examples/c28x/mcan/— these are useful for seeing the correct Message RAM/filter setup pattern even though they're not Classic-CAN-loopback specific.
    • I'd also recommend generating your MCAN configuration from SysConfig first (even as a starting point) and comparing the generated mcan.c/board.c initialization order against your own code — this is usually the fastest way to spot ordering issues.
    Best Regards,
    Zack Fleenor