TCAN1043-Q1: INH status

Hi Jasper,

What is the sec/div on the scope shot? I can't read it on the picture but the nSTB pin has to be held low until t_go_to_sleep expires which can be at most 50 us. So you will have to wait 50 us before the device transitions into sleep mode and the INH pin goes low.

Can you double check the voltage of your pins to make sure they have passed the correct thresholds (EN > VIH, nSTB<VIL)?

Can you also provide a schematic of your set up? During normal mode it looks like your pins are very noisy.

Best,

Chris

Hi Chris

Thank you for your reply.

For the abnormal snapshot which is 100ms/div, we can observe the nSTB goes low (nSTB = 0V) and EN is still at high (EN = 3V3), but the INH is at H for a long time (t_go_to_sleep >>> 50us).

The schematic as follows:

which nSTB and EN are controlled by the SoC, INH connects to the DC-DC enable pin.

We simulate that the module receives a lot of CAN data on the vehicle which has different duration time like 20ms/40ms and so on, so we can observe the signal on the CAN bus. 

Thanks.

Jasper

Hi Jasper,

The schematic is a little confusing. I see that nSTB is connected to an input called AR_BSS_RX. But EN is connected to an output called AR_MSS_TX. Both of these pins are inputs and they should be receiving a voltage level. 

If the CAN bus is constantly receiving communication then a WAKE request is being thrown and causing the device to enter standby mode. For the t_go_to_sleep time there has to be no traffic on the CAN bus or it will not enter sleep mode.

Try disconnecting the CAN bus and repeating your test. Let me know what happens.

Best,

Chris

Hi Chris

Yes, you are right, nSTB and EN are all input pins, just type error in schematic.

If I disconnect the CAN bus, the status of nSTB/EN/INH is right for me.

In the filed test, the CAN bus always receive communication from other parts which are all in the vehicle like ECU, BCM, EPS and so on, so we must solve this problem in this situation.

Thanks.

Jasper

Jasper,

If you are constantly receiving frames on the CAN bus then your device is constantly seeing wake up requests and it will not be able to sleep. This is part of the design of the device. How do you expect your device to know when it needs to wake up?

In practice you can receive a CAN frame and then immediately try to put your device to sleep but if another CAN frame is coming in the device needs to be ready to read it incase that message is for itself. The only way the device will sleep is if there are no new frames on the CAN bus. That is the intended design for this device and that follows the CAN standard.

If you are looking to break away from the CAN standard you can try designing your own protocol using RS-485 but that will be more work on the software side of things.

Best,

Chris