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.

TI8148 CAN bus receive

Has anybody had any success receiving CAN messages with the TI8148 EVM under Linux, and if so, what did you do?

I'm following the Wiki instructions, though they describe a different EVM: http://processors.wiki.ti.com/index.php/AM335X_DCAN_Driver_Guide

I can send packets that are received by a CAN USB adapter, but the evm does not receive packets. I'm using candump to show received packets, and I never have any results. There is also no indication of received packets in the packet counters.

I've tried a variety of other endpoints, including a second EVM, without success.

  • Hi Adrian,

    Please use this wiki page for DM814x:  http://processors.wiki.ti.com/index.php/TI81XX_PSP_DCAN_Driver_User_Guide.

    BR,

    Viet

  • Hi Viet,

    I've seen that page as well: the instructions are exactly the same, and the CAN port doesn't receive.

    Adrian

  • I have used CAN on I8148 EVM under Linux. I have a CAN device connected to dcan0 on the EVM. Here is what I did:   

    1. ip link set can0 type can bitrate 50000 <-- CAN device run on this bitrate

    2.ip link set can0 up

    3. candump can0 &

    4. cansend can0 -i 0x4e1 1 2

    can0 4E1 [2] 01 02                               <--  recv own message

    can0 4E0 [8] 01 02 10 00 C0 00 00 00    <-- recv response message from the CAN device

    Hope this helps.

    Jiewen

  • Interesting - I had to change your example slightly, as my CAN device is at 500kBit:

    root@dm814x-evm:~# ip link set can0 type can bitrate 500000
    root@dm814x-evm:~# ip link set can0 up
    d_can d_can: can0: setting CAN BT = 0x504
    root@dm814x-evm:~# candump can0 &
    root@dm814x-evm:~# interface = can0, family = 29, type = 3, proto = 1
    cansend can0 -i 0x4e1 1 2
    interface = can0, family = 29, type = 3, proto = 1

    My CAN device receives the message transmitted by CAN send, but candump does not see its own message, and does not see the reply message I send from my CAN device. I also get no response trying it at 50kBit/s in loopback mode:

    root@dm814x-evm:~# ip link set can0 type can bitrate 50000 loopback on
    root@dm814x-evm:~# ip link set can0 up
    d_can d_can: can0: setting CAN BT = 0x1c18
    root@dm814x-evm:~# candump can0 &
    root@dm814x-evm:~# interface = can0, family = 29, type = 3, proto = 1
    root@dm814x-evm:~# cansend can0 -i 0x4e1 1 2
    interface = can0, family = 29, type = 3, proto = 1

    Which SDK / Kernel are you using? This is mine:

    root@dm814x-evm:~# cat /proc/version
    Linux version 2.6.37 (x0029463@swubn01) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 Wed Oct 10 14:02:40 IST 2012

    My canutils is the latest from git, and my board stack consists of:

    • DM814x/AM387x BASE EVM REV D
    • EXPANSION I/O BOARD REV D
    • LCD ADAPTER BOARD REV C
  • Hi Adrian,

    Please check the connections details between the EVM and CAN device.

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_DCAN_Driver_User_Guide#Connection_details

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_DCAN_Driver_User_Guide#Port_details

    Once these connections are proper then hardware wise everything fine.

    As coming to software:-

    1. Can you get the logs for these?

    a. dmesg | grep -i can

    b. cat /proc/net/can/stats

    c. ip -d -s link show can0

    2. I hope you have not modified the kernel code (DCAN paltform data, pinmux settings and driver)

    3. Can you tell me the PSP/SDK version? (Not the kernel)

    4. In loopback mode, we can see both the packets TX & RX.

    5. In normal mode we can not see the packets in this board unless other device transmitted.

    Regards

    AnilKumar

    Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

  • The connections appear to be correct (as CAN is a differential bus, the ability to transmit indicates the wiring is fine). I'll get the rest of the logs once I'm back in the office.

    Our software versions are ti-ezsdk version 5.05 (5_05_01_04 according to PDF) from Oct 2012 and Linux Kernel: linux-2.6.37-psp04.04.00.01 

    To compare further, are you able to run a loopback test on your board (without cable plugged in) and show me the commands and console output so I can replicate?

  • First of all, 0x4E1 is a message that I used to request response from my CAN device, so the device will send back a 0x4E0 message if it receives 0x4E1. You need to use some

    messages that you know your device would recognize. 

    Secondly, I think I modified the device drive a bit (in d_can.c), in d_can_poll(), added logic to clear Parity Error status if getting Parity error interrupts.

    I did a loopback test, nothing connected to can interface, here is the output:

    root@dm814x-evm:~# ip link set can0 type can bitrate 50000 loopback on
    root@dm814x-evm:~# ip link set can0 up
    d_can d_can.0: can0: resetting d_can ...
    d_can d_can.0: can0: setting CAN BT = 0x1c18
    root@dm814x-evm:~# candump can0 &
    root@dm814x-evm:~# open 0 'can0'.
    using interface name 'can0'.

    root@dm814x-evm:~# cansend can0 -i 0x4E1 1 1
    interface = can0, family = 29, type = 3, proto = 1, idx = 2
    new index 0 (can0)
    can0 4E1 [2] 01 01
    can0 4E1 [2] 01 01
    root@dm814x-evm:~# cansend can0 -i 0x1 1 1
    interface = can0, family = 29, type = 3, proto = 1, idx = 2
    can0 1 [2] 01 01
    can0 1 [2] 01 01

    Good Luck

    Jiewen

     



  • Thanks for that - my results are quite different. As you can see, candump does not show any packets:

    root@dm814x-evm:~# ip link set can0 type can bitrate 50000 loopback on
    root@dm814x-evm:~# ip link set can0 up
    d_can d_can: can0: setting CAN BT = 0x1c18
    root@dm814x-evm:~# candump can0 &
    root@dm814x-evm:~# interface = can0, family = 29, type = 3, proto = 1
    cansend can0 -i 0x4E1 1 1
    interface = can0, family = 29, type = 3, proto = 1
    root@dm814x-evm:~# cansend can0 -i 0x1 1 1
    interface = can0, family = 29, type = 3, proto = 1

    For Anil Kumar, here are the other logs from the attempt:

    root@dm814x-evm:~# cat /proc/net/can/stats

    2 transmitted frames (TXF)
    0 received frames (RXF)
    0 matched frames (RXMF)

    0 % total match ratio (RXMR)
    0 frames/s total tx rate (TXR)
    0 frames/s total rx rate (RXR)

    0 % current match ratio (CRXMR)
    0 frames/s current tx rate (CTXR)
    0 frames/s current rx rate (CRXR)

    0 % max match ratio (MRXMR)
    1 frames/s max tx rate (MTXR)
    0 frames/s max rx rate (MRXR)

    1 current receive list entries (CRCV)
    2 maximum receive list entries (MRCV)

    root@dm814x-evm:~# dmesg | grep -i can
    NOR: Can't request GPMC CS
    PM: Adding info for platform:d_can
    ti81xx_pcie: Starting PCI scan...
    CAN device driver interface
    CAN bus driver for Bosch D_CAN controller 1.0
    PM: Adding info for No Bus:can0
    d_can d_can: d_can device registered (irq=52, irq_obj=53)
    can: controller area network core (rev 20090105 abi 8)
    can: raw protocol (rev 20090105)
    can: broadcast manager protocol (rev 20090105 t)
    d_can d_can: can0: setting CAN BT = 0x1c18

    root@dm814x-evm:~# ip -d -s link show can0
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
    link/can
    can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
    bitrate 50000 sample-point 0.875
    tq 1250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
    d_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
    clock 20000000
    re-started bus-errors arbit-lost error-warn error-pass bus-off
    0 0 0 0 0 0
    RX: bytes packets errors dropped overrun mcast
    0 0 0 0 0 0
    TX: bytes packets errors dropped carrier collsns
    0 0 0 0 0 0

  • I have a breakthrough today. The binary kernel from the SDK, and the kernel compiled by my colleague, both failed.

    The kernel I built on my own development machine from the SDK source has working CAN. The reasons are a mystery, but this appears to be a toolchain problem.

  • The true fix is actually this patch, which needs to be adjusted and applied to the d_can.c file. This has been fixed in other TI processors, but never ported back in to the GIT tree for DM8148 processors.