TCAN4550EVM: Tx FIFO transmission issue

Hi Hermes,

The SPI transaction you highlighted here is the software loading the information into the MRAM. The 2kBytes of MRAM starts at address 0x8000 and is used to store info for all filter elements, buffers, and FIFOs. In this case, you are loading information into TX Buffer 0, which was configured in address 0x8174 in MRAM. This all looks fine. 

The CAN data here looks good as well, until we see the error frame (long dominant low period) at the end of the CAN frame. If this error frame was driven by the TCAN4550, we should be able to read the MCAN interrupts (h0824). If there is some other active CAN node on the bus, it could also be the one generating the error frame. If that is the case, we will have to interrogate it to learn what error it identified. In either case, one of the configurations for TCAN4550 is to automatically attempt to retransmit if a transmit attempt failed. Let me know if this is undesirable and I can help you reconfigure this setting. Otherwise, we can focus on resolving the error itself. 

Let me know what else you are able to find out. 

Regards,
Eric Schott

Hi Eric,

Thanks for your advice. In my testing, there is no other active CAN node on the bus, only connects to the Logic Analyzer I use. Also, I tried to read the interrupt register after sending the data, its value is 0x11810000.

Best Regards,

Hermes Wu

Hi Hermes,

Thanks for completing the extra testing. It looks like the TCAN4550 has attempted to send so many times with this error that it has entered the error passive mode (EP) and has stopped generating error frames on the CAN bus. The other interrupt that sticks out here is the Protocol Error in Data Phase (PED) interrupt. This makes sense because of where the error frame was appearing in the previous shots. 

My suspicion here is that the analog signal on the CAN bus is not able to keep up during the data phase (FD phase with faster datarate). Is it possible to capture the CANH and CANL signals with an oscilloscope so we can see the analog behavior of the signal lines?
Also for a bit more info, we can read the Protocol Status Register (h1044) to see what the last reported error code (LEC) is. This will tell us exactly what protocol error the CAN controller recognizes in this case. 

Regards,
Eric Schott

Hi Eric,

I try to capture CANH and CANL signals with the oscilloscope, and read register h1044 with values 0x0013037F or 0x0013036F. The value in the LEC field remains at 7.

Best Regards,

Hermes Wu

Hi Hermes,

The last error code in the data phase (DLEC) here has a value of 3 which indicates that there was an ACK error. This occurs when a transmission is not acknowledge by any other node on the CAN bus. When the controller identifies that the transmission has not been completed successfully, it automatically attempts to retransmit the message. This is why you are seeing repeated messages appear on the CAN bus. To disable automatic retransmission, set the Disabled Automatic Retransmission (DAR) bit in the Control Register h1018[6]. 

To avoid this error, another active node should be placed on the CAN lines so that it may drive a dominant during the ACK phase of the CAN frame. 

Regards,
Eric Schott