• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 501 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.

Original question:

CCS/TMS320F28035: a fallback for ecan failure

CCS/TMS320F28035: eCAN mode transition failed.

user5019379
Intellectual 370 points

Part Number: TMS320F28035

Tool/software: Code Composer Studio

Hello Sir/Madam,

when the eCAN encounter an error, a handler is triggered to reinitialize the eCAN HW module.

the sequence is the same as below diagram, put eCAN into configuration mode first from normal mode, then request goto normal mode at the end.

the handler is stucked at the final step that CCE is not change into 0 by the request command.

Do you have any ideas on how to solve this problem rather then reset the MCU?

the working environment is that there are 2 node on the CAN bus with 500k/bits communication. 

  • 0
    TI__Guru* 95315 points

    I am unable to see the figure in your post, but I presume you are referring to Fig 14-5 in page 816 of SPRUI10. Looks like you are able to get CCE to become 1 initially, but unable to get CCE back to 0 while exiting the configuration mode. Please answer the following questions:

    1. What kind of "error" did the bus encounter?
    2. Can you check the level of the CANRX pin when the code is stuck in this loop?
    3. Do you have some kind of a timeout where code exits the loop after some time if it doesn’t sense CCE to be 0 ?
    4. Have you looked into performing a soft-reset (SRES) during this error condition?
  • 0 in reply to Hareesh Janakiraman
    TI__Guru* 95315 points

    I believe I have the answers for 1 & 2 from https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/918299/3393115#3393115 

    What kind of "error" did the bus encounter?

    It appears this is Bus-off that is deliberately created as an experiment and the problem shows up after tens of thousands of times. 

    Can you check the level of the CANRX pin when the code is stuck in this loop?

    The CANRX pin is high, which means bus is idle from the node's point of view. 

    So, I only need answers to 3 & 4. (and 5 & 6 below) 

    5. Is recovery from bus-off set to automatic? i.e. ABO=1?

    6. Are you able to recover from this situation by initiating a warm reset?

  • 0 in reply to Hareesh Janakiraman
    Intellectual 370 points

    hello Sir,

    thanks a lot for your answer,

    answers as below,

    3. a time-out used in the CAN initial code for not cause any block there, another task keep monitor the CCE bit, if it transits successfully, then notify the upper layer software components, otherwise, just keep monitoring.

    4. no, we are looking for a method that only reset CAN module only, maxly narrowing the impact scope.

    5. not test yet, we have a manually recovery for each 200ms.

    6. not test yet.

    does IT have any recommand fallbacks when detecting a  time-out for this?

  • 0 in reply to user5019379
    TI__Guru* 95315 points

    3. a time-out used in the CAN initial code for not cause any block there, another task keep monitor the CCE bit, if it transits successfully, then notify the upper layer software components, otherwise, just keep monitoring.

    I understood as follows: You do have a timeout during initialization of the module (at the beginning of your application). For the bus-off recovery procedure, there is no timeout and the code will simply keep looping. 

    4. no, we are looking for a method that only reset CAN module only, maxly narrowing the impact scope.

    SRES is a bit in CAMC register. Reset done via SRES will reset only the CAN module. 

    5. not test yet, we have a manually recovery for each 200ms.

    Note that when the node enters bus-off CCR is set to 1. Can you simply try clearing CCR bit to come out of bus-off (as opposed to "setting" CCR and clearing it)? 

    does TI have any recommended fallbacks when detecting a time-out for this?

    No. What you are facing is an anomalous condition. Bus-off recovery can either be automatic (when you set ABO=1) or manual (by way of clearing the CCR bit)

  • 0 in reply to Hareesh Janakiraman
    Intellectual 370 points

    Hello Sir,

    as it is quite hard to reproduce this condition, last time when is CCR = 0 is requested, but CCE cannot change to 0 happened, we connect the JTAG probe and

    directly set CCR = 1 then CCR = 0, CCE could change to 0.

    i think the SRES should work, but we want to know the exactly the specific reason/condition for this case (CCE stuck)  .

    i am looking forward for your any answer.

  • 0 in reply to user5019379
    TI__Guru* 95315 points

    What I am suggesting is to change your application code to just clear CCR bit when a bus-off condition is detected. If that doesn’t recover the module within a specified time, initiate a software reset. 

    Is there a reason why you do not use auto recovery from bus-off? Could you try that as an experiment? 

    but we want to know the exactly the specific reason/condition for this case (CCE stuck)

    I understand you see this after tens of thousands of attempts. It is hard for me to come up with possible reasons for such a rare condition. I presume all other parts of the chip is working fine and the only problem you face is being unable to get the CCE bit cleared. Have you looked at the diagnostic tips in my Application Report (http://www.ti.com/lit/spra876 ), specifically the one pertaining to 32-bit R/W?