• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 278 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: DCAN stop sending data in some circumstance

Sheldon He
Expert 8585 points
Part Number: TMS320F28388D

Hi expert,

My customer sending CAN frames in three timer triggered functions with F28388D's CM core. These "takes" who send CAN frame have an interval of 1ms, 2ms and 10ms. Data transmitting is via for loop with no special delay among each frames. 

They met transmmit stop issue when running and it seems highly related to "How they send these frams", means the sending frequency. I get three register capture here and one is normal case, the other two are abnormal cases. Could you help me review the register dump to idenfity the possible casue?

Let me know if you need more information here.

1541.CAN register dump.zip

Thanks

Sheldon

  • 0
    TI__Mastermind 34335 points

    Hi Sheldon,

    What I typically look for in the register dumps are the error status register (CAN_ES), error counter register (CAN_ERRC), parity error register (CAN_PERR), pending interrupts registers (CAN_IPEN_xx), transmission request registers (CAN_TXRQ_xx) and message valid registers (CAN_MVAL_xx).  These registers will somehow indicate if there have been any errors and the fact that the LEC in CAN_ES is 7 means there was no reported error for all three dumps.  The other registers like TX request and pending interrupts may also indicate that there is a request that has not been serviced yet and may indicate errors but these register do not indicate anything on the three files.  Looks like application is using mailboxes 0-3 for CANA and mailboxes 0-2 for CANB as indicated by CAN_MVAL_xx registers and on all 3 dumps, these values are the same.

    Unfortunately, the register dumps do not indicate anything wrong.

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    TI__Expert 8585 points

    Hi Joseph,

    One additional question here. This issue is highly related to CAN bus load rate for the higher the CAN bus load, more frequent the issue will be reproduced. They will not get this issue anymore when CAN bus load rate down to 70% or less.

    1. Do you have any comments on what could be a cause here? (How to debug this further)

    2. For TI's DCAN mdoule, is there a recommended CAN bus load rate that we should keep as a red line?

    Thanks

    Sheldon

  • 0 in reply to Sheldon He
    TI__Mastermind 34335 points

    Hi Sheldon,

    By reducing CAN bus load rate, did you mean reducing the baudrate or is it something else?  Sorry, i am not clear on what you menat by bus load rate.  Thanks for clarifying.

    Regards,

    Joseph

  • 0 in reply to Joseph Casuga
    TI__Expert 8585 points

    Hi Joseph,

    It is something like this:

    bus load = #bytes send / speed

    Also refer to https://kb.vector.com/entry/1519/

    May I know our recommendation here?

    Thanks

    Sheldon

  • 0 in reply to Sheldon He
    TI__Mastermind 34335 points

    Hi Sheldon,

    Ok, now I understand what you mean.  I am not aware that the TI DCAN has a bus load spec.  Based on the intervals of CAN messages sent, looks like there is around 1600 frames sent every second.  What is the baudrate that the CAN is set to? Has the customer  tried the max 1Mbps baud rate?  This would reduce put the bus load to approximately 25%.  Maybe customer is using lower CAN baud rates.  Another thing you can recommend (if customer cannot change the baud rate) is to use standard ID of 11 bits.  If customer is using the extended 29-bit ID, there will be 18 more bits (and maybe some stuffing bits too) that will be added to the frame so using the standard ID will shorten the frame time.

    Regards,

    Joseph