• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 367 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.

CCS/TM4C123GH6PM: CAN Bus Receiving only two characters

Deoyani Joshi
Prodigy 185 points
Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

Hello,

I have implemented a small node of CAN using 1N4148 diodes connected to Tx of both microcontrollers I am sharing the schematic diagram.

I have tried simpler_x.c,simple_tx.c codes from Tivaware peripheral example codes. I am getting output but when I am sending a string to through can bus, can RX object receiving only two characters.

example if I am sending hello then it receiving only "he ". I am doing the project in which I have to sensors values over can bus how to send and receive multiple characters or strings over can bus. 

 please guide me, what changes I have to do in the code?

thanks and regards

Deoyani

 

  • 0
    Prodigy 185 points

    This is the schematic of CanNode

  • 0 in reply to Deoyani Joshi
    TI__Guru**** 191486 points

    Hi,

      Using diode is only for very short distance, perhaps for a quick start on learning CAN. You need to use a proper transceiver in a real world application. Since you will eventually need to replace the diodes with the transceivers, you should try with the transceivers to see if you can repeat the same problem. If you are seeing the same problem then it is most likely the s/w problem. If with the transceivers, the problem goes away then the diodes will be the suspect. I strongly suggest that you use a CAN analyzer or logic analyzer that can interpret CAN protocol so you know what is going on the bus.  If you try to send 'hello', how will you know if the transmitter is not sending the 3rd character correctly or the receiver is not receiving the 3rd character correctly? Without the CAN analyzer it will be hard to debug. These are the suggestions I can offer at this time. I will close the thread for now. You can always reopen it by posting again if you have new results. Hopefully we will hear from you soon.  

  • 0 in reply to Charles Tsai
    Prodigy 185 points

    Hello,

    Can you suggest me any can analyzer?  

    thanks and regards

    Deoyani

  • 0 in reply to Deoyani Joshi
    Guru 117855 points

    Greetings,

    How deeply have you checked - and confirmed - that, "sCANMessage.ulMsgLen" accommodates your (>2) char width?     

    My group is, "Not so sure" that your "diode implementation" (eats) those last 3 chars.   You must "check for this limitation in BOTH Simple_RX & Simple_TX!    Also - had you noted that (both) "simple" code examples seek to "Increment" the byte being sent?   You have (almost) surely changed something - to achieve your "HE" result.

    Note that (any) form of Serial Bus Monitor proves immensely helpful.    CAN proves too complex for "Non-Instrumented" Analysis/diagnostics...             

  • 0 in reply to Deoyani Joshi
    TI__Guru**** 191486 points

    Hi,

      Do you have updates on the status? I hope you are making progress. Per cb1's suggestion, can you check what message length you are asking the CAN kernel to send out. a CAN frame can have up to 8 bytes of payload. If you have a scope or a logic analyzer you should at least see one CAN frame with the 'hello' as a payload as the 'hello' takes up only 5 bytes. 

      Below is an example of what you will expect to see for a 'one' byte payload frame. If you are transmitting 5 bytes you should see the DLC=5. I take the below screenshots from the wikipedia. You can find the same. 

  • 0 in reply to Charles Tsai
    Guru 117855 points

    Greetings Charles,

    May young staff here note that your (previously) un-noted talents as an "Artiste" (nearly) approach those of "Technologist."   We believe the completeness of your diagram - aided by its use of  "color, clear definition & high detail" proves especially effective!    (Staff will steal ... borrow it...)

    Not our attempt to, "Rock the boat" - yet staff recalls that (both)  "simple_rx.c & simple_tx.c" underwent fairly substantial modification during the transition from "StellarisWare to TivaWare!"    For many years we noted "quick & eased" success w/those "simple" program examples.   (yet used (only) the S-Ware versions!)

    Staff presents that past (S-Ware) portion of "simple_tx.c" - "known to work" - which has been altered by "T-Ware."   (primarily via "Type specifiers & qualifiers")     We don't know if the T-Ware code has been successfully test/verified...

    // Initialize the message object that will be used for sending CAN messages. The message will be 4 bytes that will contain an // incrementing value. Initially it will be set to 0.
    //
    *(unsigned long *)ucMsgData = 0;
    sCANMessage.ulMsgID = 1; // CAN message ID - use 1
    sCANMessage.ulMsgIDMask = 0; // no mask needed for TX
    sCANMessage.ulFlags = MSG_OBJ_TX_INT_ENABLE; // enable interrupt on TX
    sCANMessage.ulMsgLen = sizeof(ucMsgData); // size of message is 4
    sCANMessage.pucMsgData = ucMsgData; // ptr to message content

    We note that the "char" specifier ([past employed) has been altered.   Again - the above is the (S-Ware) [working] version.

    Do note that the transition from "S-Ware to T-Ware" was demanding - and like many such efforts - succeeded incrementally...