• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 1389 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCAN4550: TCAN4550 unable to spi read / write - error 88000000

Ole Kristian Western
Prodigy 85 points
Part Number: TCAN4550


Hello! I'm working on a custom board with two TCAN4550 connected to the same SPI bus of nRF52832, but can't read any register. I've tried all the lowest registers 0x0000, 0x0004, 0x0008 and 0x000C which should work even with crystal problems, but i'm always getting 88000000 as response. I tried everything from 500kHz to 18MHz bus speed,CPOL=0 and CPHA=0 (but for troubleshooting I've tried all SPI modes).
I see that the correct bytes are sent from the nRF52832 with my logic analyzer (saleae pro 8), but the response is almost always 88000000 (sometimes 00000000). If I disconnect the 12V, I'm getting FFFFFFFF, so I'm suspecting the TCAN is responding to something. Is this an error code? Since the messages are sent in 4 bursts of 8 bits, the 88000000 response mean bits 31 and 27 are set? What errors does that indicate?

Some output from the analyzer:

0x61/0x00 0x00/0x00 0x0C/0x00 0x01/0x00 0xFF/0x00 0xFF/0x00 0xFF/0x00 0xFF/0x00
0x41/0x00 0x00/0x00 0x0C/0x00 0x01/0x00 0xFF/0x00
0x41/0x00 0x00/0x00 0x00/0x00 0x01/0x00 0xFF/0x00
0x41/0x00 0x00/0x00 0x04/0x00 0x01/0x00 0xFF/0x00
0x61/0x00 0x08/0x00 0x08/0x00 0x01/0x00 0x12/0x00 0xEF/0x00 0xCD/0x00 0xAB/0x00
0x41/0x00 0x08/0x00 0x08/0x00 0x01/0x00 0xFF/0x00
0x41/0x00 0x08/0x00 0x20/0x00 0x01/0x00 0xFF/0x00
0x41/0x00 0x00/0x00 0x00/0x00 0x02/0x00
0x61/0x00 0x00/0x00 0x0C/0x00 0x01/0x00 0xFF/0x00 0xFF/0x00 0xFF/0x00 0xFF/0x00
0x61/0x00 0x08/0x00 0x30/0x00 0x01/0x00 0x00/0x00 0x00/0x00 0x00/0x00 0x00/0x00 0x41/0x00 0x08/0x00 0x30/0x00 0x01/0x00 0xFF/0x00
0x41/0x00 0x08/0x00 0x20/0x00 0x01/0x00 0xFF/0x00
0x61/0x00 0x08/0x00 0x20/0x00 0x01/0x00 0x00/0x00 0x00/0x00 0x00/0x00 0x00/0x00
0x41/0x00 0x10/0x00 0x18/0x00 0x01/0x00 0xFF/0x00

I ported your official driver to Zephyr RTOS, but after failing to read even the lowest registers, I focused on simple write/read commands to figure out if it was hardware or software. But now I'm stuck.

We had a few hardware problems in the beginning. We first assembled with a 40MHz resonator (OT201640MJBA4SL) with wrong footprint instead of the crystal we intended to use (ABM11W40.0000MHZ8B1UT).
Resonator:
1 Tri-state 2 GND 3 OUTPUT 4 VDD
Footprint:
1 OSC1 2 GND 3 OSC2 4 GND
Don't think it damaged the TCAN4550?
My assembly person replaced the resonator with the proper crystal on his board, and he could see it oscillating fine. We work in different countries, and I don't have the crystals. Instead I removed the resonator and caps, soldered OSC2 to GND and use my signal gen set at 40MHz 3.2Vpp offset 1.6V to OSC1. No luck. But even with a faulty or missing oscillator, the lowest registers should be accessable anyway?

Next, the standard drive strength of nRF52832 was causing too slow rise time for SCK (measured to about 40ns). We increased it, and now it's measured to rise about 8ns (within 10ns spec). Still no improvement. I take it the rise time spec 10ns is measured between the points of 0.3*VIO (max L) and 0.7*VIO (min H)? Anyway, no luck.

I measure:

VSUP: 12.26V

VCCOUT: 5.05V (drops to 0V after 4 min, within spec)

FLTR: 1.498V (drops to 0V after 4 min, within spec)

INH: 12.26V (not connected)

STDBY: 0V

nINT: 0V

My setup is:
VIO: 3.3V with 100nF to GND.
INH: floating.
VSUP: 12V with 100nF/100nF/10uF to GND.
FLTR: 330nF to GND.
VCCOUT: 10uF to GND.
WAKE: to MCU output with 2x 10nF to GND (pin set LOW at boot in software). The functionality was misunderstood, in next revision this will be tied to GND without caps.
SCLK / SDI->MOSI / SDO->MISO: SPI of MCU (no other SPI slaves on bus).
CS: two independent inputs of MCU (no pull-ups).
GPO1: input of MCU (no pull-ups/downs).
GPO2: input of MCU (no pull-ups).
INT: input of MCU (no pull-ups).
RST: output of MCU (no pull-down)
WKRQ: input of MCU (no pull-ups).
CANH/L: 2x 60.4R tied together with 4.7nF to GND.
CANH/L: PESD1CAN tied to GND.

Crystal: ABM11W40.0000MHZ8B1UT
C: 10pF

  • +1
    TI__Mastermind 34270 points

    Hello. 

    From the logic analyzer plot, I see the SPI enable pin is toggling high after the first 4 bytes and not remaining low for the entire 8 byte SPI transaction.  The TCAN4550 will treats the transition of the enable signal as the end of the SPI transaction which is why you are not having any success with your communication.  You will need to modify the firmware or control the enable pin like a GPIO pin if it can't be modified to remain low for the full 8 bytes.

    There are a couple of reasons the TCAN4550 requires this.  The first is that it counts the number of clock cycles to make sure it is an exact multiple of 32 bits, or one word, or data, and because of the R/W opcode, address, and data length information takes up 4 bytes, there is a minimum of 64 bits required for a register SPI transaction.  It is possible to read/write multiple consecutive registers in a single transaction allowing for 64 bits, 96 bits, 128 bits, etc. but always a multiple of 32.

    The second reason is that the TCAN4550 will return the Global Fault Flag bits (register 0x0820[7:0]) on MISO signal immediately following the enable signal transitioning low.  This is to inform the MCU of any important interrupt or status flags that may be time critical.  SPI errors are included in this and can be a way for the MCU to monitor the success or failure of the previous SPI transaction.  If the TCAN4550 detected an error such as too few, or too many clock pulses, it will assume there was noise or some other error that corrupted the data.  If this was a write command (0x61) to the device, the TCAN4550 will discard the data and keep the register's old value.  If this was a read command (0x41) the MCU should consider the value returned as potentially corrupted and repeat the transaction.  Other SPI errors can be from a mismatch between the Length field and the actual data.  For example, if 2 words of data were indicated in the Length field, but the enable pin transitioned high after only a single word (register) was written or read, then the device would treat this as an error.  Likewise, if the Length field was 1, and 2 words of data were written, this too would be treated as an error.

    As you have observed, the device is returning 0x88000000 indicating that the Global Error (GLOBALERR) and SPI Error (SPIERR) bits are being set due to the enable pin transitioning high in the middle of your transaction.

    You can find the SPI signal diagrams and more information about the topics I have discussed in the Programming section of the datasheet.

    Regards,

    Jonathan

  • 0 in reply to Jonathan Nerger
    Prodigy 85 points

    Thank you so much! I didn't notice it, since I wrote my code to explicitly keep the chip select low until the transaction was complete. Problem was that Zephyr also controlled the chip select and pulled it high after each individual spi_write / spi_read.

  • 0 in reply to Ole Kristian Western
    TI__Mastermind 34270 points

    You're welcome!  Let us know if you have any additional questions as you proceed with your development.

    Regards,

    Jonathan