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/TMS320F2810: tms320f2810

Part Number: TMS320F2810


Tool/software: Code Composer Studio

We use TMS320F2810 DSP for motor control applications. In our case Our drive will be a slave and PLC being the master. Recently we've observed an issue of CAN engine not responding to the RTR messages after sometime. When i look at the status registers i observed bit stuff error bit was active. Does this error cause the CAN engine to halt?

  • I presume RTR is sent by the Master and the F2810 (slave) is expected to respond to it. Stuff error, by itself does not halt the communication. The protocol is designed to recover gracefully from error conditions, unless excessive errors have forced the node to a bus-off state. Which brings me to the next question: Is the node in bus-off condition? Have you checked the CCR bit, which gets set during bus-off? If is indeed in bus-off, how does your code handle recovery?

     

    You say it doesn’t respond to RTR. Are you able to transmit a data-frame by setting TRS=1? I am asking this question to differentiate between these two situations: 1. A node is unable to respond to RTR (Vs) 2. A node is unable to transmit anything. This line of thought leads us to the errata. Have you looked at the following erratum: eCAN: Unexpected Cessation of Transmit Operation (page 17 of SPRZ193Q)?

     

     

  • Hello sir,

    Thanks for the reply.
    As of now no recovery handling is implemented in case of Bus off condition. We will implement it.

    The following value was observed in the CAN error&status registers
    0x0010010 -- which implies that only CCE bit and Stuff error bit were set. Bus off bit was not set.

    The CAN is configured to generate Receive interrupt, which works fine when there are no errors. But when error condition occurs we observed that receive interrupt also stopped working i.e when an RTR was sent to the slave it is not going to the receive ISR.

    Regards
    Kireeti
  • Kireeti,

    You have not answered many questions in my previous post. Please answer them.

    CCE being set implies CCR being set, which implies node is in bus-off.

  • Hello sir,

    I've worked on the cases that  you've mentioned in your reply. The following are the observations.

    1. CCR bit was set during the error case.

    2. I was not able to transmit data by setting TRS bit. This I've verified with help of a CANAlyser. No data was seen on the CANAlyser when i tried to transmit.

    3. I've gone through the erratum "eCAN: Unexpected Cessation of Transmit Operation (page 17 of SPRZ193Q)". I've implemented the recovery option mentioned in the document in my code. By verifying the CCE bit I've set the CCR bit and cleared the CCR bit,but this did not resolve the issue. The bus off condition was not recovered by doing this.

    Thanks and Regards

    Kireeti 

  • It doesn’t appear this is the case of the erratum. It appears your node is just in bus-off condition.

     

    Does the CAN traffic on CANalyzer show error frames prior to this condition?

    In your code, do you monitor the error counters?

    Do you monitor the EW & EP bits in CANES register?

    Are you monitoring for 128x11 recessive bits before attempting to take the node out of BO?

     

    Many things happen to alert you before a node goes bus-off. You need to determine why your node goes BO in the first place. Have you monitored the bit-rate of each node at the CANTX pins? Please look at the debug tips of my app.note SPRA876.

  • Hi Kireeti,
    Is the issue resolved?