TCAN4550-Q1: SPI read write error and spi stops receiving

Yogesh Modi1

Part Number: TCAN4550-Q1
Other Parts Discussed in Thread: TCAN4550

Hello,

I'm trying to interface TCAN4550 ic with STM controller, which I've done successfully, but when I communicate data a high speed simultaneously in 2-3 boards, then one of the receiver stops receiving (It is still transmitting) So I checked the registers and I found that this is due to SPI Errors (Write underflow and read overflow).

So please help me to resolve this SPI issue.

SPI Specs:

hspi2.Instance = SPI2;
hspi2.Init.Mode = SPI_MODE_MASTER;
hspi2.Init.Direction = SPI_DIRECTION_2LINES;
hspi2.Init.DataSize = SPI_DATASIZE_8BIT;
hspi2.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi2.Init.CLKPhase = SPI_PHASE_1EDGE;
hspi2.Init.NSS = SPI_NSS_SOFT;
hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_4;
hspi2.Init.FirstBit = SPI_FIRSTBIT_MSB;
hspi2.Init.TIMode = SPI_TIMODE_DISABLE;
hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
hspi2.Init.CRCPolynomial = 7;
hspi2.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
hspi2.Init.NSSPMode = SPI_NSS_PULSE_ENABLE;

SPI Communication API's:

void AHB_WRITE_32(uint16_t address, uint32_t data)
{
AHB_WRITE_BURST_START(address, 1);
AHB_WRITE_BURST_WRITE(data);
AHB_WRITE_BURST_END();

}

void AHB_WRITE_BURST_START(uint16_t address, uint8_t words)
{
uint8_t txDataTemp[4];
txDataTemp[0]=AHB_WRITE_OPCODE;
txDataTemp[1]=((address & 0xFF00)>>8);
txDataTemp[2]=(address & 0x00FF);
txDataTemp[3]=words;

HAL_GPIO_WritePin(TCAN_CS_GPIO_Port, TCAN_CS_Pin, GPIO_PIN_RESET); //chip select low
WAIT_FOR_IDLE;
HAL_SPI_Transmit(&hspi2, txDataTemp, 4, 50);
//WAIT_FOR_IDLE;
}

void AHB_WRITE_BURST_WRITE(uint32_t data)
{
uint8_t txDataTemp[4];
txDataTemp[0]=((data & 0xFF000000)>>24);
txDataTemp[1]=((data & 0x00FF0000)>>16);
txDataTemp[2]=((data & 0x0000FF00)>>8);
txDataTemp[3]=(data & 0x000000FF);
//WAIT_FOR_IDLE;
HAL_SPI_Transmit(&hspi2, txDataTemp, 4, 50);
//WAIT_FOR_IDLE;

}

void AHB_WRITE_BURST_END(void)
{
//WAIT_FOR_IDLE;
HAL_GPIO_WritePin(TCAN_CS_GPIO_Port, TCAN_CS_Pin, GPIO_PIN_SET); //chip select High
}

uint32_t AHB_READ_32(uint16_t address)
{
uint32_t returnData;

AHB_READ_BURST_START(address, 1);
returnData = AHB_READ_BURST_READ();
AHB_READ_BURST_END();

return returnData;
}

void AHB_READ_BURST_START(uint16_t address, uint8_t words)
{
uint8_t txDataTemp[4];
txDataTemp[0] = AHB_READ_OPCODE;
txDataTemp[1] = ((address & 0xFF00)>>8);
txDataTemp[2] = (address & 0x00FF);
txDataTemp[3] = words;
HAL_GPIO_WritePin(TCAN_CS_GPIO_Port, TCAN_CS_Pin, GPIO_PIN_RESET); //chip select low
//TCAN_CS_GPIO_Port->BSRR = (uint32_t)TCAN_CS_Pin;
//WAIT_FOR_IDLE;
HAL_SPI_Transmit(&hspi2, txDataTemp, 4, 50);
//WAIT_FOR_IDLE;

}

uint32_t AHB_READ_BURST_READ(void)
{
uint8_t rxDataTemp[4];
uint32_t returnData;
//WAIT_FOR_IDLE;
HAL_SPI_Receive(&hspi2, rxDataTemp, 4, 50);
//WAIT_FOR_IDLE;
returnData = (((uint32_t)rxDataTemp[0]) << 24) | (((uint32_t)rxDataTemp[1] << 16)) | (((uint32_t)rxDataTemp[2]) << 8) | rxDataTemp[3];
return returnData;
}

void AHB_READ_BURST_END(void)
{
//WAIT_FOR_IDLE;
HAL_GPIO_WritePin(TCAN_CS_GPIO_Port, TCAN_CS_Pin, GPIO_PIN_SET); //chip select High
}

Thanks & Regards

Yogesh

over 4 years ago

0 Eric Schott1 over 4 years ago

TI__Guru 52025 points

Hi Yogesh,

The write_underflow and read_overflow flags are asserted when a SPI sequence ends will a different number of data bytes than was described in the length byte of the header. This is common if a burst read/write operation doesn't know how many bytes it wishes to receive/send before the transaction begins or if this field is not properly updated before the transaction starts. This doesn't corrupt any data or negate any writes, and is meant only to indicate to the processor that some discrepancy was detected. I don't expect this to have caused an issue where the receiver was no longer able to relay data to the controller.

Could you describe the device behavior more when it stops receiving?

Does the SPI interface become completely unresponsive (read all 0s), or is it the CAN receiver that appears to stop (RX FIFO not populating for example).
How long does the system operate (in the 2-board configuration) before one of the receivers stops responding? Immediately, seconds, minutes?
What other interrupt flags are set after the receiver stops responding? Particularly, are any other flags set in the status register ('h000C)? Is anything set in the Interrupt register ('h0820)?
Are non-diagnostic registers ('h0800 +) accessible when the receiver stop responding? Check a register with expected known values such as Mode Control ('h0800).
- Non-diagnostic registers are dependant on the clock input. Loss of response may indicate a problem with the clock signal or crystal oscillator.
If available, check the Mode Control register to confirm the device is in normal mode (I would expect this to be the case if it is still transmitting).

I don't see any issues in the code you shared above. Based on the fact that you have been able to successfully interface with the device before, it sounds like some added complexity from hooking up multiple boards is causing the issue. If one of my above questions does not point to a specific SPI or crystal related issue, would you be able to share more information about the test setup? A block diagram showing how each board is connected to the MCU and CAN bus would likely be sufficient.

Regards,
Eric Schott

0 Yogesh Modi1 over 4 years ago in reply to Eric Schott1

Prodigy 30 points

Hi Eric,

Thanks for your reply,

The page was on maintenance so I was not able to reply.

Eric Schott1 said:
Does the SPI interface become completely unresponsive (read all 0s), or is it the CAN receiver that appears to stop (RX FIFO not populating for example).

No only Receiving stops, Card is still transmitting the message to other card.

Eric Schott1 said:
How long does the system operate (in the 2-board configuration) before one of the receivers stops responding? Immediately, seconds, minutes?

When I start the communication between two cards by sending a message (5 bytes) every 50 milli seconds (both cards transmit to each other at same instance), then one of the cards stops receiving in only few minutes after receive only 400-500 messages.

Eric Schott1 said:
What other interrupt flags are set after the receiver stops responding? Particularly, are any other flags set in the status register ('h000C)? Is anything set in the Interrupt register ('h0820)?

When receiver is working fine:

Status ('h000C) - 0x8

Interrupts ('h0820) - 0

MCAN Interrupts ('h0824) - 10000

Error Count ('h1040) - 0

When receiver stops responding:

Status ('h000C) - 0x4000a

Interrupts ('h0820) - 0x8a

MCAN Interrupts ('h0824) - 0x10105

Error Count ('h1040) - 0

Eric Schott1 said:
Are non-diagnostic registers ('h0800 +) accessible when the receiver stop responding? Check a register with expected known values such as Mode Control ('h0800).

Yes I'm able to read the non-diagnostic register when receiving stops.

Mode Control ('h0800) - 0x84004a0

Eric Schott1 said:
If available, check the Mode Control register to confirm the device is in normal mode (I would expect this to be the case if it is still transmitting).

Yes the device is in Normal Mode, as bit 7:6 are 10 - Normal Mode

Block Diagram:

I'm using the Flat cable for communication with piercing pins (no connectors)

Please have a look on diagnostic register output once as I got only SPI errors.

Thanks & Regards

Yogesh

0 Eric Schott1 over 4 years ago in reply to Yogesh Modi1

TI__Guru 52025 points

Hi Yogesh,

Thank you for your answers and readouts of the interrupt registers.

It looks like the TCAN4550 is reporting two significant errors. The first is a SPI error (Status bits 1+3, Interrupt bit 3) and that RX FIFO 0 is full (MCAN_INT bit 2 ,Interrupt bit 1). It sounds like the second error concerning the full RX FIFO is what's causing the device to stop receiving. Be sure that after each read of the FIFO, the MCU clears the corresponding index for re-use. An outline of the correct RX FIFO reading can be found in section 4.3.2 of the software user's guide. The SPI error may be contributing this by causing either the read or clearing write to fail. Be sure that the software checks the state of the SPIERR flag periodically to make sure that the previous transactions (particularly writes to TCAN4550) were successful. For debug, I would recommend checking the state of this register after writing to clear the FIFO index to make sure the clear was successful. If not, the format of the message should be checked to make sure that valid address and data values are used.

I hope this information helps. Let me know if this helps resolve the issue or if you find out anything from further tests.

Regards,
Eric Schott

Interface

Interface forum

TCAN4550-Q1: SPI read write error and spi stops receiving