TCAN4550: TCAN4550 SPI write fifo overflow

Hi Zhonghui,

What is the value of the Status register (h000C) after this SPIERR is reported? The status register can tell us the nature of the SPI error so we can take a look at what may be causing this. 

Does this error always appear on this write attempt? Or does it happen inconsistently? Would you be able to provide scope shots of the SPI signals so we can verify that the electrical parameters are met?

Is it possible to share a schematic for this design? I would like to see how all the digital pins and CAN bus are connected.

Regards,
Eric Schott

Hi Eric,

Thank you for your help.

The value of status register (h0000c) after spierr is h01000004. After the first and second write, this error will occur during write and read. Data cannot be written during write, and data can be read back normally during read (h0000)

SPI is directly connected to MCU hardware without other operations.

Best regards,

Hi Zhonghui,

Can you confirm that the 40MHz single-ended clock signal is present and stable during this test? Any address > h000C must have this clock signal active to be accessed. 

Are you able to capture analog scope shots of the SPI lines to verify electrical parameters?

Are any other interrupts set in h0820 after the SPIERR is reported?

Regards,
Eric Schott

Hi Eric,

Thank you for your help.

I just got the verification result of the client and determined that the crystal oscillator 40M was exported to the chip.

The problem remains.

As shown, after the first write, it returns 00 and second returns to 88 error.

Please help analyze it again,thanks.

Best regards,

Zhonghui,

The error you mentioned from 0x000C register is the write_fifo_overflow interrupt. Is the SPI communication working in general though, or is SPI communication not working along with getting these errors? I know you mentioned writes wouldn't work but reads would, is that still the case? And is it possible to share zoomed in waveforms of SCLK, SDI, SDO, and nCS? I want to make sure the timing is correct.

Regards,

Eric Hackett 

Hi Eric,

Thank you for your help.

It is useful.

Best regards,

Zhonghui,

No problem, is there still an issue present then? The write_fifo_overflow is typically the result of transmitting more data than was declared in the LENGTH portion of the SPI frame (see page 43 of the datasheet). Though, in your waveforms it looks like you're only defining a length of 1, and sending one word, so I'm curious if the SPI timing is causing the data that's transmitting to overflow the SPI FIFO and trigger the interrupt because it is seeing the beginning of a second data word.

Regards,

Eric Hackett