TCAN4550-Q1: TCAN4550 Data sending and receiving exception

Hi Liang,

This sounds like the clock may be getting disrupted resulting in the inability to communicate when it is not present.  This can occur when using a crystal and the circuit is not optimized resulting in the device switching between the crystal and single-ended clock mode.

If you have a series dampening resistor between the OSC1 pin and the crystal, try to increase that value.  This resistor will reduce the current flowing through the crystal and reduce the amplitude of the oscillation waveform and stabilizes the circuit.

If you don't have a series resistor, you can increase the value of the two load capacitors on each side of the crystal by 2-4pF each.  The reactance from the increased capacitors create a larger voltage divider with the ESR of the crystal and reduces the amplitude of the oscillation waveform and stabilizes the circuit.

Please review the TCAN455x Clock Optimization and Design Guidelines application note (Link) for more information.

Try to increase the resistance or capacitance and re-test.

Regards,
Jonathan

HI  Jonathan

Thanks for your suggestion ,

Now I'm trying to increase RXfifo to 64   " MRAMConfiguration.Rx0NumElements = 64; "

Feel this phenomenon decrease

Is there any connection between the two

Jonathan Nerger said:

Jonathan

Hi Liang,

I still don't know if your observations are, or are not, related to a clock disruption.  However, a clock disruption from a crystal to single-ended mode change would be completely independent of any register configuration and the number of elements you've enabled in the RX FIFO.  The clock disruption would be asynchronous to the CAN data.  Increasing the frequency of the CAN messages could make it more likely to have a CAN message coincide with a clock disruption, but his does not depend on the RX FIFO size.

How are you monitoring the system and the communication?  Can you monitor the various device registers such as the Status, Interrupts, Error Counter and Protocol Status Register, along with the RX FIFO status to track the Get/Put Indexes and the RX Fill levels?

Regards,

Jonathan

Hi Jonathan

     I used the logic analyzer to obtain the working status of SPI and INIT pins, as shown in the figure   

     At the same time I turned on these interrupts but they didn't fire when the exception happened

//! @brief IR[22] ELO: Error logging overflow
uint8_t ELO : 1;

//! @brief IR[23] EP: Error_passive status changed
uint8_t EP : 1;

//! @brief IR[24] EW: Error_warning status changed
uint8_t EW : 1;

I didn't see any interruption on the bus during the exception, but I didn't turn on REG for RX0FIFO full

Hi Liang,

Are you using a crystal for the clock source?  If so, please try my original suggestion of increasing the value of the series resistor between OSC1 and the crystal, or increasing the capacitance value of the capacitors on the OSC1 and OSC2 pins if the series resistor has been left out of the circuit.  After doing so, see if the disruptions are still observable.

Regards,

Jonathan

Hi Jonathan

thanks for your reply 

I will modify the circuit according to your suggestion, keep in touch

Hi Liang,

Thank you, I will wait for your results.

Regards,

Jonathan

HI Jonathan

     I made the circuit modifications as you suggested

     I replaced the 12pf capacitor with 15pf , The problem still exists.

     One thing to note  After I increase rxfifo  I can send data to CAN when I can't receive CAN data

    Are there any special operations required to receive interrupt processing

   The following is my receive interrupt processing code and hardware crystal part of the circuit design

Hi Liang,

Thanks for testing the clock configuration with more capacitance.  Having too little capacitance has has been a common reason for communication issues.

The ability to transmit and receive CAN messages should be independent as long as there are not problems with the MRAM allocation such as overlapping the memory space between the different types of buffer elements.  But assuming your RX and TX buffer elements do not overlap in memory, then increasing or decreasing the RX FIFO length should have no impact on the TX operation.

Looking at your interrupt code, it appears you are only interested in processing CAN message ID's that are withing a specific Range based on the "Universal_Min_ID" and "Universal_Max_ID" variables as well as a few specific ID's.  Is that correct?

If so this is inefficient and the TCAN4550 can filter those messages by itself and prevent them from being stored in the RX FIFO.  This will eliminate the interrupt to the MCU to process a message it does not care about.  This also prevents unwanted messages from filling up the RX FIFO and possibly blocking new messages that you do care about from getting stored.  Please consider creating some SID and XID Message Filters for the message ID's you care about.

It may be that the RX FIFO is getting full and prevents you from receiving new messages until they are eventually cleared and there is additional space in the RX FIFO. 

Can you monitor and log the RX FIFO Fill Level during the disruptions to see if it is becoming full?

If you have not already reviewed the following documents, I would suggest you look at them for additional information that may help you.  Please consider creating some SID and XID Message Filters for the message ID's you care about.  Additional information on how to do that can be found in the following documents.

TCAN45xx Software User's Guide (Link)

MCAN User's Manual (Link)

Regards,

Jonathan

Hi Liang,

This is more evidence of a bad clock.  The SPI interface uses a FIFO to handle the frequency translation between the SPI clock frequency and the clock frequency used by the digital core that is supplied by the OSC1 and OSC2 pins.  If the OSC clock is stopped or disrupted in any way while the SPI data is coming into the FIFO, then the digital core will not pull the data out of the FIFO (due to the lack of a clock) and the FIFO will overflow generating a SPI Error.

The most common cause of this is too large of an amplitude on the OSC2 waveform that causes the device to switch to single-ended clock mode because it sees the lower level of this waveform as a "grounded" pin.  As I've mentioned, increasing the capacitance should reduce the amplitude and prevent a clock mode switch.

You said you increased the caps to 15pF, but perhaps you need to increase them more.  Can you try to keep increasing the cap values and re-test to see if you can find a level that is stable?

Do you have access to the GPIO1 pin on your board, or is it not used?

Regards,

Jonathan

HI Jonathan

     Thank you for your reply. We didn't use GPIO1 .we introduced it to the mcu .Do I need to do anything with it. So why can I send it when I'm abnormal

HI Liang,

I was just curious if it was available to monitor with a scope because if so, we could use it to detect a clock disruption with device test mode.  Would your board allow you to place a scope probe on the GPIO1 pin during your testing?

Regards,

Jonathan

Hi Liang,

I will send you some information on how to monitor the GPIO1 pin through email.

liang jie said:

Another question I have is why it is OK to send but not to receive

Assuming this is a clock disruption issue, the device can only send messages when the clock is working, so they will almost always appear to be transmitted OK.  A transmit error may be generated if the clock stops in the middle of a CAN message transmission and the other nodes detect an incomplete or invalid message frame.  But the message transmission may have a better chance of completing successfully while the device has a working clock.

However, because the receiving message is independent of the local clock, it has a higher chance of detecting an error because the messages can arrive while the clock is not working. 

Can you also share your complete MRAM configuration so we can verify it does not have overlapping sections between your elements.  The MRAM is only 2Kb and if you exceed the space, it automatically wraps around and can overwrite other elements which can sometimes create some unexpected errors.

Regards,

Jonathan

Hi Jonathan,

This is FAE Iris supporting Yanfeng. Liang Jie is my customer from Yanfeng and I am here to follow up this issue.

1. Would you share the details about how to monitor the clock through GPIO1? Liang said they didn't receive your email.

And we have below questions:

1. Do we have a summary table about when nINT would be active low? I only found "this pin is the logical OR of all faults in registers 16'h 0820 and 16'h0824" in datasheet. Does below registers contain all the possible interrupt requests when nINT is low?

2. If there is an interrupt bit in h1050 resgiter, will it set nINT low?

3. When 0820 register bit SPIERR is1, is it OK to read data from RX FIFO?

4. Is there a way to clear the SPIERR interrupt flag?

Thanks.

Iris,

Because today and tomorrow are US holidays, please expect delays in response until next week. Thank you for your patience.

Regards,

Eric Hackett

Hi Iris,

Iris Shen said:

1. Would you share the details about how to monitor the clock through GPIO1? Liang said they didn't receive your email.

I've emailed you the information as well so please pass that along to Liang.

Iris Shen said:

1. Do we have a summary table about when nINT would be active low? I only found "this pin is the logical OR of all faults in registers 16'h 0820 and 16'h0824" in datasheet. Does below registers contain all the possible interrupt requests when nINT is low?

Yes, the nINT pin will reflect any interrupt bit that has been set in registers 0x0820 and 0x0824 that has not been "masked" from causing the nINT pin from being set by this bit.  Some of the interrupt bits cannot be masked and will always be reflected on the nINT pin.

The device's non-CAN related interrupts are reflected in register 0x0820 and are masked or enabled by setting the corresponding bit in the Interrupt Enables register 0x0830.  A "1" enables the bit to be reflected on the nINT pin, and a "0" masks or disables the bit from being reflected on the nINT pin.

The CAN related interrupts are reflected in register 0x0824 and 0x1050.  Note that register 0x0824 is just a read-only copy of register 0x1050 which is the primary CAN Interrupt register that would be used to clear the interrupts with a write.  Also note that ALL CAN related registers are in the register address domain of 0x10xx and all other device related registers are in the register address space of 0x08xx.  However, by placing a read-only register of the CAN interrupts allows the MCU to read both the device and CAN interrupts in a single 2-word SPI Read because registers 0x0820 and 0x0824 are consecutive to each other.

By default all CAN related interrupt bits are disabled and you will need to enable them through the Interrupt Enable register 0x1054.

You will also need select with CAN Interrupt Line to use.  Note there are two Interrupt Lines available (0 and 1) that can optionally be used with the GPIO1 and GPO2 pins to allow better handling or prioritizing of the interrupts by the MCU.  By default all interrupts are assigned to Line 0, but you can configure this selection in the Interrupt Line Select register 0x1058.  Note, that this will have no impact on whether the nINT pin reflects these interrupts, if the CANINT bit is enabled in register 0x0820 because nINT is the global interrupt pin.

The final step if you want to enable any CAN interrupts from being reflected on the nINT, GPIO1, or GPO2 pins, you will need to enable the CAN Interrupt Line that has been selected for use on the interrupts.  This is done in the Interrupt Line Enable register 0x105C.  By default both CAN interrupt lines are disabled, so you will need to enable one or both of these lines to see any CAN interrupts reflected on the nINT pin.

Iris Shen said:

3. When 0820 register bit SPIERR is1, is it OK to read data from RX FIFO?

4. Is there a way to clear the SPIERR interrupt flag?

The SPIERR bit is set to 1 when there is some form of protocol error detected in a SPI read or write transaction.  The device will count the number of SPI clock cycles while the chip select line is low to make sure is an exact multiple of 32.  If it is not, then there are either too few, or too many clock cycles and sampled bits which means the data is unreliable. 

If the error occurs during a Write transaction, then the device ignores the write data and the register or memory value retains the previous value because it is assumed the data was invalid. 

If the error occurs during a Read transaction, then the device has already returned data, to the MCU, but because of the error the MCU may need to re-read the data to verify it's accuracy because of the SPI error detected.

A SPI Error can also occur because there are too many or too few 32-bit words of data in the SPI transaction that don't match the Length field of the SPI Header.  The Status register 0x000C can provide additional information about what may have caused the SPIERR bit to have been set.  TO clear a SPIERR, you will need to clear the bits that have been set in register 0x000C.

If noise has caused an extra clock edge to be detected, then clearing the error bits and re-reading the register is all that is needed.  But if the SPIERR bit is continually set, then there may be a larger protocol error that needs to be resolved.

Regards,

Jonathan