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.

TM4C123GH6PM: CAN 1mps is not working in controller TM4C123GH6PM with baud rate 80MHz

Part Number: TM4C123GH6PM

Hello TI Team,

I am working on TM4C123GH6PM microcontroller for CAN application. I am sending/receiving the data from/to PCAN.

I have used CANBitRateSet() driver function for setting the baud rate with 80MHz clock. It was observed that, when the baud rate is configured for 100k,125k,250k , 500kbps and 800kbps, it works smoothly. But when the baud rate is increased to 1Mbps, the PCAN displays BUSHEAVY/BUSOFF conditions for 80MHz sysclk.

Then instead of CANBitRateSet() function, i tried by using CANBitTimingSet() for setting the bit rate which inturn uses tCANBitClkParms structure as shown below. The CAN clock was set to 80MHz. In this configuration also, it was observed that, when bit rate is 1mbps the PCAN displays BUSHEAVY/BUSOFF conditions.

tCANBitClkParms CANBitClkSettings[] =

{

    {16, 8, 4, 32},    // CANBAUD_100K ok at 80MHz clock.

    {13, 2, 4, 40},    // CANBAUD_125K ok at 80MHz clock.

    {4, 3, 2, 40} ,      // CANBAUD_250K ok at 80MHz clock.

    {10, 5, 4, 2} ,     // CANBAUD_500K ok at 80MHz clock.                

    {5, 4, 4, 10},        //4 -  CANBAUD_800K ok at 80MHz clock.

    {8, 1, 1, 8},       // CANBAUD_1M ok at 80MHz clock.   

    {6, 4, 4, 11},  //6 -  CANBAUD_666k ok at 80MHz clock.

    {3, 1, 1, 23}       //7 -  CANBAUD_700k ok at 80MHz clock.

};


The tCANBitClkParms  data structure contains the values for SyncPropPhase1, Phase2, SJW, BRP used for calculating bit rate. 

typedef struct
{

uint32_t ui32SyncPropPhase1Seg;

uint32_t ui32Phase2Seg;

uint32_t ui32SJW;

uint32_t ui32QuantumPrescaler;

}
tCANBitClkParms;

I am using SN65HVD1040D CAN transceiver and using 8MHz XTAL.

Here is attached hardware interface.

Please help me to fix the problem.

Thanks in advance.

  • Greetings,

    As always - scope waveforms revealing the Can Bus signals - prove immensely helpful:

    • 500Kbps - seems a good start - display the transceiver's differential output as well as the output past the 'termination network'
    • 800Kbps - I'm unsure if this is a 'recognized' standard - yet a similar set of scope caps (may) prove useful
    • 1Mbps  -  both captures here - ideally 'locked' to the same trigger points as the succeeding rates (i.e. enabling eased 'overlap' - so that (any) differences may be easily recognized) seems an 'extremely' helpful 'next step.'
    • Neither staff nor I are familiar w/'PCAN!'      Should that prove the case for vendor agents as well - then providing a 'link' would speed & ease your assistance...

  • CB1,

    Thanks, that is exactly what I was going to ask for.

    ,

    Scope pictures will tell a lot. Are we getting error frames and then going off-bus? Difference in measured bit size at 500Kb may still work, but at 1Mb not work. The capacitance of the bus might affect the bit timing as well. 

  • Greetings Bob,

    You are welcome - credit young college staff - after several months (here/other venues)  now 'Recognize & Can Resolve' - many Diagnostic Issues & Patterns.

    Now poster (twice) noted, "When the baud rate is increased to 1Mbps, the PCAN displays BUSHEAVY/BUSOFF conditions for 80MHz sysclk."    Does not  'PCAN'  properly  define those (exact) 'bus conditions'  -  which generate, 'Heavy & Off?'     (Poster appears to 'assume'  that many/most here, 'Have  PCAN  familiarity' - that's not the  safest  assumption.)

    The combination of the requested:

    • scope caps - both during success (≤ 800 Kbps) and failure (≥ 1Mbps)
    • those caps to each include the Can Bus:
      • @ the transceiver outputs
      • and after passing thru the termination network
    • and the diligent review of, 'PCAN's definition' of  'BusHeavy/BusOff' - and subsequently relating that key Can Bus (failure description) to the scope caps

    likely  'well positions'  the poster  to, 'Resolve his own issue!'

    While CAN does employ the advantaged, 'differential signalling' - 'Excessive Cable Lengths and/or Inferior Cable'  - are proven (beyond) the 'usual suspects' - when  '(especiallyhigher speed'  communication  - becomes erratic...

    Lastly - might we have here a classic case of, 'Premature Optimization?'      The 'CAN transceivers,  termination network components & connecting cables'  will  all  'AGE' - and are (almost) sure to be assaulted by 'new & stronger' noise sources - thus the  (apparent) quest for,  'Speed & Only Speed' may arrive w/a, 'Reduction in Robustness!'     (nullifying (any) benefits gained thru 'High Speed!')  

    Slower Data Rates - even when 'faster ones' (appear) to work - score much higher under, 'Risk-Reward'  - and (almost) always keep the communication channel, 'On the Air!'

  • Hi Cb1_mobile,

    Thank you for your reply.

    We have generated the CAN signals for 500Kbps and 800Kbps, its working like a charm. Here is the screenshot for those signals respectively.

    But when we check the CAN signals for 1Mbps, its sending irregular data. Please find the screenshot below.

    Thank you for your help.

  • Thank you - kindly note that (both) vendor's Bob & I responded - vendor agents are far more expert on specific MCU-based issues.

    May I note that if  your 'screen-shots'  are 'scope-caps' - your scope probes (likely) require adjustment.    (i.e. @ 500Kbps our MCU's CAN_TX signal is far more square than yours.)

    Both your 500 & 800Kbps captures appear to 'nicely frame' (i.e. center) a CAN Bus transaction.    (i.e.  each of the 4  CAN Signals clearly/cleanly reveal the transition from 'Inactive - to Active - back to Inactive'  CAN Bus.)      Such can not be said for the 1Mbps presentation!

    As specifically regards that 1Mbps screenshot:

    • Has the horizontal scale changed?     And if so - by how much?
    • The CAN_TX signal now (appears) to alternate between a (reasonable) square wave followed by a far narrower triangle wave.    This leads to the expectation that the baud-rate has (greatly) declined from the (claimed) 800Kbps.    Kindly measure (again) and advise.
    • In all cases - your MCU's CAN_TX & CAN_RX signals appear 'in phase.'     Is this expected?    (may result from your CAN Xcvr - I don't recall our CAN implementations operating in that manner)
    • The 'normal/customary' CAN Bus Transceiver signals are properly biased at your 500 & 800Kbps rates.    The 1Mbps outputs do not show (either) of those bias levels.

    Scope caps were also requested 'Just past your termination network.'     It is suggested that you 'simplify' that network to 'resistor alone'  (temporarily) - and then test/observe & report.

    Have you confirmed that your CAN Xcvr is (really) capable at 1Mbps?    (and at MCU's 3V3 levels?)

    And again - 'ALWAYS' it proves true that 'higher data rates' experience: 

    • shorter distance
    • more disturbance

    than 'Safer & Slower' ones.    (Speed proves 'not so advantageous' when messages must be 'Resent' - and/or 'undetected corruption' occurs...)

  • I think the sample rate on your oscilloscope is too low. Here is a scope shot of the TM4C123 transmitting at 1Mb using a 300MHz oscilloscope:

    Here is what it looks like with a logic analyzer sampling at 100MHz:

    Once you get a good scope picture, are you getting square waves out of the CAN transceiver? If not, try removing your common mode choke. 

  • Greetings Bob,

    Thanks for your expertise.    Surely the higher performance scope will 'help matters.'   

    Even better - if that's a '4 Channel Scope' - your presentation of (at minimum) the MCU's TX, RX and Xcvr Outputs - would prove IDEAL!     (especially if you could reach 1Mbps - don't you agree?)

    We must note that poster's 1Mbps CAN Rate does not succeed - thus any/all Poster Scope Limitations - are (unlikely) to have caused his issue...

    cb1_mobile said:
    It is suggested that you 'simplify' that termination network to 'resistor alone'  (temporarily) - and then test/observe & report.

    We've both (now) identified poster's  'termination choke  as  suspect.'

    My group remains 'unimpressed' by the 'Missing yet (assumed) pressing need' to 'Trade Robustness 'for Higher Speed!'     Is it (always) wise to 'Comply w/Poster Desires' - even when - and especially when - potential liabilities are introduced?