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.

TCAN4551-Q1: From registers, cannot tell what caused the interrupt pin to go low.

Part Number: TCAN4551-Q1
Other Parts Discussed in Thread: TCAN4550,

Tool/software:

Hello Everybody, 

I need some help understanding what registers to check when I have an interrupt from the nINT pin.

I'm probably missing something, but here is the background:

I have successfully written a driver for this device on a different board. On that, I have no problem reading and writing CAN messages.

On a new board, which is only slightly different, and not expected to be different in the area of the TCAN4551, I have a problem that when there is a single message on the CAN bus, the nINT pin goes low to interrupt the MCU, but when I read the registers I cannot see evidence that the TCAN has received a message. this means:

As soon as I externally transmit a message on the CAN, the nINT pin goes low (so definitely message rx driven, and repeatable consistently). When the MCU firmware sees this, it reads

REG_DEV_IR = 0x000004A0

REG_MCAN_IR = 0x00010008

it seems to be setting the RF0L message lost but

REG_MCAN_RXF0S shows no messages at all, so how did I lose the message?

I can't see any indication in 

REG_MCAN_ECR = 0x00000000

REG_MCAN_PSR = 0x00000708

I can't work out where the message has gone, or if there was an error, what it was. (i'm concerned there could be some kind or hardware issue on the new board affecting bit detection)

I am not using any filters, and only using RX0 elements.

What other registers should I be looking at?

At the end of my interrupt function, I clear the interrupts, and the pin goes high again until I send another message.

I think maybe it's something from the DEV IR, but I can't work out what. 

Regarding which interrupts I'm enabling, it's mostly from the demo code - it behaves the same whether or not I enable the RF0L interrupt:

/* 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
mcan_ie.RF0WE = 1; // RX FIFO 0 watermark interrupt enable
mcan_ie.RF0FE = 1; // RX FIFO 0 full interrupt enable
// mcan_ie.RF0LE = 1; // RX FIFO 0 message lost interrupt enable (if on it's own doesn't mean there's a message to process)

mcan_ie.EWE = 1; // Error Warning interrupt enable
mcan_ie.BOE = 1; // Bus Off interrupt enable

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


/* 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; // GPO1 output (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_NO_ACTION; // 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

Any pointers would be gratefully received.

  • Hi Ed,

    This is interesting and, and I don't have an immediate answer for you.  Can you provide a list of the final register values that are being configured into the device so that I can review the final configuration?  Basically if possible just read back all of the device registers into a simple text log file.

    I know you said you aren't using filters, but if possible, can you tell me what the CAN message you are sending is so that I have that information when reviewing the register configuration?

    Is your current test setup just two nodes (the Board under test and some other node that is used to send CAN messages)? Or are there multiple nodes on the CAN bus?

    Do you have the ability to monitor the CAN waveforms on a scope to see if it has been acknowledged or has error flags, etc.?

    If you would like to provide a schematic of the TCAN4551-Q1 portion of your board, I can review that as well.

    But to the immediate questions, the nINT pin is the Logical OR of registers 0x0820 and 0x0824 (and 0x0824 is just a read only copy of 0x1050).  It appears the Interrupts are working correctly, but the question still remains as to why is the RX message lost, and I hope the additional register information will help provide an answer to that question.

    Regards,

    Jonathan

  • Hi Jonathan, 

    Thank you for the quick reply. It was a good suggestion to read back the entire configuration.

    I was able to spot that for some reason some registers like RXF0C, RXESC, TXBC had been zeroed, which explains the lost/missing messages.

    I will have to investigate why this is. I only write them once, so I suppose it is some kind of power or sleep event that clears them.

    Inspecting other registers, I see that this event has cleared the Test Read and Write and  saved the Scratch Pad half of the Test and Scratch Pad Register, so this looks like I am entering sleep mode and losing the configuration. From reading the data sheet, I'm still not quite sure which registers are cleared in sleep mode, or when I need to rewrite them.

    It may be that I'm not using sleep mode in the right way.

    Regards, 

    Ed.

  • Hi Ed,

    I'm glad my suggestion was useful and this certainly explains the missing messages. 

    Regarding the bits that are saved in Sleep Mode, they have Bold Font in the register maps tables in addition to the scratch pad bits as you have mentioned.  These bits are generally concerning the hardware pin configuration settings that need to be retained during Sleep Mode.  But most device registers, including all of the MCAN registers, are reset during Sleep Mode and need to be reconfigured after the device has seen a POR or Sleep Wake Up event.

    Regards,

    Jonathan