• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 244 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.

TCAN4550: nINT latches active for unclear reason; possibly WUP-related

Torin
Prodigy 30 points
Part Number: TCAN4550

We use the TCAN4550 in an application where we do not require low power modes or wake events. On chip initialisation, we disable the watchdog and the WAKE pin functionality. Neither WAKE nor nWKRQ are connected to our processor.

We find that after some time in use on the bus, the nINT pin becomes held low despite everything being ostensibly normal. The processor is still able to TX frames, but it is no longer receiving interrupt requests, which breaks the RX logic. Every time this latching occurs, we've found that the CANINT bit is set in IR, which according to the datasheet indicates detection of a WUP event.

Here is our interrupt handling routine, as a sanity check: upon a falling edge on nINT, the processor clears its pending-interrupt flag on that pin (so further edges are guaranteed to be registered), reads IR (0x0820) and then immediately writes 0xFFFFFFFF to it. If SPIERR was set in IR, it writes 0xFFFFFFFF to Status (0x000C). If M_CAN_INT was set, it reads M_CAN IR (0x1050), writes 0xFFFFFFFF to it, and proceeds to handle the M_CAN interrupt request.

Why could the nINT pin be latching like this, and is it actually related to WUP detection? Why are we detecting WUP at all, if so? We never put the chip into Sleep mode. After power-on / reset, we enter Standby mode, configure the chip, and enter Normal mode for the duration of the application. The failsafe feature is also disabled (as is default).

Many thanks,

Torin

  • 0
    TI__Mastermind 47895 points

    Hi Torin,

    Welcome to E2E! Thanks for your detailed description of the issue you're encountering with TCAN4550. 

    This behavior definitely sounds odd, as a CANINT interrupt from a WUP should only be possible when the device is in Standby or Sleep mode. Would it be possible to read the Mode Control register (h0800) after this interrupt is detected? I would like to see what mode the device reports it is in when this occurs. My suspicion is that some event such as thermal shutdown or undervoltage has caused the device to switch automatically into a low power mode. 

    It's strange that the interrupt appearing to cause this is CANINT. Could you share the whole state of the interrupt register (h0820) when the nINT assertion persists? I would like to see what other interrupts, if any, are asserted that may give us an indication of what's happening. 

    The interrupt handling routine you outlined here should be sufficient to clear the nINT pin back high in most typical cases. However, if the interrupt source persists after the flags are cleared, the nINT pin may remain asserted. My recommendation would be to check the state of this pin before exiting this routine to make sure that nINT has been cleared. If it is still asserted (subsequent interrupts will not be edge-detectable), the routine could repeat the attempt to clear these interrupts. 

    In summary, please try the following to see if we can narrow down what is causing this issue:

    • Share state of mode control register (h0800) when nINT assertion persists
    • Share state of interrupt register (h0820) when nINT assertion persists
    • See if checking the state of the nINT pin during the interrupt handling routine shows any other interrupt persists during this state.

    Regards,
    Eric Schott

  • 0 in reply to Eric Schott1
    Prodigy 30 points

    Hi Eric,

    Thanks a lot for getting back to me. I am currently trying to reproduce the problem with this extra logging in place, but this issue is intermittent so it may be some time.

    In the meantime, would you be able to elucidate exactly what interrupt sources can persist after clearing the interrupt register?

    Would I be right in saying that the flags in bits [7:0], which are not writable and cannot be masked in the Enable register (h0830), should contain the culprit? I always handle M_CAN_INT [1] and SPIERR [3] correctly, which leaves VTWD [0], CANERR [5] and GLOBALERR [7]. I can ignore GLOBALERR as it just indicates the presence of any fault (correct me if I am wrong), and CANERR should be cleared since I clear both CANDOM [8] and CANSLNT [10] in the register.

    VTWD, I assume, should be handled by issuing a device reset.

    I suppose, also, the culprit could be SPIERR being reasserted due to SPI-related faults occurring during the clearing of nINT itself...

    Thanks again. Kind regards,

    Torin

  • 0 in reply to Eric Schott1
    Prodigy 30 points

    Hi Eric,

    I managed to reproduce this eventually. The interrupt register simply read 0x000004A2:

    • CANSLNT
    • GLOBALERR
    • CANERR
    • M_CAN_INT

    The chip remained in Normal mode.

    I have to assume CANSLNT and/or M_CAN_INT became apparent while the processor cleared the interrupt source which originally asserted nINT, so I will improve my interrupt handler as you suggested. It is not surprising that it takes a long time to reproduce, given the likelihood of such a race condition!

    Kind regards,

    Torin

  • 0 in reply to Torin
    TI__Guru 60042 points

    Torin,

    It's great to hear you've been able to reproduce and that you now have a path to resolution. Please let us know if you have any more questions or need any more assistance.

    Regards,