• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 339 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.

TCAN1043A-Q1: WUP in the middle of go to sleep, will INH drop at all?

David Shumate
Expert 7905 points
Part Number: TCAN1043A-Q1

Hi Team,

If CAN is in the middle of going to sleep (specifically because of UV_Vio for this case) and a WUP is received will INH release for any amount of time before going back up?

I'm specifically trying to understand if there is risk of INH never dropping/resetting the system in the above situation.

There are two areas I want to focus on with this situation:

- UV_Vio timer just started and a WUP is received

- UV_Vio timer just expired when the WUP is received 

Best,

David

  • 0
    TI__Guru 53555 points

    Hi David,

    Good question here, I understand that this is important in the case where a reset via INH cycling is desired. 

    For the first case, since the UV_Vio timer does not expire the device remains in the same original mode for the duration of this scenario. So if this mode has INH high (such as Normal mode), then the INH signal will remain high as long as the UV_Vio event lasts less than tUV. 

    In the second case, since the UV_Vio timer expires the device will change into Sleep mode. At this time the INH signal will go high impedance and begin to discharge through any external load. At this point, the INH fall time and the input threshold of whatever is receiving this signal will determine the timing that will cause the system to reset. If the INH signal is allowed to discharge under the voltage regulator's input threshold the system will be unpowered and a reset will occur. If a WUP is received before this discharge can occur, the INH signal will be driven high by the transceiver and the system may not reset. For this reason it is important to externally load the INH signal (100k-ohm pull-down recommended) to ensure a reasonable fall-time for this signal. 

    Keep in mind that in the unlikely event that a WUP wakes the transceiver from Sleep mode before the INH signal can fall and cause a reset, there is another failsafe tool that can reset the system later on. When the transceiver wakes from Sleep mode into Standby mode, the SWE timer starts. If the device is not placed into Normal mode (which will require Vio to be present) the transceiver will automatically return to Sleep mode after tINACTIVE. This way, if there is some issue with Vio, the system will not remain in Standby mode indefinitely as the transceiver will continuously try to return to its lowest power state in this case.

    Let me know if you have any more questions.

    Regards,
    Eric Schott

  • 0 in reply to Eric Schott1
    TI__Expert 7905 points

    Hi Eric,

    Thanks! One clarification. For the first case we receive a WUP but Vio does not actually come back up. If it's getting wake commands but not clearing the UV flag does this reset the UV timer?

    In the second case, do you know if there is a minimum time the INH will be high impedance before coming back up? With a minimum time we can size external pulldown appropriately.

    Best,

    David

  • 0 in reply to David Shumate
    TI__Guru 53555 points

    Hi David,

    Wake commands to not clear the UV timer. The only thing that halts this timer is the supply moving back above the UV threshold or the device moves to Sleep mode.

    The INH signal will be high impedance from the time of the mode transition to Sleep mode (tUV times out) and when the WUP is recognized. Because it's unknown when the WUP will occur (may be immediately after the mode transition) there is no way to catch all of these events. This is the reasoning behind the SWE timer. The recommended 100k-ohm value is a good compromise between reasonable fall-time (also dependant on signal line capacitance) and leakage in an active state. 

    Regards,
    Eric Schott

  • 0 in reply to Eric Schott1
    TI__Expert 7905 points

    Hi Eric,

    The concern is if we have constant communication on the CAN bus I'm worried that everything will look like a WUP so even if we timeout the SWE timer again we get a WUP instantly again and I'm worried about a situation where we are just blasting the CAN bus constantly and we can never get INH to actually drop.

    Is there not a deglitch time between getting the wake up command and when INH comes up that maybe we can dial into?

  • 0 in reply to David Shumate
    TI__Expert 7905 points

    Eric,

    Maybe a quick EVM test might be the easiest way to approach this. Do you think you could try the above situation where you just blast CAN data on the bus and see if you catch any situation where INH doesn't drop?

  • 0 in reply to David Shumate
    TI__Guru 53555 points

    Hi David, 

    I'm afraid that with the amount of variance that will exist from system-to-system, an EVM test will not be sufficient to cover all possible based. The main reason I'm thinking is that in most systems there will be significant down-time on the bus (interframe spacing) where there will be no activity from a WUP viewpoint. At this point it is still a statistics question to see how many cycles it will take to land in one of those spaces and get a proper reset. At its core, the UV timer is not intended to be used as a reset generator in the case of a fault event in an active system. Rather, it is a failsafe mechanism to ensure the faulty node does not remain powered in an otherwise inactive system (i.e. prevents battery drain while parked). 

    In order to guarantee a rest in an active system, I would recommend the use of a dedicated monitoring feature such as a watchdog. This would be able to monitor the system state and generate the reset condition when it detects an issue. The TCAN1144 is a similar CAN transceiver to TCAN1043A that offers a watchdog feature. Implementing this to solve the issue we're discussing would require some design changes (as well as a SPI connection to the transceiver), but would allow us to cover this edge case. Does this sound like it would be worth exploring? 

    Regards,
    Eric Schott