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.

TM4C129EKCPDT: Lose data between different brand MCU CAN communication

Part Number: TM4C129EKCPDT

Hi

TM4C129EKCPDT-> CAN Tx, also received by TM4C129EKCPDT. It's OK as below right picture.

TM4C129EKCPDT -> CAN Tx, receive it by another brand MCU.  It's failed in sometimes as below left picture.

Where should we pay attention to troubleshoot? Frequency accuracy? Thanks a lot.

Here is waveform.

  • The first step would be to carefully check the bit timing generated by the sending device (TM4C129EKCPDT) using the oscilloscope to verify that you have the baud rate set correctly. (It could be incorrect on both TM4C129EKCPDT and still work.) If it is correct, then try to catch the error response from the "other" MCU. A logic analyzer with a CAN interpreter will help. If you see stuff bit errors and an error response from the other MCU, it is likely a baud rate mismatch.

  • Greetings,

    I like the vendor's recognition that, 'Frequency could be OFF at (both) of  'this vendor's devices.'    Should both devices run (reasonably) 'fast' or 'slow' - communication between these two devices (may) prove robust.   (as the frequency 'delta' between the two is acceptable.)     That said - as 'communication IS the issue here' - it is believed that  checking the timing/frequency of (both) CAN devices (vendor's local) and (other's remote)  - and bringing (both) into 'specification limits'proves a more effective, 'First Step!'   

    Now when 2 devices attach (each from different vendors) - and should one 'be fast' - the other 'slow' - then that frequency 'delta' may prove excessive.   (And Yes - we have seen that ... and there 'is' a tendency for individual vendor CAN devices to run (almost) uniformly - 'fast or slow.')   So - when 'joined'  (to another vendor's device) and you're unlucky - communication may be disturbed.

    You note only 'sometimes'  does communication break down.    Presenting a more measured quantification of error occurrences - would be helpful.   And - there is NO report of the number of devices/implementations - suffering this issue.    That's (always) important - is it not?    

    Also - unstated is the operating environment of 'each brand' of CAN device.   Might the issue be a noise source(s) - isolated to the (present) 'other CAN brand's' location/environment?   Every effort must be made to detect & eliminate (any/all) potential sources of  'communication impediments.'    Ideally - when conducting such 'A-B' tests - the devices are tested (only) in a highly controlled & duplicative environment.   Exercising diagnostic staff when a 'suspect joint/termination/methodology' exists - is not (really) justifiable!

    Long ago my firm designed/developed a 'CAN Analyzer' which measured such timing/frequency - and provided a 'Go - No Go' confirmation prior to that CAN device's, packing/shipping.'  

    A final tip - it would prove best to measure (your) and the (other) vendor device w/the same (recently) calibrated instrument (scope etc.) - to assure error minimization...   (the more 'unknowns' allowed - the longer the diagnostic hunt!)

  • Hi Daniel,

    I have not heard back from you so I assume that this issue has been resolved. If not, just reply to this thread, or open a related thread.