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.

TCAN1145-Q1: TCAN1145 wake up accidentally

Part Number: TCAN1145-Q1

Tool/software:

Hi Team

Customer is using TCAN1145 in their OBC product. 

There is an issue in their system: Any frame sent by the host may accidentally wake up the auxiliary source. they configured fixed frame to wake - up, and non - fixed frames will not trigger wake - up.

Configured SWCFG=1, it will change to 0 when accidentally wake up.

 

The following is schematic:

 

And the customer has ruled out the following: Wake - up via the WAKE pin; the power supply voltage of BAT12V fluctuates between 12.9V - 12.12V, which is within the normal range; both SPI communication, reading and writing are normal.

Their question is :what kind of situation that SWERR  will be read as 1( normal prototype is 0)? how to address this issue? 

 

  • Hi Harry,

    There are two situations will set SWERR, as described in datasheet.

    • SW_EN is set 1 but SWCFG is 0
    • Frame overflow cause selective wakeup being disabled

    The accidental wakeup in this case is due to the frame overflow, see 10.4.5.2 for details. They can check the FRAME_OVF interrupt whenever there is an accidental wakeup to confirm.

    Are they sending CAN FD frames when device is in sleep mode with selective wakeup enabled?

    Regards,

    Sean

  • Hi Sean

    1:I would like to inquire whether the INH pin transitions to a high level when the FRAME_OVF event occurs.
    2:Can I turn off frame error detection when I enter sleep mode? I don't want a FRAME_OVF event to happen.
    3:When a FRAME_OVF event occurs in sleep mode (SW_EN=1), will it trigger the chip to enter Standby mode?

    Regards,
    LingZhi



  • Hi Lingzhi,

    1. Yes it will wake up and change to standby mode, thus INH will output high.

    2. Unfortunately frame detection cannot be disabled in selective wakeup mode, this is a requirement by the ISO 11898-2. The partial networking requires the node to be waked up when it receives too many error frames.

    3. Yes, it will enter standby mode.

    When the chip enters sleep mode with selective wakeup enabled, are you still sending CAN FD frame? Please note that only classical CAN frame is supported by selective wakeup, thus any CAN FD frame will be recognized as an error frame. You can set this bit to 1 so CAN FD frame will be ignored by the error counter.

    Regards,

    Sean

  • Hi Sean,

    Thank you for your professional answer.

    I understand that CAN FD isn’t supported in selective wake-up. Thanks for the heads-up!

    Regards,

    Lingzhi

  • Hi Sean,

    Thank you for your answer.

    We have analyze the situations which set SWERR, we found that:

    1. FRAME_OVF frame overflow: when accidental wake-up happened and SWERR is set 1, before clear interrupt flag, we read FRAME_OVF interrupt flag in register 51h-bit3, value is 0, and read frame error cnt in egister 45h, max value is 1, not reach the threshold value 0x1F in register 46h; so frame overflow may was not happened ever.
    2. SW_EN = 1 and SWCFG = 0: Before entering the sleep mode, the register related to selective wake-up is successfully configured, and the SWCFG is written as 1 in the last step, and then TCAN1145 is configured to sleep mode. However, selective wake-up is still invalid, after accidental wake-up happened and SWERR is set 1, the SWCFG value is read as 0. Are there any errors in this step? And we don't know why the register value has been changed? Could you please help us? Thanks.

    And as for CAN FD frame, when in sleep mode, there are no CANFD frames in the CAN bus, only classic CAN frames (ID 11 bits), which triggers the above problem.

    Regards,
    John

  • Hi John

    1.About the the configured of selective wake-up ,you can refer to the following two sources.
    English Version:How Selective Wake Enables Partial Networking (Rev. B)
    C
    hinese Version:选择性唤醒如何实现局部联网 (Rev. B)

    Regards,

    Lingzhi

  • Hi John,

    When SWERR is set, it indicates that there is an issue with the selective wake configuration that will need to be resolved before the device can enter sleep mode with partial networking enabled. The set of SWERR will disable the selective wakeup thus any CAN frame on the bus can be a WUP to wake up the device. In this case, the selective wake registers should be reconfigured to ensure that all of the register values are at their appropriate values. This configuration should end by writing 1 to the SWCFG to lock in the current configuration.

    Could you check the interrupt registers before moving to sleep mode to ensure that the SWERR flag has not been set to indicate a problem with the current configuration? Also, after the accidental wakeup, will your software write to any selective wake configuration registers?

    Regards,

    Sean

  • Hi Sean,

    We have checked the following items:

    1. Before moving to sleep mode, add a step that clear all interrupt registers (write value 0 into rsgister 51h, 52h, 53h), then selective wakeup is normal; then restore the previous code, the selective wakeup is invalid; so there is a conclusion that when some issues happened and a  SWERR flag is set, we need to clear the interrupt flag in register before moving to sleep mode, which ensures the selective wakeup will work properly next time. 
    2. There is a new question, We made a comparative test using the same hardware and the same software(the software without clearing SWERR interrupt rigister). We find some of the prototype samples are always normal(with selective wakeup normal and no SWERR flag set ever), but some of the prototype samples are always abnormal(with selective wakeup invalid and the  SWERR flag set everytime), we do not know why, could you please help us or give us some ideas?
    3. Our software only write selective wake configuration registers at the time when before moving to sleep mode, and each time, the addresses and the values of the registers configured  are the same, and not related to different reasons of wakeup.
    4. As my previous reply, before moving to sleep mode, SWCFG is written as 1 at the last step, after accidental wake-up happened and SWERR is set 1, the SWCFG value is read as 0. Based on the tests and conclusions today, we still have this question that what is the timing and logic between SWCFG and SWERR? Who influences whom? 

    Thank you!

    Regards,

    John

  • Hi John,

    Yes it is always recommended to clear interrupts before going to sleep mode. 

    Interrupt flags like CANINT, FRAME_OVF will not be set again if it's already 1 before entering sleep mode, once there's a valid wake up source, it won't automatically return to 0 then set 1, it is possible for the WUF receiver to miss the WUF if the interrupts are not cleared thus it will be blocked in sleep mode and cannot wakeup.

    After you write SWCFG = 1 as the last, please make sure to read this bit again before entering selective wakeup mode (set SW_EN =1), if the selective wakeup is not configured correctly, the SWCFG will return to 0. The SWERR will set to 1 in the case SW_EN =1 but SWCFG = 0.

    Regards,

    Sean

  • HI Sean,

    Thank you for helping us! We will add the step that clear all interrupt registers (write value 0 into rsgister 51h, 52h, 53h) to solve this issue.

    We have double-checked, and we are sure that in our current software(without clearing SWERR interrupt rigister), after we write SWCFG = 1 as the last, we read this bit again before entering selective wakeup mode (set SW_EN =1), everytime the SWCFG value we read is 1, correctly. But then selective wakeup invalid,  accidental wakeup happened, the SWCFG we read became value 0.

    So is this means when SWERR interrupt flag not be cleard, even if SWCFG is written to 1 and read as 1, the selective wakeup will still be invalid, after moving to Sleep Mode, the SWCFG will be set to 0 automatically and trigger a SWERR bit? 

    Regards,

    John

  • Hi John, please see my reply on email.

    Regards,

    Sean