Compiler/TCAN4550EVM: D3-TDA3xx-rvp can not receive 64bytes CAN FD data correctly through TCAN4550EVM

Hi Ethan,

How are you polling for the Received data?  I see that your byte value pattern is continued throughout the total data log where each 4 byte word of data  is received in inverted order.  By that I mean that your expected pattern would be:

[03,02,01,00] [07,06, 05, 04] [0B, 0A, 09, 08] ...

I see in your data log that the first word is received with each byte is returned in a single sample.  However, the first byte of the second word is 07 and is returned for 28 samples in the log with a total time stamp delta between the 00 and final 07 value equal to 2mS.  Most samples are 61uS apart with a couple being 91uS, 92uS and 122uS.  But then the next expected data value of 06 is returned, followed by 05, and then 04 each with a single sample to complete the second word of data.

Then the beginning byte of the third word is once again stuck for multiple samples (19 samples) with a time stamp delta between the final 04 byte and the final 0B byte of 1mS.  However unlike the second word, the second byte of the third word is 0A and it too gets stuck for multiple samples in the log with unknown length since the log ends before the next value received. 

The fact that the data values are in the correct order leads me to believe that they are probably being received correctly by the TCAN4550 and are placed in the MRAM memory correctly.  And I suspect there is some problem with the SPI reading of the returned data values into your data log.

Can you continue to read the data beyond the 67 bytes you are currently running to determine if the pattern continues and that all the data is actually returned eventually?  Also, I would be curious to know if there is some pattern to the time stamp delta between the stuck bits that might lead to some other process happening in the processor that is causing a disruption to this data read such as another interrupt, etc.

Have you manually tried to read the MRAM values directly to verify the contents of the memory allocated for the RX data?

Since the first stuck byte seems to be the first byte of a word, can you check the code to verify how subsequent words are handled by the SPI read to ensure there aren't any memory overlaps, or other issues with how that code works for multiple word reads. 

Also, are you reading the data with single word SPI reads, or multiple word SPI reads?

Regards,

Jonathan

Hi Jonathan,

I modified Utils_mcspiWrite() function to send SPI Header and read data with Multi-word.

Received data is stored in dataPayload.

Regards,

Ethan

/**
*******************************************************************************
*
* \brief Function to write to the McSPI device
*
* \param fd Pointer to the McSPI commnication Handle.
* \param pBuff Pointer to the buffer to which the data is written.
* \param len Number of bytes to read.
*
* \return SYSTEM_LINK_STATUS_SOK if operation successful,
* SYSTEM_LINK_STATUS_EFAIL otherwise.
*
*******************************************************************************
*/
Int32 Utils_mcspiWrite(void * fd, UInt8 *pBuff, UInt16 len)
{
UInt32 size = 0;
Int status = IOM_COMPLETED;
Mcspi_DataParam issueDataparam = {0};
Mcspi_DataParam reclaimDataparam = {0};
Ptr pReclaimDataparam;
Int32 retVal = SYSTEM_LINK_STATUS_SOK;
Utils_mcspiCommHandle commHndl = (Utils_mcspiCommHandle) fd;
Mcspi_FifoTrigLvl fifoLevel;

issueDataparam.outBuffer = (UInt8 *) pBuff;
issueDataparam.bufLen = (UInt32) len;
issueDataparam.inBuffer = (UInt8 *) pBuff;
size = (UInt32) len;

if (len < (UInt16)32)
{
fifoLevel.rxTriggerLvl = len;
fifoLevel.txTriggerLvl = len;
}
else
{
fifoLevel.rxTriggerLvl = 32;
fifoLevel.txTriggerLvl = 32;
}

status = GIO_control(commHndl->mcspiHandle, IOCTL_MCSPI_SET_TRIGGER_LVL,
&fifoLevel);
if (IOM_COMPLETED == status)
{
/* Issue the first & second empty buffers to the input stream */
status = GIO_issue(commHndl->mcspiHandle, &issueDataparam, size,
NULL);
}

if ((status != IOM_PENDING) && (status != IOM_COMPLETED))
{
Vps_printf(" UTILS_MCSPI: Failed to issue empty buffer to stream!!\r\n");
}
/* Reclaim is done after every issue and buffers are not primed. If
* the buffers are primed next transfer is initialized as soon as
* the first one is completed. We wont be able to ensure transfer
* initializaton on Slave before master for second buffer
*/
pReclaimDataparam = (Ptr) & reclaimDataparam;
status =
GIO_reclaim(commHndl->mcspiHandle,
(Ptr *) &pReclaimDataparam,
NULL,
NULL);

if (IOM_COMPLETED != status)
{
Vps_printf(" UTILS_MCSPI: SPI Write Failed\r\n");
retVal = SYSTEM_LINK_STATUS_EFAIL;
}
else
{
retVal = (Int32) len;
}
return retVal;
}

Hi Ethan,

This appears to be a processor firmware related issue and not a problem with the TCAN4550 receiving the message through the CAN FD bus.  I will need to move this thread to the Processor forum so that somebody can support you that has direct experience with that processor and the firmware functions you are trying to modify. 

Once I reassign the thread to the processor forum somebody should pick up the support and respond shortly.

Regards,

Jonathan

Hi Ethan,

Are you seeing any errors while transmitting from PCAN and while receiving on TCAN? Also, your MCAN message RAM configurations look fine.

Thanks & Regards,
Vivek Dhande.

Texas Instruments (India) Pvt Ltd

Hi Vivek,

I didn't see any error messages while transmitting and receiving.
I have tried single-word method to receive 64 bytes data, and it works.
But I don't know why multi-word method can't get the right result.

Regards,
Ethan

Hi Ethan,

By multi-word, you mean SPI transfers, right? If yes, are you getting any SPI errors during multi-word transfers?

Thanks & Regards,
Vivek Dhande.

Texas Instruments (India) Pvt Ltd

Hi Vivek,

Yes, it is.

I didn't see any SPI errors either.

Regards,
Ethan

Hi Ethan,

Let me check with the SPI expert and will then get back to you. Thank you for your patience.

Thanks & Regards,
Vivek Dhande.

Texas Instruments (India) Pvt Ltd

Hi Ethan,

Thank for your patience.

It is taking a longer time than expected to get in touch with SPI expert. It may require more time. I'll keep you posted once I have the update. 

Thank you again for your patience. 

Thanks & Regards,
Vivek Dhande.

Texas Instruments (India) Pvt Ltd

Hi Vivek,

It's okay.
Thank you so much for your help.

Regards,
Ethan

We have some additional information to share on this thread.

Hi,

Are you still facing this issue or it is resolved?

below is my understanding about the setup, let me know if it is correct.

TDA3xx is connected to TCAN using SPI interface. TCAN is connected to external CAN device (PCAN).
TCAN receives the data over CAN interface from external device (PCAN)
TCAN sends the data to TDA3xx through SPI interface.

Currently the data received from external CAN device PCAN is verified at TCAN message ram.
The issue is seen when receiving the data at TDA3xx through SPI in burst mode only.

How is the SPI configured? What is the frequency of the data transfer?
What is the difference in the SPI configuration between the working and on working case?
Please share the difference in APIs/Parameters and the SPI register setting

Regards,
Prasad

Hi Prasad,

This issue has been resolved by decreasing SPI clock speed(18MHz--->8MHz).

Thanks for your help.

Regards,
Ethan