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.

TCAN4550: RECEIVING STOPPED / NO INTERRUPT TO MCU

Part Number: TCAN4550

Hi,

I have set-up of multiple CAN nodes, where they work good for a while, however after some period of time some of them stops to receiving. 

On noticing it was observed that TCAN receives the data but was not giving an interrupt to MCU (GPIO2 is configured to give interrupt to MCU).

Below is the configuration for reference:

SPI Speed of MCU is set to 6MBPS

/********************* TCAN Configuraion******************************/

TCAN4x5x_Device_ClearSPIERR(); // Clear any SPI ERR flags that might be set as a result of our pin mux changing during MCU startup

/* Step one attempt to clear all interrupts */
TCAN4x5x_Device_Interrupt_Enable dev_ie = {0}; // Initialize to 0 to all bits are set to 0.
TCAN4x5x_Device_ConfigureInterruptEnable(&dev_ie); // Disable all non-MCAN related interrupts for simplicity

TCAN4x5x_Device_Interrupts dev_ir = {0}; // Setup a new MCAN IR object for easy interrupt checking
TCAN4x5x_Device_ReadInterrupts(&dev_ir); // Request that the struct be updated with current DEVICE (not MCAN) interrupt values

//printmsg("PWRON %x",dev_ir.PWRON);

if (dev_ir.PWRON) // If the Power On interrupt flag is set
TCAN4x5x_Device_ClearInterrupts(&dev_ir); // Clear it because if it's not cleared within ~4 minutes, it goes to sleep

/* Configure the CAN bus speeds */
TCAN4x5x_MCAN_Nominal_Timing_Simple TCANNomTiming = {0}; // 500k arbitration with a 40 MHz crystal ((40E6 / 2) / (32 + 8) = 500E3)
TCANNomTiming.NominalBitRatePrescaler = 2;
TCANNomTiming.NominalTqBeforeSamplePoint = 32;
TCANNomTiming.NominalTqAfterSamplePoint = 8;

TCAN4x5x_MCAN_Data_Timing_Simple TCANDataTiming = {0}; // 500kbps CAN FD with a 40 MHz crystal (40E6 / (15 + 5) = 2E6)
TCANDataTiming.DataBitRatePrescaler = 2;
TCANDataTiming.DataTqBeforeSamplePoint = 32;
TCANDataTiming.DataTqAfterSamplePoint = 8;

/* Configure the MCAN core settings */
TCAN4x5x_MCAN_CCCR_Config cccrConfig = {0}; // Remember to initialize to 0, or you'll get random garbage!
cccrConfig.FDOE = 1; // CAN FD mode enable
cccrConfig.BRSE = 1; // CAN FD Bit rate switch enable

/* Configure the default CAN packet filtering settings */
TCAN4x5x_MCAN_Global_Filter_Configuration gfc = {0};
gfc.RRFE = 1; // Reject remote frames (TCAN4x5x doesn't support this)
gfc.RRFS = 1; // Reject remote frames (TCAN4x5x doesn't support this)
gfc.ANFE = TCAN4x5x_GFC_REJECT; // Default behavior if incoming message doesn't match a filter is to accept into RXFIO0 for extended ID messages (29 bit IDs)
gfc.ANFS = TCAN4x5x_GFC_REJECT; // Default behavior if incoming message doesn't match a filter is to accept into RXFIO0 for standard ID messages (11 bit IDs)

/* ************************************************************************
* In the next configuration block, we will set the MCAN core up to have:
* - 1 SID filter element
* - 1 XID Filter element
* - 5 RX FIFO 0 elements
* - RX FIFO 0 supports data payloads up to 64 bytes
* - RX FIFO 1 and RX Buffer will not have any elements, but we still set their data payload sizes, even though it's not required
* - No TX Event FIFOs
* - 2 Transmit buffers supporting up to 64 bytes of data payload
*/
TCAN4x5x_MRAM_Config MRAMConfiguration = {0};
MRAMConfiguration.SIDNumElements = 1; // Standard ID number of elements, you MUST have a filter written to MRAM for each element defined
MRAMConfiguration.XIDNumElements = 1; // Extended ID number of elements, you MUST have a filter written to MRAM for each element defined
MRAMConfiguration.Rx0NumElements = 16; // RX0 Number of elements
MRAMConfiguration.Rx0ElementSize = MRAM_32_Byte_Data; // RX0 data payload size
MRAMConfiguration.Rx1NumElements = 0; // RX1 number of elements
MRAMConfiguration.Rx1ElementSize = MRAM_32_Byte_Data; // RX1 data payload size
MRAMConfiguration.RxBufNumElements = 0; // RX buffer number of elements
MRAMConfiguration.RxBufElementSize = MRAM_32_Byte_Data; // RX buffer data payload size
MRAMConfiguration.TxEventFIFONumElements = 0; // TX Event FIFO number of elements
MRAMConfiguration.TxBufferNumElements = 8; // TX buffer number of elements
MRAMConfiguration.TxBufferElementSize = MRAM_32_Byte_Data; // TX buffer data payload size


/* Configure the MCAN core with the settings above, the changes in this block are write protected registers, *
* so it makes the most sense to do them all at once, so we only unlock and lock once */

TCAN4x5x_MCAN_EnableProtectedRegisters(); // Start by making protected registers accessible
TCAN4x5x_MCAN_ConfigureCCCRRegister(&cccrConfig); // Enable FD mode and Bit rate switching
TCAN4x5x_MCAN_ConfigureGlobalFilter(&gfc); // Configure the global filter configuration (Default CAN message behavior)
TCAN4x5x_MCAN_ConfigureNominalTiming_Simple(&TCANNomTiming);// Setup nominal/arbitration bit timing
TCAN4x5x_MCAN_ConfigureDataTiming_Simple(&TCANDataTiming); // Setup CAN FD timing
TCAN4x5x_MRAM_Clear(); // Clear all of MRAM (Writes 0's to all of it)
TCAN4x5x_MRAM_Configure(&MRAMConfiguration); // Set up the applicable registers related to MRAM configuration
TCAN4x5x_MCAN_DisableProtectedRegisters(); // Disable protected write and take device out of INIT mode


/* Set the interrupts we want to enable for MCAN */
TCAN4x5x_MCAN_Interrupt_Enable mcan_ie = {0}; // Remember to initialize to 0, or you'll get random garbage!
mcan_ie.RF0NE = 1; // RX FIFO 0 new message interrupt enable

TCAN4x5x_MCAN_ConfigureInterruptEnable(&mcan_ie); // Enable the appropriate registers


/* Setup filters, this filter will mark any message with ID 0x055 as a priority message */
TCAN4x5x_MCAN_SID_Filter SID_ID = {0};
SID_ID.SFT = TCAN4x5x_SID_SFT_DUALID; // SFT: Standard filter type. Configured as a classic filter
SID_ID.SFEC = TCAN4x5x_SID_SFEC_PRIORITYSTORERX0; // Standard filter element configuration, store it in RX fifo 0 as a priority message
SID_ID.SFID1 = unique_ID; // SFID1 (Classic mode Filter)
SID_ID.SFID2 = global_ID; // SFID2 (Classic mode Mask)
TCAN4x5x_MCAN_WriteSIDFilter(0, &SID_ID); // Write to the MRAM

/* Configure the TCAN4550 Non-CAN-related functions */
TCAN4x5x_DEV_CONFIG devConfig = {0}; // Remember to initialize to 0, or you'll get random garbage!
devConfig.SWE_DIS = 0; // Keep Sleep Wake Error Enabled (it's a disable bit, not an enable)
devConfig.DEVICE_RESET = 0; // Not requesting a software reset
devConfig.WD_EN = 0; // Watchdog disabled
devConfig.nWKRQ_CONFIG = 0; // Mirror INH function (default)
devConfig.INH_DIS = 0; // INH enabled (default)
devConfig.GPIO1_GPO_CONFIG = TCAN4x5x_DEV_CONFIG_GPO1_MCAN_INT1; // MCAN nINT 1 (default)
devConfig.FAIL_SAFE_EN = 0; // Failsafe disabled (default)
devConfig.GPIO1_CONFIG = TCAN4x5x_DEV_CONFIG_GPIO1_CONFIG_GPO; // GPIO set as GPO (Default)
devConfig.WD_ACTION = TCAN4x5x_DEV_CONFIG_WDT_ACTION_nINT; // Watchdog set an interrupt (default)
devConfig.WD_BIT_RESET = 0; // Don't reset the watchdog
devConfig.nWKRQ_VOLTAGE = 0; // Set nWKRQ to internal voltage rail (default)
devConfig.GPO2_CONFIG = TCAN4x5x_DEV_CONFIG_GPO2_MCAN_INT0; // GPO2 has no behavior (default)
devConfig.CLK_REF = 1; // Input crystal is a 40 MHz crystal (default)
devConfig.WAKE_CONFIG = TCAN4x5x_DEV_CONFIG_WAKE_BOTH_EDGES;// Wake pin can be triggered by either edge (default)
TCAN4x5x_Device_Configure(&devConfig); // Configure the device with the above configuration

TCAN4x5x_Device_SetMode(TCAN4x5x_DEVICE_MODE_NORMAL); // Set to normal mode, since configuration is done. This line turns on the transceiver

TCAN4x5x_MCAN_ClearInterruptsAll(); // Resets all MCAN interrupts (does NOT include any SPIERR interrupts)

/********************* TCAN Configuraion END******************************/

/******************** Register Values when Receiving Stopped *************/

Status Reg 0x000C: 4000a
Interrupts Reg 0x0820: 4aa
MCAN Intrpt Reg 0x824: 10101
Error Count Reg 0x1040: b00000
Protocol Status Reg 0x1044: 25300f
Interrupt Reg 0x1050: 10101
Mode Control 0x0800: c84004a0
Rx FIFO 0 Configuration 0x10A0: 8010000c
Rx FIFO 0 Status 0x10A4: 3090a

/******************** Register Values when Receiving Stopped END *************/

 

I don't get where exactly the problem is as the RX_FIFO register is receiving the data but the interrupt to MCU is not being genrated.

Thank & Regards 

Tirthraj Solanki

  • Tirthraj,

    I've assigned this to an expert so they can help out.

    Regards,

    Eric Hackett 

  • Hi Eric,

    Thank you for reply.

    Can you give some estimate time period. 

    Actually we are about to launch our product and are facing this issue during testing of product where number of nodes are 8.

    Regards 

    Tirthraj Solanki

  • Hi Tirthraj,

    When you say that the "interrupt to MCU is not being generated," can you clarify the value of the nINT, GPO2, and GPIO1 pins?  Are they always High, or Low, etc.?  I understand that the MCU is not responding to new interrupts, but I don't know if that is because the interrupt pin is stuck low or stuck high. 

    Either there are interrupt bits that are not getting cleared which are masking new interrupt bits to the MCU, or the device has stopped generating the interrupts which I find less likely.  Generally there are uncleared interrupt bits masking the new ones.

    I see that there are three specific MCAN Interrupts getting set in register 0x0824.  If these are not all getting serviced and cleared, then they could prevent the pin from changing state when a new message is received.  Can you also provide the value of registers 0x0830 and 0x1054 (MCAN Interrupt Enables)?

    You may want to verify that only the interrupts you care about are enabled and disable the other ones.

    I see from register 0x0842, you are getting a Timestamp Wraparound (TSW), High Priority Message (HPM), and RF0N (RX FIFO 0 New Message.  These are all common interrupts. The timestamp counter has wrapped around and needs to be acknowledged (cleared).  There are a two types of counters that you can chose from and the divider can be changed to slow down the counter and prevent you having to clear this interrupt as frequently.  If you are not currently using the timestamp counter, then this may be the bit getting set that masks your new message interrupt bits. I also see you have both a new message in RX FIFO 0 (RF0N) and a High Priority Message which is just a designation for a type of message.  All of these interrupts will need to be cleared for a new interrupt to be generated as a state change on the GPIO pins configured for MCAN interrupts.

    Your error count register 0x1040 is reporting a CEL[7:0] value with quite a few errors indicating there could be some problems with the configuration on some of the nodes and the signal integrity is not good resulting in bit errors.  The REC[6:0] and TEC[7:0] values are zero, so the CEL errors may be old and just need to be cleared with a read.

    You also have some flags getting set in the Status register 0x000C which indicate a possible issue with the SPI communication.  The Write Underflow (bit 18) shows that there was not enough data transmitted in a SPI message that was indicated.  This could also be the cause for the SPI Error Interrupt (bit 1) getting set.  The TCAN4550 counts the number of clock cycles (or bits) between the chip select signal toggling LOW and the HIGH again to make sure there is a proper number of bits transmitted in the message as a form of error checking.  If there is an incorrect number of bits, it will discard the data it received on a write and does not change the register or MRAM data with this new corrupted data.  If there is too few data bytes or words transmitted, it too will assume an error and set the Write Underflow bit as shown.  These errors are global errors that would be reflected as an interrupt on the nINT pin, and not the GPIO pins, but these indicate that register and RX/TX FIFO message read/writes may not be completing properly.  If the SPI errors are persistent, then we need to verify the SPI signals are correct and of good quality.

    Regards,

    Jonathan

  • Hi Jonathan,

    Thank you for your quick response.

    Today on testing with same configuration mentioned by me earlier we haven't seen the problem.

    Further we will be testing it again and will give you an update as soon as it occurs.

    Regards

    Tirthraj Solanki

  • Hi Tirthraj,

    Thank you for the update and I hope it continues to operate without issue.  I didn't see anything as a obvious issue from your previous post, so generally it looks like pretty good configuration.  I'll keep the thread open while you do your additional testing so that you can follow up if you have additional problems.

    Regards,

    Jonathan

  • Hi Jonathan,

    During testing these days we have noticed the same issue again, I am attaching some of the data we gathered, can you please help us on same.

    NODE 1 DATA WHEN ISSUE OCCURRED:

    GPIO2 Value 0 (i.e. LOW)
    Status Reg 0x000C: 8
    Interrupts Reg 0x0820: 4a2
    MCAN Intrpt Reg 0x824: 10105
    Interrupts Field Reg 0x0830: 809628ff
    Error Count Reg 0x1040: ff0000
    Protocol Status Reg 0x1044: 25300f
    Interrupt Reg 0x1050: 10105
    Interrupt Enable Reg 0x1050: 1
    Mode Control 0x0800: c84004a0
    Rx FIFO 0 Configuration 0x10A0: 8010000c
    Rx FIFO 0 Status 0x10A4: 1020210

    To be Noted that both the nodes are on different bus, this data is for reference

    NODE 2 DATA WHEN ISSUE OCCURRED:

    GPIO2 Value 0 (i.e. LOW)
    Status Reg 0x000C: 804000e
    Interrupts Reg 0x0820: 4aa
    MCAN Intrpt Reg 0x824: 10105
    Interrupts Field Reg 0x0830: 809628ff
    Error Count Reg 0x1040: 200000
    Protocol Status Reg 0x1044: 25300f
    Interrupt Reg 0x1050: 10105
    Interrupt Enable Reg 0x1050: 1
    Mode Control 0x0800: c84004a0
    Rx FIFO 0 Configuration 0x10A0: 8010000c
    Rx FIFO 0 Status 0x10A4: 10f0f10

    NODE 2 DATA WHEN AFTER SYSTEM RESET:

    GPIO2 Value 1 (i.e. HIGH)
    Status Reg 0x000C: 834000e
    Interrupts Reg 0x0820: 4a8
    MCAN Intrpt Reg 0x824: 10000
    Interrupts Field Reg 0x0830: 809628ff
    Error Count Reg 0x1040: 0
    Protocol Status Reg 0x1044: 300f
    Interrupt Reg 0x1050: 10000
    Interrupt Enable Reg 0x1050: 1
    Mode Control 0x0800: c84004a0
    Rx FIFO 0 Configuration 0x10A0: 8010000c
    Rx FIFO 0 Status 0x10A4: 0
    Device ID = 8

    Also would like to mention that we are not using GPIO 1, so it is not connected and during initial phase of development we were noticing too much interrupts on nINT pin and were unable to differentiate between was it error interrupt or data interrupt, as a result we moved to GPIO 2  and at this moment we are not using any functionality of nINT Pin.

    Regards

    Tirthraj Solanki

  • Hi Tirthraj,

    Just to clarify, when you say that the two nodes are on different bus, you're telling me that these devices are not communicating with each other and are on two different test setups, correct?  Can you tell me what the bus looks like, or provide a simple diagram?  I'm curious what types of transceivers are on them and I know you have already mentioned there are 8 nodes on the bus. For example, are they all TCAN4550 devices, or is there only one TCAN4550, and how frequently are you sending messages, etc.?  Also, what is the length of the bus, the spacing between the nodes, etc.?  Have you tried to swap the position of the nodes on the bus, and does the error follow the physical node (device) or does it stay in a particular position on the bus?

    I have reviewed the device registers.  I see that Node 1 has a full RX FIFO 0, but I don't see much indication as to why the GPIO2 pin would stop generating an interrupt unless not all of the interrupt bits are getting cleared by the MCU which would cause the GPIO2 pin to remain active low even while new messages are arriving.  Can you confirm that the GPIO2 pin is transitioning back High after the MCU checks the interrupt register and tries to clear it such as after a new message has been received?

    I see the Timestamp Wraparound (TSW) and High Priority Message Received (HPM) bits are always set.  Are those getting cleared as well, or are you only clearing the RX FIFO related bits?

    Everything I observed for Node 1 applies to Node 2, but there are a few additional observations with Node 2.  The Status register 0x000C shows there are also some SPI related errors that could cause some problems.  If the error occurs on a Write transaction, the MCU may think that a register has been updated, but the TCAN4550 may discard the transaction because it did not meet the SPI requirements such as the correct number of bits or SPI clock cycles.  Is the MCU monitoring for SPI errors and verifying the register values if it sees a SPI error is reported?  SPI errors can also result when accessing the MRAM to write or read data from the TX and RX FIFOs because these still require a multiple of 32 bits to be passed.

    SPI errors are only passed as an interrupt on the nINT pin, but are always reported on the SDO pin immediately after the nCS pin is pulled low at the beginning of each SPI transaction. 

    Can you verify the SPI signals are of good quality and should be noise and error free?  I don't expect there is a protocol error in the SPI driver based on how much you have working, so I suspect that there is either poor signal quality, or perhaps some form of clock disruption that would result in a SPI error. 

    One additional issue that could result in a SPI error or some device corruption and missed messages is a disruption to the device clock (either the crystal or single-ended clock) that would prevent the digital core from fully passing data to and from the device in a SPI message, or from sending or receiving a CAN message.  Can you share with me the portion of the schematic for the TCAN4550 and what components you have connected to the device including the crystal/clock?

    I also see the CAN Silent bit is set which associated with one of the device failsafe features.  This indicates that there has not been CAN activity detected on the bus for longer than the timeout period which is roughly 1 second.  Is there enough CAN messages on the bus to ensure this flag should not get set?  Could there be some hardware explanation for why this node would not see messages for a period of time causing it to set this flag?

    Regards,

    Jonathan

  • Hi Jonathan,

    1. Yes you are getting it correct that two nodes are not communicating with each other and they are on different setup.

    2. All the transceivers are TCAN4550.

    3. Number of nodes are as given in image below on each bus, where different color represents different bus.

    4. Messaging Frequency is random.

    5. Maximum space between two nodes can be 1 meter and maximum length of bus could be 100 meters and maximum devices that could be connected to each bus are 100.

    6. Yes have tried to change position on bus, also to be noted that issue doesn't follow any specific device or place. It is quiet random.

    7. We were only clearing SPI Error and Rx FIFO bit till now. We have implemented to clear other status also as you mentioned and currently that configuration is in testing.

    8. Meanwhile i will check the SPI Signal and will give you an update. 

    Can you provide me email-id to share schematic files  and image of bus architecture system.

    Regards

    Tirthraj Solanki

  • Hi Tirthraj,

    I have sent you an email that you can use to provide the files.

    Regards,

    Jonathan