TCAN4551-Q1: State clarity in test mode

Hello G T,

Can you help clarify what all is part of the "Network"?  I am assuming this is CANH, CANL, and maybe a power and ground for the transceiver. 

Can you also tell me about the TCAN4551 and MCU power connections?  How are the VSUP and VIO rails supplied and are they both on and stable while disconnected from the network?

Do you have the FAIL_SAFE_EN bit set to '1' in register 0x0800[13]?  If so, when you disconnect from the CAN bus, the TCAN4551 may enter Sleep Mode after a period of time due to the CAN bus being "silent" or no activity.  If the device does enter Sleep Mode, then there won't be SPI communication.  However, this usually takes several minutes for the device to enter Sleep Mode.

When you disconnect from the CAN bus, is the MCU and TCAN4551 still trying to send/receive any CAN messages?  Is SPI activity still happening between the MCU and the TCAN4550 while it is disconnected from the network?

Can you monitor the nWKRQ or INH pins while doing this test to see if there is any state change on them?  If the device is entering Sleep Mode, these pins will have a state change.

What type of clock are you using for the TCAN4551?  Is it a crystal? 

Regards,

Jonathan

Can you help clarify what all is part of the "Network"?  I am assuming this is CANH, CANL, and maybe a power and ground for the transceiver. 

Yes, that is correct.

Can you also tell me about the TCAN4551 and MCU power connections?  How are the VSUP and VIO rails supplied and are they both on and stable while disconnected from the network?

Both are powered from the system, not the bus, and are not interrupted by the network being disconnected.

Do you have the FAIL_SAFE_EN bit set to '1' in register 0x0800[13]?  If so, when you disconnect from the CAN bus, the TCAN4551 may enter Sleep Mode after a period of time due to the CAN bus being "silent" or no activity.  If the device does enter Sleep Mode, then there won't be SPI communication.  However, this usually takes several minutes for the device to enter Sleep Mode.

No, FAIL_SAFE_EN is set to 0.

When you disconnect from the CAN bus, is the MCU and TCAN4551 still trying to send/receive any CAN messages?  Is SPI activity still happening between the MCU and the TCAN4550 while it is disconnected from the network?

Yes, we have a heart beat that the MCU transmits periodically and even when disconnected I still see SPI chip select activity periodically.

Can you monitor the nWKRQ or INH pins while doing this test to see if there is any state change on them?  If the device is entering Sleep Mode, these pins will have a state change.

Both nWKRQ and INH pins stayed low all the time, even when there is communication and I am not seeing any change in their state, even when communication stopped. These two pins are just left floating on the board.

What type of clock are you using for the TCAN4551?  Is it a crystal? 

Yes, it is using a 20 MHz xtal.

Thanks for the additional information. 

What is the value of the Inhibit Disable (INH_DIS) bit in the configuration register 0x0800[9]?  By default the INH pin is enabled and should be driven High (to VSUP voltage level) when the device is powered on.

If the VSUP and VIO are ON and stable, and nWKRQ should be Low and INH should be High.  If you are seeing INH Low when INH_DIS = 0, then this would be unexpected.

And I want to make sure I understand that the MCU is sending a heartbeat SPI signal to the TCAN4550 and you can see the chip select toggle, but there is no response from the TCAN4550.  And the general issue is that TCAN4550 stops responding to SPI when you disconnect the transceiver from the CAN bus.  Is this correct?

The two things I don't understand is why the INH pin is Low when the VSUP is stable and the device has not been placed into Sleep Mode, and why SPI communication fails when the CAN bus is disconnected from the external transceiver's CANH and CANL pins.  Neither of these two observations are normal if VSUP is on. 

Can you verify with a scope that there really is no disruption to the VSUP, VIO and VCCOUT supply rails before, during, and after you have disconnected the CAN bus?

Is it also possible to monitor any SPI data to see when it stops working during this process?

Regards,

Jonathan

What is the value of the Inhibit Disable (INH_DIS) bit in the configuration register 0x0800[9]?  By default the INH pin is enabled and should be driven High (to VSUP voltage level) when the device is powered on.

If the VSUP and VIO are ON and stable, and nWKRQ should be Low and INH should be High.  If you are seeing INH Low when INH_DIS = 0, then this would be unexpected.

I changed the default setting and configured INH_DIS bit to 1. My intention was to disable this, since INH is not connected.

And I want to make sure I understand that the MCU is sending a heartbeat SPI signal to the TCAN4550 and you can see the chip select toggle, but there is no response from the TCAN4550.  And the general issue is that TCAN4550 stops responding to SPI when you disconnect the transceiver from the CAN bus.  Is this correct?

Yes this correct. Also, when I re-connect the transceiver to the CAN bus, I can see data from CAN bus network(Other ECUs) when I probe tcan's RxD line, however there is no SPI communication from TCAN4551(to the MCU) or any data being sent on TxD line(to the transceiver).

I will probe VSUP, VIO and VCCOUT supply rails and update those findings.

I will try to monitor SPI data, but it looks like the SPI communication from TCAN4551 stops as soon as the transceiver is disconnected from the CAN bus network. As soon as I disconnect the transceiver, there is no activity on the SPI CS line(to the MCU) until the periodic heart beat that MCU sends to TCAN4551(to send across CAN bus).

Thanks. 

For SPI communication, the device needs VSUP to power the device and digital core, VIO to power the clock circuit and set the voltage level translators for the SPI signals, and the device must be in Standby or Normal mode. 

Registers in the 0x0000 to 0x000C (Device ID, Revision, and Status) work off of the SPI Clock domain and don't require the 20MHz crystal to be operational.  The power still needs to be stable.  Any SPI related errors should be visible in the Status (0x000C) register.

All other device registers in the 0x0800 to 0x08FF and 0x1000 to 0x10FF address space require the 20MHz crystal to be active to power the Digital Core and MCAN Controller.  Therefore if there is some issue with either the power or the 20MHz crystal, SPI transactions to these registers will fail and the device can't send any CAN messages.

Can you try to also read registers 0x0000 and 0x000C as part of your heartbeat test loop as well as the Mode Configuration and Interrupt Registers (0x0800, 0x0820 and 0x0824).  You should always see data on the SDO (MISO) signal when reading registers 0x0000 to 0x000C. 

Regards,

Jonathan

Hi Jonathan...I am yet to read the registers, but I just noticed that the clock to TCAN4551 is not a xtal oscillator, but it is a 20 MHz MEMS Oscillator. Not sure if this will have an impact on what I am seeing.

I will read the registers and let you know what I see.

Thanks for the help!

Hi G T,

I don't think it should matter as long as the clock is working.  If it is not working, then you could have communication errors.  I will wait for your update.

Regards,

Jonathan

Hi Jonathan,

I started periodically reading DEV IR, MCAN IR and PSR with device connected to the network. Then disconnected the device from CAN network and re-connected it back after a minute or so. As soon I started reconnecting the device, I noticed a change in PSR. It looks like the form error LEC is set. Then I noticed MCAN IR set Error Passive bit.

I am pasting part of my log here, I read these registers every 100ms.

[00:00:41.080,596] 3. DEV IR-0x0000008a MCAN IR-0x00000005 PSR-0x0000070f ---> device disconnected from CAN bus
[00:00:41.179,168] 3. DEV IR-0x0000008a MCAN IR-0x00000005 PSR-0x0000070f
[00:00:41.277,801] 3. DEV IR-0x0000008a MCAN IR-0x08000005 PSR-0x0000070a---> device re-connected to the CAN bus
[00:00:41.464,447] 3. DEV IR-0x0000008a MCAN IR-0x09800005 PSR-0x00000748
[00:00:41.562,957] 3. DEV IR-0x0000008a MCAN IR-0x09800005 PSR-0x00000748
[00:00:41.661,651] 3. DEV IR-0x0000008a MCAN IR-0x09800005 PSR-0x00000748
[00:00:41.760,223] 3. DEV IR-0x0000008a MCAN IR-0x09800005 PSR-0x00000748

These are the nominal bus timings I have set in tcan4551 configuration.

TCANNomTiming.NominalBitRatePrescaler = 2;
TCANNomTiming.NominalTqBeforeSamplePoint = 32;
TCANNomTiming.NominalTqAfterSamplePoint = 8;

Like I mentioned before, I am running TCAN4551 in test mode with TxD and RxD connected to  TI's ISO1044 isolated CAN transceiver. And the transceiver gets its Vcc2 from the CAN bus. So effectively I am powering on transceiver by re-connecting the device to CAN bus.

Do you see anything else, that is not obvious to me. Are there any other reasons for form error?

Thanks!

Hi G T,

The DEV IR-0x0000008a indicates that you have a SPI Error of some sort that would be indicated in the Status register 0x000C.  This could come from an error with the SPI driver causing some form of SPI protocol error, noisy or poor quality SPI signals, or from some clock related issue.  Bit 1 is also set to indicate that at least one bit in the MCAN IR register has been set.  What is the value of register 0x000C?  Do you commonly see SPI Errors?

The MCAN IR-0x00000005 indicates that you have lost messages in the RX FIFO.

After re-connecting to the bus, the MCAN IR-0x08000005 and then MCAN IR-0x09800005 coincide with the presence of the Form Errors reported in the PSR register.  You are interpreting the register data correctly

With a 20MHz crystal I am calculating your Nominal bit rate as 250kbps with an 80% sample point.  Is this correct?  If so, I don't see an issue with the bit timing configuration and the sample point should be OK. 

I am understanding your "We are using external caps for the tcan4551" statement to mean caps on the crystal and OSC1 and OSC2 pins.  Is that correct?  What are the value of those caps and have you done any optimization or tests on the clock circuit to make sure it is of an appropriate frequency and is stable?  Please see the TCAN455x Clock Optimization and Design Guidelines application note (Link).

Form errors can be caused by clock drift, or in this case a clock or node that has not had time to synchronize to the other clocks on the CAN bus.  If the 20MHz clock frequency is out of the acceptable tolerance, then the time quanta will be too long or short and eventually lead to sampling issues that could result in a Form Error.

If the device has not seen enough dominant to recessive transitions on the CAN bus, the CAN controller may not have had time to synchronize to the data on the bus and try to transmit at incorrect times resulting in errors.  Are you trying to immediately transmit a message when you reconnect to the bus, or just receive messages for a short period of time after reconnecting?

What is your Error Counter Register value during this time (0x1040)?  Are your errors coming from the Transmitter, Receiver, or both Error counters?

One possible explanation for both the SPI and CAN errors is a disruption to the system clock (crystal).  If this clock is disrupted, the TCAN4551 won't be able to respond to SPI or CAN messages.  This can occur if the clock circuit is not optimized and the device sees a low voltage signal on the OSC2 pin which causes the device to switch to single-ended clock mode.  Connecting OSC2 pin to ground is the method to enable the single-ended clock mode, but if the oscillation voltage on the crystal gets large enough that the lowest peak voltage drops below an approximate 100mV threshold, then the device can think the pin is grounded and momentarily switch to single-ended mode.  If this occurs, the device will not have a working clock and SPI and CAN communication errors could occur.  I'm not sure if this is applicable in your case but it is a possible reason that errors could occur.

Regards,

Jonathan

Thank you for the pointers, I will look into the clock optimization guidelines app note.

I am not seeing SPI bus errors regularly. If I power on the device after connecting to CAN bus, things seem to be working file. I am not seeing any errors. The only times when I seeing the issue is when,

I disconnect from CAN network and reconnect it back.

OR

I power on the device without connecting to bus and then connect to bus.

This leads me to looking at external transceiver that we are using. Like I mentioned before, I am running TCAN4551 in test mode with TxD and RxD connected to  TI's ISO1044 isolated CAN transceiver. And the transceiver gets its Vcc2 from the CAN bus. So effectively I am powering on transceiver by re-connecting the device to CAN bus.

The TCAN4551 controller is always powered on and initialized. The only thing that is getting impacted by the disconnecting the device from the bus is Vcc2 of the transceiver. It looks like the change of power on the transceiver side might be the cause for the errors. Does this make sense?

I will go through your response one more time and respond to your questions, but let me know what you think.

Are you placing the device into Standby Mode or setting the INIT bit in the MCAN Control register before disconnecting and reconnecting the device from the  CAN bus?

If you are simply removing the board from the CAN bus, this will power down the transceiver but the MCAN Controller in the TCAN4551-Q1 will still be in Normal Mode and expect valid data on the RXD and TXD signals.  I would expect you would see errors in this situation because the TXD and RXD data would not be from complete messages or controlled.

Regards,

Jonathan

That explains the behavior.

Currently I am not putting the device in Standby Mode or setting INIT bit.

I am just disconnecting the board from the CAN bus and seeing errors when I reconnect it back.

I will put the controller in standby and see, if that fixes these errors.

Thanks for your help.

Hi G T,

The device is expecting to be completely operational when in Normal Mode and INIT=0.  I think the issue is that the controller thinks there is a functional transceiver, when it has essentially been powered down.

Changing to Standby mode automatically sets INIT=1 to prevent it from communicating on the CAN bus when it is not capable of doing so.  But the device can also stay in Normal mode if you just want to set INIT=1.  The important thing from a CAN communication perspective is that INIT=1 when the device is disconnected from the CAN bus.

I will wait for your update.

Regards,

Jonathan

Great, thanks for confirming.  Let us know if there is anything else we can help with.

Regards,

Jonathan