TCAN4550: CANSLNT error is received even if SWE is disabled

Hello,

An engineer has been assigned this question. Because of the holidays, TI E2E design support forum responses may be delayed through Jan. 3. Thank you for your patience.

Best,

Chris

Hello Sandy,

The CANSLNT flag is set when there are long periods of silence on the CAN bus or longer idle times than expected between messages.  This could indicate a fault condition such as a broken wiring harness or a short which would prevent messages from passing.  The timer is approximately 1 second. 

To avoid the CANSLNT error, you can either increase the amount of CAN messages on the bus to prevent the bus from being idle for longer than the tsilence spec.

Or you can disable the CANSLNT interrupt bit by setting the CANSLNT bit in the Interrupt Enables Register to '0'.  (Register 0x0830[10]).  The CANSLNT interrupt bit is set to '1' by default, so you will need to disable this bit if you do not want to to see this interrupt.  The CANERR and GLOBALERR bits are getting set because the CANSLNT bit is getting set.  Any other interrupts that you do not care about can also be disabled in the same way.  Register 0x1054 is the interrupt enable register for the MCAN interrupts.

Regards,

Jonathan

Hi Jonathan,

Thanks for your reply!

Jonathan Nerger said:

The CANSLNT flag is set when there are long periods of silence on the CAN bus or longer idle times than expected between messages. 

I've done some experiments and have been sending Rx packets at 100ms intervals and once the packets stop, ~1 second later the CANSLNT interrupt triggers, so I think that's what I've been seeing when sending on 1 packet of data. It confused me because the interrupt triggered like a Tx complete or new Rx data but now the behavior makes sense.

Moving on to the next question:

Jonathan Nerger said:

Register 0x1054 is the interrupt enable register for the MCAN interrupts.

For testing purposes, I currently have all interrupt enable bits in 0x1054 set to 1 and can't receive any MCAN interrupts. Are there any other settings that I have to configure for me to receive the interrupts?

Sandy,

When using register 0x1054, this allows the MCAN interrupts to be designated to one the m_can_int interrupt lines, which can then be indicated on GPIO1 or GPO2. If this is what you're trying to do, you'll also need to decide which interrupt line you want to use, 0 or 1, and enable this in register 0x1058 by assigning specific MCAN interrupts to their respective interrupt line. Then in register 0x0800 you can assign GPIO1 and/or GPO2 to MCAN interrupt line indication.

If you are just trying to enable the MCAN interrupts for the nINT pin, as long as the MCAN interrupt is enabled then then MCAN interrupts will be indicated on nINT. How are you determining if you are receiving MCAN interrupts or not?

Regards,

Eric Hackett 

Hi Eric,

I'm trying to enable MCAN interrupts for nINT pin but when a message is received into a Rx FIFO 0, the nINT pin isn't pulled low when I measure it with an oscilloscope (the nINT pin is working because I was constantly receiving interrupts triggered by the CANSLNT error). If I read register 0x1050, I see that the bit for new message in Rx FIFO0 is set to 1. When I read 0x820 however, the m_can_int bit isn't set which I assume is why I'm not getting an interrupt on the nINT pin.

I've done some tests and purposely sent more messages than my Rx FIFO0 can hold. The RF0L, RF0F, RF0W, RF0N bits are all set, but I still don't get an interrupt. I've also switched from receiving messages into FIFO0 to FIFO1, and don't get an interrupt either. This makes me think that none of the CAN related interrupts are reflected on the nINT pin. As I've mentioned before, I have all the CAN interrupts in 0x1054 enabled right now. Are there any circumstances where CAN interrupts will be ignored, or is there some other setting that I'm missing? Thanks!

Hi Sandy,

Can you share the final value of register 0x0830 and confirm that bit 10 has been set to '0' to disable the CANSLNT flag?

Can you also monitor register 0x0824 and 0x1050 and share their values?  They should match, but 0x0824 also reports the RX FIFO information and it is adjacent to register 0x0820 which allows both the device specific and MCAN interrupt bits to be read in a single SPI read that is 2 words in length.

If the MCAN interrupt bits are enabled in register 0x1054, the M_CAN_INT bit should get set when any of the enabled interrupt bits are set.  It is also possible to configure either the GPIO1 or GPO2 pin to act as an interrupt pin that will only reflect the enabled MCAN interrupts as Eric has mentioned.

Are you also reading and clearing the Status register 0x000C of any interrupt bits that are set?  What is the value you are reading for register 0x000C?

After reading and clearing all the Status and Interrupt registers, do you ever see the nINT pin go High?  Or does it always remain Low?  If any interrupt bit is not cleared, the nINT pin will remain Low and it will mask the pin from reporting any new interrupt bits that are set.  So we need to make sure that we are clearing all the set bits and can see the nINT pin go High.

Regards,

Jonathan

Hi Jonathan, 

My final value of register 0x0830 is 0xFFFFFBFF which confirms that the CANSLNT interrupt has been disabled and I no longer get interrupts on the nINT pin.

In my current design, I am using a polling thread to monitor the MCAN interrupt bits for Rx data. When I send data to TCAN4550, the values of the registers you mentioned are as follows.

Register 0x0824:0x10001

Register 0x1050: 0x10001

Register 0x000C: 0x0008 

Register 0x0820: 0x04A0.

Before clearing any of the interrupts, I measured the nINT pin and it is high, which indicates no interrupt has been triggered and any previous interrupts have been cleared. In our current design, GPO1 and GPO2 are not in use so they are not configured in any way. 

Hi Sandy,

So does this mean that everything is working for you?  Or are you still having some issues?  I just want to clarify your statement about no longer getting interrupts on the nINT pin.  Does this mean you are not receiving the new data interrupts either?

The nINT pin is active low and the logical OR of all bits in register 0x0820 and 0x0824 that are not masked, so the RF0N bit in register 0x0824 should be causing the nINT pin to get pulled LOW.

Regards,

Jonathan

Hi Jonathan,

Jonathan Nerger said:

Does this mean you are not receiving the new data interrupts either?

Yes, I am not receiving new data interrupts. The nINT pin never gets pulled low when I disable the CANSLNT interrupt. Could it be that the CANERR caused by the CANSLNT bit is preventing M_CAN_INT from being set?

Hi Sandy,

I have done some testing and I am unable to duplicate your results.  I have only masked the CANSLNT bit in register 0x0830 0xFFFFFBFF and I see the nINT pin toggle low every time I send a message to that board.  I also see that the M_CAN_INT bit is set in register 0x0820 upon reception of a new message.  Otherwise I see the same values for registers 0x0830, 0x0820, and 0x0824 as you do. 

Writing a '1' to the RF0N bit of register 0x1050 will clear the RX FIFO 0 New Message bit and this causes the nINT pin to return High. Note again that register 0x0824 is just a read only copy of register 0x1050 allowing for easier burst reading of all interrupts in registers 0x0820 and 0x0824 in a single SPI transaction.

How are you monitoring the nINT pin? Are you using a scope probe with a falling edge trigger?

I had to place my receiving node MCU into a mode that would prevent it from automatically clearing the interrupt bits when the nINT pin was transitioned to use a visual indication with an LED on my board.  Otherwise the MCU cleared the interrupt before I could observe anything on an LED. The nINT pin transitioned high when I performed the write to the 0x1050 of 0x00000001 shown above.

My MCU cleared the interrupt within 180uS, so this could be easily missed.  Masking the CANSLNT bit should not prevent you from receiving an nINT interrupt when the RF0N bit is getting set.

Regards,

Jonathan

Hi Jonathan,

I monitored the nINT pin with a scope and the the signals I captured are attached below. CH1(yellow) is the nINT pin and CH2(blue) is CAN-L pin. 

The data on the CAN bus is sent TO TCAN4550 by a CAN analyzer tool but as you can see the nINT pin is always high. Reading the 0x1050 register at this point verifies that the RF0N bit has been set and the data read from FIFO0 matches the data sent on the bus.

The nINT pin is able to be pulled low by TCAN4550 because I was getting CANSLNT interrupt as mentioned in one of my previous questions, so I have ruled out any hardware design problems.

Are there any other scenarios where the nINT pin cannot be pulled low? Do you have any suggestions that I can try? Thanks!

Hi Sandy,

The nINT pin reflects the Logical OR of all faults in registers 0x0820 and 0x0824 that are not masked. If you have only masked the CANSLNT flag, then new messages should still be reflected on the nINT pin at the same time they are reflected in registers 0x1050 and 0x0824 which is a read only copy of 0x1050.

I will setup my test system again and then capture my device configuration register values so that we can compare them against your configuration registers.

Regards,

Jonathan

Hi Jonathan,

I experimented with the other settings and discovered that I was able to get the GPO2 pin to correctly issue interrupts when data is received. Below are the signals I captured. CH1(yellow) is signal from GPO2 and CH2(blue) is CANL.

I'm not sure what this indicates but I thought I'd share this discovery with you. If you have any thoughts on this please let me know! Thanks.

Hi Sandy,

This is interesting.  The nINT is a Global Interrupt and should get pulled low on any non-masked interrupt.  Therefore, when GPO2 is configured to be an MCAN Interrupt and gets pulled low based on an MCAN Interrupt bit getting set, the nINT pin should also get pulled low. 

I have replicated your test and scope shot using the nINT pin (yellow) and CANL(blue) signals.  My MCU responds to the interrupt signal and clears the interrupt registers in approximately 170uS.

If I then move my blue scope probe off of the CANL line and place it on the GPO2 pin and send another message to this board, you can see that both the nINT and GPO2 pins are the same.

My pin and interrupt configuration register values are:

Register 0x1054 = 0x1A800001

Register 0x1058 = 0x00000000

Register 0x105C = 0x00000003

Register 0x0800 = 0xC84004A8

I have also verified that the GPIO1 pin can be used in the same way as the GPO2 pin by configuring the RFONL bit in the Interrupt Line Select register 0x1058 to '1' and making sure the Interrupt Line 1 Enable EINT1 bit is set to '1' in the Interrupt Line Enable register 0x105C.

As long as the RX FIFO 0 New Message Interrupt Enable RF0NE bit in the Interrupt Enable register 0x1054 is set to "1", the RF0N Interrupt bit in register 0x1050 and 0x0824 will get set to '1' on a new message and this will cause nINT to pull low.  I don't know of any other configuration settings that can prevent nINT from pulling low when an Interrupt Bit is enabled or unmasked in this fashion.

If you can only get GPO2 or GPIO1 to pull low on a new message, but the nINT pin remains high, then I would start to question if the nINT pin is working properly.  It almost sounds to me that it might have become damaged in some way.  Have you been able to get the nINT pin to pull low since you have diabled the CANSLNT flag?  Also, do you by chance happen to have a second device or board that you could try the test on to see if there is a different result for the same register settings?

Regards,

Jonathan

Hi Jonathan,

I found the problem. After enabling EINT0 in 0x105C to test GPO2, I was also able to get interrupts on nINT pin. Looks like either EINT0 or EINT1 has to be enabled for nINT pin to work for CAN interrupts? I was under the impression that they only have to be enabled if GPO1 or GPO2 are being used for m_can_int 0/1. Thanks again for all your help!