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.

CAN issue with tm4c123gxl board

Other Parts Discussed in Thread: TM4C123GH6PM, LM3S8962

Hi,

I've been trying to use the C series Launchpad Evaluation Kit with the tm4c123gh6pm chip to talk to a SN65HVD255D Evaluation Module using CAN but I can't seem to get it to work.

Right now, I am running the simple_tx.c CAN example program on my launchpad, and I've connected the CAN0TX and CAN0RX GPIO pins to the TXD and RXD pins on the evaluation board. Everything compiles, and things print onto a terminal. But I am getting the error message of cable connected?

The register view in Code composer shows that I occasionally get activity on the CAN_TST register where the receive observation bit get triggered, but I can't find any documentation on what that means. And I can't find a pattern of when it is triggering.

Is there anything else I need to connect or do?

  • Hi,

    You need two boards and a cable between to realize a valid communication. Two boards means 2x(Lauchpad+SN65HVD255D) - in terms of CAN: two nodes. No other way around - CAN rules.

    And of coarse some programs to learn/play with. Suggest to search/download what you find out in old Stellaris distributions (e.g. LM3S8962). The CAN module seems to be the same.

    Petrei

  • Ah, that makes more sense. I'll try that.

    Though, in theory, shouldn't a CAN interface like http://www.totalphase.com/products/komodo-canduo/ still work if I hook it up to the CANH and CANL?

    As I understand it, my one launchpad board was erroring out because it was sending a message, but getting nothing in return saying that the message was received. 

  • Hi,

    The most important thing is to build first the CAN bus = the physical transmission line, closed at both end by the characteristic impedance an then to attach two nodes (one "master" and one "slave"). Komodo says it can be configures as a node, but, in paragraph 5.6.1, note 2, it says having a limited capability buffer, showing errors/skipping messages - or your main goal at this stage is keeping sending messages while investigating/ debugging - seems to have an extra added source of possible (bad) info - so I am reserved about that, but you may try. 

    Petrei

     

  • Thank you so much. You have been a huge help.

    I'm putting the Komodo thing on hold for now, since I am making progress with just the boards.

    My setup works right now with the transmitting program loaded onto one board and the receiving program loaded onto the other board and two CAN transceivers in the middle. With enough code tweaking, I should be able to load the same program onto both boards so they can send/receive from each other right? So if a node is a "master" initially, can it become a "slave" later?

  • Hi,

    You can say a master node can become a slave node later, but, I prefer to maintain the initial set as master/controller and just say that a slave/peripheral can push messages to the master/controller. (Use this terminology only if you have two identical modules working in parallel and needs to be synchronized.)

    This difference should be highlighted since in the other case someone can think that the slave become the full functional master, which may not be true, due to both hardware and software consideration - i.e. your peripheral miss a display or does not have full capabilities of the master(software not includded, micro is a cheaper version...).

    Petrei

  • Shalmali Joshi said:
    I've connected the CAN0TX and CAN0RX GPIO pins to the TXD and RXD pins on the evaluation board. Everything compiles, and things print onto a terminal. But I am getting the error message of cable connected?

     Hi, in your configuration seem as there is an error on wiring, see diagram if is wired this way or as I understood uC side RX and TX where connected in parallel to Bus line. DOn't do that, bus line is subjected to some spikes, RF noise and common mode voltage too, driver is designed for, uC side both controller and uC chip may got destroyed by.

    ****  EDIT Jul 19 *****

     On diagram where an error I corrected now.

     Reading again all post I realized connection where on right way. After posting I lost connection. Sorry.

    *************************

     CanBUS network line impedance controlled and both side Zo terminated.

    T======x===============x================x================x=========T

                    !| CAN H                    !|CAN H                       !| CAN H                      !| CAN H   

                    !| CAN L                     !| CAN L                       !| CAN L                      !| CAN L  

       +-----------------------+    +-----------------------+     +------------------------+    +------------------------+

       | CAN BUS Trcvr  |     | CAN BUS Trcvr  |     | CAN BUS Trcvr  |     | CAN BUS Trcvr   | 

       |______________|    |______________|     |______________|     |______________| 

                    !| TXD                         !| TXD                          !| TXD                          !| TXD         uC side disjointed from bus and

                    !| RXD                        !| RXD                         !| RXD                          !| RXD        other remote nodes too

       |-------------------------|    |-------------------------|     |-------------------------|     |--------------------------| CANxTX CANxRX

       | uC Side Can bus|    | uC Side Can bus|     | uC Side Can bus|     | uC Side Can bus| just from uC to

       |______________|    |______________|     |______________|     |______________| Driver no other.

            Node 0                              Node 1                         Node 2                         Node 3

      This side MUST be ground separated and not interconnected any way to CANBUS still if non isolated solution. I suggest if CANBUS is non short or RF exposed to evaluate isolated can bus driver.

  • Roberto, I am not sure what you are suggesting, but this is how my system is connected:

    (UART on my computer) <->MCU <-> CAN Tranciever <-> CAN Tranciever <->MCU <-> (UART on my computer)

    And it all works now, Komodo analyzer and all,  in case anyone is reading this post in the future.

    Make sure you tie your CAN High and CAN Low outputs together with a 120 ohm resistor. The Evaluation board I used had it built into the board, I just had to connect two of the pins together with a jumper cable. Without that, it basically errors out and doesn't work. My cable disconnected problem was solved by adding the 120 ohm resistor.

  • Shalmali Joshi said:
    Make sure you tie your CAN High and CAN Low outputs together with a 120 ohm resistor. The Evaluation board I used had it built into the board, I just had to connect two of the pins together with a jumper cable. Without that, it basically errors out and doesn't work. My cable disconnected problem was solved by adding the 120 ohm resistor.

     One resistor MUST be on one bus end and just another one MUST be at opposite end of cable. You can see them in my diagram as T===... And ===T where T are the terminating resistor and == is the twin bus cable impedance controlled.

     No value where on my diagram due to Terminating resistor MUST be the same Zo value of cable so not 120Ohm but just Zo. In case you use a CANBUS specific cable check impedance is 120Ohm and in case you use cat 5 cables use 100Ohm instead.

     Stub on canbus connection MUST be very short to avoid impedance mismatching and reflection, reflection come from both open or shorted lines, open stubs fully reflect transmitted pulse, reflected pulse signals change polarity on case Zo is lower or bigger and is more intense if close to open or short and completely adsorbed if Zo matched.

     For more info check a basic about transmission lines.