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.

TCAN4550: TCAN4550 timeout problem

Part Number: TCAN4550

Hi TI Team!

I have got a question about TCAN4550.

Problem occoures if can goes in to ERR state. I can reproduce this error if CANH and CANL is connected to GND for a short period of time. Then register CANERR and CANTO is triggered which is correct.

My question is am i able to reset and "reinit" TCAN without hard reset the whole board. 

Regards.

Seba

  • Seba,

    If you really need to reset the device, the RST pin can be toggled to initiate a hard reset of the TCAN4550-Q1 and allow re-initialization. However, if you clear the interrupt flags that assert and remove the condition that caused them to trigger in the first place, the device should be fully configurable again.

    Does this help?

    Regards,

  • Hi Eric,

    Thank you for anwser  and sorry for such al long delayed response.

    We were testing a lot these days and what you suggested unfortunately did not help. We try to reset al the interrupts but err still persist. We also try to reset tcan and try to reint it bud it does not help. Only thing that helped is hard reset board where tcan4550 is.

    Do you think it is something related with “bus off state”?

    How can i recover module from this state ?

    Regards.

    Seba

  • Sebastijan,

    No worries about the delay, we're all busy these days.

    For the bus off state you're referencing, this is an error state that is the result of the TCAN4550-Q1 error counter incrementing due to erroneous CAN frames. In order to get out of this state, the device will need to send a a large number of correct CAN frames so that the device can observe the error state is removed from the CAN bus.

    Is there any way you can share the CAN bus waveforms?

    Regards,

  • Hi Eric,

    Thank you for quick reply.

    Would be data from logic analyser enough?

    Can yo just explain what will be sufficient waveform for you?

    You probably want to se when waveform when error occurs right? Or just random waveform communication?

    Regards.

    Seba

  • Seba,

    Yes, waveforms when the error occurs, and read registers 0x0824 and 0x1044. These will both tell us what kind of errors are getting reported by the controller that are causing the device to go into bus off state.

    Regards,

  • Hi Eric,

    Ok this is normal operation of whole BUS.

    Our protocol works like this. Master is always asking for data. And other nodes send necessary data. Everything is working fine until error occurs. The wave  form looks like this.

    This are flags which are triggered.

    Hope it helps.

    Regards.

    Seba

  • Seba,

    Thank you for the quick info, is it possible to zoom in on the CAN bus waveforms? I wanted to see if there were any indications on the waveforms that would show why errors might be occurring. Also, can you get the register information from register 0x1044 in the case where errors occur?

    The register information from the two you provided isn't indicative of what may be happening to cause the error state, other than the EW bit saying that there's a error warning. Reading register 0x1044 will show what specific errors are occurring.

    Regards,

  • Eric,

    Yes of course sorry.

    Top wave is good communication bottom is err.

    When i read PSR register:

    Good COM: 0x00000708

    Bad COM: 0x00000710 or sometimes 0x00000750

    Hope this helps.

  • Hi Sebastijan,

    Eric's out today, but I wanted to give you a bit of feedback here.

    The Bad COM reading of 0x0750 has the Error Warning flag [bit 6] set. This indicates that at least one error counter has reached its limit. As Eric described above, to decrement this counter the device must receive an error-free CAN frame. Once the error counter has decremented below this limit, this status flag will clear. Because this bit seems intermittent, I suspect that some of the CAN frames are still registering as errors, increasing the counter above the limit and resetting this flag.

    The other difference between the good and bad values is the Activity status. During the good COM, the CAN module is in an Idle idle state (4:3 = 01). During bad COM, the CAN module is in the Receiver state (4:3 = 10).

    The rest of this register mostly refers to CAN FD information. Based on the waveforms showing classical CAN frames, it makes sense these values are cleared (the 0x7 is the default value of those bits).

    We'll get back to you with more comments on Monday. I hope you have a nice weekend.

    Regards,
    Eric Schott

  • Hi,

    Thank you very much for answer.

    I also sweep quickly through datasheet about different bit meanings. I appreciate again for detailed explanation about different flags.

    Is it possible to get out of this error to normal operation again? Without hard reset of device?

    Regards.

    Seba

  • Seba,

    How the bus off state is typically cleared is explained in the Bosch MCAN user's manual. The controller reporting the bus off state must observe 129 occurrences of bus idle state (11 consecutive recessive bits) before resuming normal operation. In the description of the Bit0Error in register 0x1044:

    "During Bus_Off recovery this status is set each time a sequence of 11 recessive bits has been monitored. This enables the CPU to monitor the proceeding of the Bus_Off recovery sequence (indicating the bus is not stuck at dominant or continuously disturbed)."

    So this can be used to monitor to make sure the buss off recovery sequence is happening at all.

    Please let me know if you have any other questions.

    Regards,

  • Eric,

    I don't think that is related to BUS-OFF state. Because during good communication PSR = 0x708. After ERR occurs PSR jumps to 0x750 for few few second after that PSR is 0x710. 

    I swiped through datasheet  PSR = 0x750 indicate that a some err counter is exceeded limit (bit 6). If PSR = 0x710 that means tcan is in receiver mode (bit 4:3 = 01). There is no indication of BUS off state bit.

    Is it possible to recover from this state without hard reset? 

    Because if i unplug err node for network and re plug everything seams ok.

    Regards.

    Seba

  • Seba,

    Going back to the original post, you say that you short CANH and CANL to ground, see the interrupts assert which is correct. But you aren't able to get the nINT pin to properly go high again, is that correct? In my initial suggestion you said you weren't able to clear the interrupts, can you tell me how you attempted to clear the interrupts?

    Also, thank you for your patience in this, Dallas is experiencing random power outages due to the weather, so there will continue to be delays in our responses.

    Regards,

  • Eric,

    Yes you are correct. 

    Basically when i want to clear my interrupts i call "TCAN4x5x_MCAN_ClearInterrupts(&mcan_ir);".

    The MCAN jumps in interrupt again but it is stating same error. Should i clear something else also?

    Regards.

    Seba

  • Seba,

    Removing the condition that caused the interrupt in the first place, then clearing the interrupt by writing a 1 to it should make the interrupt go away and the nINT pin go high.

    When you sent over the interrupt register information, the interrupts thrown were CAN error, and CANSLNT, meaning that the CAN bus was idle. The MCAN interrupts were new message received, high priority message, and error warning. The error warning is the result of one of the error counter in the CAN controller exceeding a value of 96, and this likely happened when you shorted the CAN bus to GND and transmitted messages.

    All of that being said, these interrupts should be 0 if you removed the condition and then write a 1 to them to clear. Is it possible for you to manually write FFFF to the interrupt registers rather than using the function and seeing if that works?

    Regards,