TCAN4551-Q1: SPI communication problem (SPIERR)

Hi Marco,

This is an interesting case. The waveform here shows the TCAN4551 reports the 0x88 state of the interrupt register, but it does not respond with any data for the rest of the SPI message. I would expect with this waveform from the SPI commander that the device would respond with its ID. Have any other tests had the TCAN4551 return any data apart from the first byte of interrupt status? If so, please try to read the error Status Register (h000C). This will give us more insight on the SPI error the device is recognizing. 

If you are unable to read any data from the device at all, I would recommend double checking the SDI input. If this signal is not connected and is resting high for the TCAN4551's input, it would be recognized as invalid form and cause it to respond with a SPI error in such a way with no data. 

Let me know what else you are able to find. 

Regards,
Eric Schott

Hi Eric,

i receive also 0x88 for the h000C register.

If i remove the SDI input the signal remains at 0V.

I am really stuck on this one :/

Best regards,

Marco

Marco,

What is your VIO voltage in this application? I'm asking because your MISO and MOSI are at 2.2V, but your nCS and SCLK are above 5V. This doesn't seem correct and may be a part of your problem.

Regards,

Eric Hackett

Hi Eric,

we could already resolve this issue. We had a defect TCAN. After changing, the signals are all at 5V.

No we are able to readout the device ids correctly, but the 0x88 is still in the message.

Reading out the 0x000C register leads to 0x0330 0006. According to the datasheet, there is still an unmasked SPI error present, and an invalid SPI message.

Also there seems to be some issue with the FIFO, but actually no CAN messages are send or received.

Is the register 0x000C reliable readable without an attached clock at OSC1 / OSC2?

Thanks for your help so far and best regards,

Marco

Hi Marco,

Yes, the 0x000C register is accessible when the external clock is not available. 

As you said, the value of this register indicates that a previous SPI command was registered as invalid. This includes the SPI_end_error flag which indicates that the a SPI transaction did not end on a byte boundary. This means that the SPI frame (one nCS pulse) did not contain a integer multiple of 32 bits. Please check that all SPI frames follow this requirement. I would recommend checking these signal lines on initial power-up as sometimes the startup condition can cause a nCS pulse with invalid data. If this is the case, be sure to clear these interrupts after startup so any following interrupt conditions can be caught. 

Alternatively, it's possible that this error is occuring when a higher address ( >= h0800) while the external oscillator is not stable. If the interrupt appears to be set after a SPI transaction with no discernable issue on the scope, we may want to look into this further. 
Are you using an external crystal oscillator for the OSC1/2 pins or a single-ended clock? If the crystal is used, please review the app note below for more info on different consideration that need to be made for such a design. 
https://www.ti.com/lit/an/slla549/slla549.pdf?ts=1656532573184&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTCAN4550-Q1 

Regards,
Eric Schott