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.

TCAN4551-Q1: TCAN4551-Q1 wakeup from sleep mode.

Part Number: TCAN4551-Q1

Tool/software:

Hi,

I am facing an issue while dealing with TCAN into low power mode. I have used an example which puts my TCAN into sleep mode using this Api " TCAN4x5x_Device_SetMode(TCAN4x5x_DEVICE_MODE_SLEEP);" . After this I receive an interrupt on my 'nINT' pin.

while debugging i got that I am getting under voltage supply interrupt which is 'UVSUP', which is expected if i refer your note from the datasheet:

"When entering sleep mode it is possible for the TCAN4551-Q1 to assert an interrupt due to UVCCFLTR event as the LDO is powering down. This interrupt should be ignored or can be masked out by using 16'h830[22] before initiating the go to sleep command." (https://www.ti.com/lit/ds/symlink/tcan4551-q1.pdf)

For now i am ignoring this interrupt in sleep mode.

The issue i am facing is, while in sleep mode if i send any data to TCAN from any CAN simulator (ex: PCAN) then i don't receive any wakeup request interrupt, but as soon as i disconnect my PCAN i am getting wakeup request as well as CANDOM  ( CAN Stuck Dominant) and CANINT  ( Can Bus Wake Up Interrupt ). 

My interpretation from this is, I am not getting a proper wakeup pattern. 

Please help me to resolve this issue and suggest the proper handling if i am doing anything in a wrong manner.

Thanks.

  • Hello Vinayak,

    while debugging i got that I am getting under voltage supply interrupt which is 'UVSUP', which is expected if i refer your note from the datasheet:

    The VSUP supply should always remain ON and above the UV threshold under all operating conditions.  The UVSUP interrupt bit should not get set when entering Sleep Mode.  This note is specific to the UVCCFLTR bit which is the internal LDO that gets powered off during Sleep Mode which can cause this interrupt bit to get set.

    Is the VSUP supply being disabled during Sleep Mode, or does it remain on?  Also, what is the status of the VIO supply during sleep mode, is it turned off or does it remain on?

    TCAN4x5x_Device_SetMode(TCAN4x5x_DEVICE_MODE_SLEEP);" . After this I receive an interrupt on my 'nINT' pin.

    The digital core is disabled in sleep mode, so the device can't generate a hardware interrupt once the device is in sleep mode.  Because the nINT pin is an open-drain pin that requires and external pull-up resistor to the VIO rail, are you seeing the nINT pin go low as a result of the VIO voltage becoming disabled in sleep mode?

    My interpretation from this is, I am not getting a proper wakeup pattern. 

    Can you monitor the CAN bus signals with a scope to determine whether the signals meet the WUP requirements?  The CANDOM bit would indicate there is a voltage difference between the CANH and CANL pins for a time period longer than the Dominant Time Out specification (1-5ms).

    Regards,

    Jonathan

  • Thanks Jonathan for your feedback, I will analyze the CAN bus and share my observations to you.

    Regarding this reply:

     The VSUP supply should always remain ON and above the UV threshold under all operating conditions.  The UVSUP interrupt bit should not get set when entering Sleep Mode.  This note is specific to the UVCCFLTR bit which is the internal LDO that gets powered off during Sleep Mode which can cause this interrupt bit to get set.

     Is the VSUP supply being disabled during Sleep Mode, or does it remain on?  Also, what is the status of the VIO supply during sleep mode, is it turned off or does it remain on?

    The reason i was ignoring the UVSUP because, when i look into the datasheet it defines  UVSUP interrupt is caused because of Under Voltage VSUP and UVCCFLTR. Under Table 18. Interrupts Field Descriptions.

  • Hi Vinayak,

    Yes, you are correct, I had written my comments based on the thought there were separate bits just like UVIO and UVSUP, but I didn't recall that UVCCOUT shares a bit with UVSUP.

    I will wait for your CAN bus observations that will hopefully provide some answers to the issue.

    Regards,

    Jonathan