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.
We are bringing up tcan4550 in a Linux environment.
The probe is failing with the error below.
After checking the information below, please provide assistance on what areas require additional confirmation.
[ 1.531193] tcan4x5x spi4.0: Unsupported version number: 0
[ 1.537022] tcan4x5x: probe of spi4.0 failed with error -22
The device tree settings are as follows.
* Commented out the device-state-gpios pin. This is because the INH pin was not connected to the board separately.
It was confirmed that INH remains high when power is turned on.
spi4:spi@fa700000 {
status = "okay";
tcan4x5x: tcan4x5x@0 {
compatible = "ti,tcan4x5x";
reg = <0>;
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <10000000>;
bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
interrupt-parent = <&gpio10>;
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
//device-state-gpios = <&gpio10 6 GPIO_ACTIVE_HIGH>;
device-wake-gpios = <&gpio10 4 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio9 0 GPIO_ACTIVE_HIGH>;
};
};
waveform
The spi input appears to be working normally (di), but the response from tcan4550 appears to be abnormal.
When checking the DO waveform, only 0x88 is still visible.

1st spi wavefoem

2nd spi wavefoem

Hello JONGHYUN,
The SPI Chip Select signal is incorrectly transitioning high after every byte which is aborting the SPI Read or Write transaction. This is resulting in the SPI errors. Please refer to the SPI programming section 8.5 of the datasheet for diagrams of the SPI signal protocol requirements.
The nCS signal needs to transition Low at the beginning of the SPI Write/Read transaction and remain low until the complete SPI Write/Read transaction is complete. The device counts the SCLK cycles to determine if there is the correct number of bits in the transaction as a fault protection mechanism. If there is an incorrect number of SCLK cycles, a SPI Error is set and the device ignores any data for a Write.
The device also has the ability to do write or read multiple words of data in a single transaction. The device also compares the number of bits in the transaction with the expected number based on the LENGTH portion of the first SPI word that contains the address and length information. The datasheet shows both the nCS signal transitions, and an example of a 2 word write and read transactions that you can use as an example.
Immediately following the nCS signal transitioning Low, the device will return the status byte with the most important high level interrupt bits including the SPI Error (SPIERR) flag. The 0x88 being returned in your plots are because of the SPIERR flag, which in turn sets the Global Error (GLOBALERR) flag.
You will need to adjust your SPI drivers to keep the nCS signal low for the entire SPI Write/Read transaction.
Regards,
Jonathan
Thank you for your response.
Upon checking, the current bits per word for the SPI driver is 8.
(I am using PL022 as spi device and the max value is 16)
1. Looking at the datasheet, it says that it uses 32 BIT WORD.
Do I need to support 32 bits per word to use TCAN4550?
2. If I use multiple words, I am also wondering if I need an additional spi driver modification to set nCS to LOW at the beginning of the data and High at the end, regardless of the bits per word.
Hi JONGHYUN,
The TCAN4550 does use 32-bit words for the register and MRAM data, however, it is common for the MCU to use multiple 8-bit or 16-bit words, as long as the total number of bits is correct for the complete Write or Read transaction which is a minimum of 64-bits.
You will likely have to modify the SPI driver to control the chip select signal. Even if you could use 32-bit words, a single register write or read has 64-bits that need to be transferred while the chip select signal is low. The first 32-bits transfers the address and the Length (or number of 32-bit data words that will be in the transaction) and then the next word is the actual 32-bit data word. If it is a Write, the data comes from the MCU. But if it is a read, the MCU keeps clocking the SCLK and receives the 32-bit data from the TCAN4550. Either way, the nCS signal must remain low for the full 64-bits.
When multiple consecutive registers or MRAM space are read or written to in a single SPI transaction, the Length field can be set to the total number and then the nCS should remain low for the total number of bits for all words.
Therefore for a single register R/W you need to have the Length value set to "1", and then keep nCS low for a total of 64-bits.
For multiple word transactions, you will need to keep nCS low for total of 32 + (Length * 32) bits.
Length = 1 -> 64-bits
Length = 2 -> 96-bits
Length = 3 -> 128-bits
etc.
Regards,
Jonathan
Hello Jonathan.
I modified the spi driver and confirmed that the probe was running normally.
I would like to ask two additional questions.
1. The waveform below is visible at 5 second intervals after the probe. Is this normal?
2. Is there a recommended method for verifying operation after the can driver probe?
Hi JONGHYUN,
1. The waveform below is visible at 5 second intervals after the probe. Is this normal?
SPI communication is initiated by the MCU and this looks to be a Read of register 0x1040 which is the CAN RX/TX Error Counter Register. A cyclical read of this register every 5 seconds may be built into the firmware, so I would expect this is operating normally. The TCAN4550 is responding with a value of 0x0000 for this register, so there are no CAN message errors. The first byte on the MISO line immediately following the chip select going low is 0xA0. This is the Global Status Byte corresponding to register 0x0820[7:0]. The GLOBALERR and CANERR bits are set, but this is likely due to a very low level of CAN traffic on the bus. I would expect that a read of register 0x0820 would show the CAN Silent (CANSLNT) bit is set to indicate that the CAN bus has been "silent" for at least 1 second. Given your initial test setup, this is not a concern.
2. Is there a recommended method for verifying operation after the can driver probe?
I don't have a recommended method for verifying operation outside of trying to transmit and receive messages on a CAN bus. If you don't have an external device connected to the CANH/L pins, then you could use the loopback test mode in the MCAN controller.
First you would need to set both the CCE and INIT bits of the Control register to 1 to initialize the configuration mode and allow access to the restricted access bits. (0x1018[1:0] = 2'b11)
Then you will need to set both the TEST bit in the control register to 1 (0x1018[7] = 1'b1), and the LBCK bit in the Test Register to 1 (0x1010[4] = 1'b1) to enable the external loop back mode. The device will loopback the message it sent on the CAN bus to itself and ignore any Acknowledge errors.
If you didn't want to see this test message on the CAN bus, you could disable the transmitter by setting the MON bit in the Control register to 1 and this will simply loopback the message internally. This method may be useful to verify operation if it connected to a working CAN bus that you didn't want to disrupt.
Regards,
Jonathan