TCAN1145-Q1: TCAN1145 transceiver INH wake-up pin does not work

Alan,

In your tests, did you short INH to the power supply with both problem devices? This may have caused damage to the pin if the device is able to communicate but INH still isn't high. Instead of forcing INH high, when the controller goes into bus off, it's likely that the CAN transceiver is also going into a fault condition due to its own error counter. Check the ERR_CNTx bits, and all the interrupt registers once this occurs, clear the interrupts, then try again to wake the device.

Regards,

Eric Hackett 

Hi Eric，

Based on your analysis, is the phenomenon a Fail-safe Mode?

But the customer checked the code and found that our previous initialization configuration turned off the "failure protection mode";
What other reasons could cause INH to remain low and unable to wake up?

Hi Eric，

Registers dumped by the client:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/TACN1145_5F00_Abnormal_5F00_dump2https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/TCAN1145_5F00_Normal_5F00_dump

Hi Eric，

The customer has another question about this problem. Please help confirm it:
1. Looking at the previous code, we have turned off "FSM mode" and "SWE count". Why does the problem of "transceiver cannot wake up, INH is always low" still occur?
2. The root cause of this problem is still not clear. What state is the transceiver in when the problem occurs?
3. Comparative testing found that it was reset after clearing the interrupt (51h, 52h, 53h). Why does the wrong interrupt cause the transceiver abnormality? Which specific interrupts will cause such anomalies?

Anyone can help？

Alan,

Are they using selective wakeup (WUF) or WUP? 

I cannot open the files you included, what format are those files? Selective wakeup may not be enabled if those interrupts are not cleared.

You said INH is always low even though the communication is normal, is the transceiver in normal mode at this time? Can you read the MODE_SEL bits? As Eric said, if in normal mode the INH is still outputting low that means the pin may be damaged due it's short to a power supply. Does that happens on the abnormal chips that you short INH to power supply, or all other units?

Regards,

Sean

Hi Sean，

The customer uses a specific message to wake up, which should be WUF
The dump file is in Txt format and can be opened with Notepad or Notepad++;

Alan Xia said:

3. Comparative testing found that it was reset after clearing the interrupt (51h, 52h, 53h). Why does the wrong interrupt cause the transceiver abnormality? Which specific interrupts will cause such anomalies?

After the customer used the reset operation here, it became normal, so I don’t think the chip is damaged. It may be that the customer does not understand the function well enough. So I need your help to find out what caused it.

Alan,

The "abnormal" device has following interrupts set:

When those interrupts set, the selective wakeup cannot be enabled, that's why they are unable to wake up after sleeping.

However, I don't have an explanation for why INH is still low during normal communication, so they are using the WAKE pin for a local wakeup, and after transition to normal mode, that INH is still low? 

Can they share CAN bus and INH waveforms?

Regards,

Sean

Hi Sean,

The customer is currently considering how to fundamentally solve this problem, and there are still several questions that need to be confirmed:
1. Which specific interrupts will cause "unable to enable selective wakeup"?
2. When the CAN transceiver is in sleep mode, a bus error occurs. Will these interrupts be triggered?
3. If we disable these interrupts, will it not affect selective wakeup?
4. If these interrupts are blocked, will there be other effects?
The customer is now considering two solutions:
Solution 1: Before triggering the CAN transceiver to sleep, clear all interrupts, and then the MCU goes to sleep;
But the premise of this solution is that the CAN transceiver cannot enter an error interrupt when it is in sleep mode. If the CAN transceiver also enters an abnormal interrupt in sleep mode, then the MCU is already asleep and the CAN transceiver cannot be awakened, then there is no way to recover;
Solution 2: Turn off all interrupts that can cause WUF to fail to wake up, but whether this solution is feasible, which interrupts need to be blocked, and whether blocking interrupts has other effects, I need your professional advice.

Hi Alan,

Maybe I should not say "unable to wakeup", what I mean is if those interrupts are set, you can not enable the selective wake up. There actually will not be any interrupt that blocks the transceiver from waking up in sleep mode.

Looking at the register maps from "abnormal" device, MODE_SEL shows the transceiver is in normal mode, that means the transceiver is actually awakened. INH should be high in normal mode, however I don't have an explanation why it could still be low in normal mode but the CAN communication is going on. That's why I'm asking you to share the waveforms to see how CAN bus is behaving when INH is outputting low. 

1. See datasheet 10.4.5.1

2. Frame error counter will increment, once reach the threshold, frame overflow interrupt will set and the transceiver will be waked up. See 10.4.5.7

3. It will, disable those interrupts can only affect nINT pin output that reflecting those interrupts.

4. What do they mean by "blocked"? Disabled? It will only affect nINT output as described in 3

Solution 1 is preferred, we recommend to clear all interrupts, set selective wakeup in standby mode, then go to sleep mode. Interrupts will not blocking the transceiver from wake up.

Regards,

Sean

Hello,Alan Xia,Have you solved your problem? I had a similar problem, and it was very similar. Also abnormally sleep and unable to wake up .I didn't solve it either.And I always clear INT before I go to sleep .Here is the link to my question: 

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1443360/tcan1145-q1-sleep-wake-up-problem-in-noack-condition

If you have solved it, please let me know,Thanks.