CC2642R: When CC2642 run as spi slave mode, the master maybe read wrong data

I have been struggling with this problem for a long time, I have used CC2640 and CC2642, both have this problem. Hope someone can help me fix this, thanks a lot!

Kang Cheng,

In there image you shared, it seems like there are 8 bytes of leading zeros, but the rest of the data is in the correct order. This seems like it could be related to some initialization or an empty buffer. Do you see this issues consistently or only sometimes? Does the problem occcur in places besides the initial bytes?

You mention

KANG CHENG said:

{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}

The master will get {0x04, 0x05, 0x06, 0x07, 0x08, 0x01, 0x02, 0x03}

This seems like it could be an endianness mismatch between the devices. How is the master configured?

To clarify, when you have the scope on the SPI lines, do you see the data coming from the CC2642R device as expected? What about if you connect 2 CC2642R devices (1 master, 1 slave) together? Is the data sent and received correctly?

It may also be helpful if you share you SPI initialization and TX/RX code.

Regards,

Daniel

Hello Daniel, thank you for your reply, first image, the 8bytes leading zeros, it is because in my spi tx buffer, the value of last 8 bytes is zero, what I want to express is that it seems like the whole TX buffer like a loop, the last 8 bytes had been shifted to the front. And I had tested this, I sent 255 bytes, {0, 1 , 2,...254}, it became {246, 247, 248, 249, 250, 251, 252, 253, 254, 0, 1, 2...}

Second question:

Nope, the scope on the SPI line(MISO) is different with the expected ( CCS debuger shows), but the MOSI is correct, so the result is slave device(CC2642) can receive the data from master device(Other chip) correctly, but the master cannot receive the expected data from slave.

attach the code of slave:

void SlaveSpi_Init(void)
{
    SPI_init();
    SPI_Params_init(&spi_params);
    spi_params.bitRate             = 1000000;
    spi_params.frameFormat         = SPI_POL0_PHA1;
    spi_params.mode                = SPI_SLAVE;
    spi_params.transferMode        = SPI_MODE_CALLBACK;
    spi_params.transferCallbackFxn = transferCallback;
    /* Configure the transaction */
    transaction.count = SPICOM_MAX_DATABUFF;
    transaction.txBuf = tx_buff;
    transaction.rxBuf = rx_buff;
    /* Open the SPI and initiate the first transfer */
    spi_handle = SPI_open(Board_SPI0, &spi_params);
    SPI_transfer(spi_handle, &transaction);
    SPISLAVE_RunMode = Slave_SPI_SYNC_MODE;
}

and in the transfer en call back:

void transferCallback(SPI_Handle handle, SPI_Transaction *transaction)
{
    /*Start another transfer*/
    Slave_Rx_analysis();/* in the SPI rec callback, prepare the SPI transmit data */
    SPI_transfer(handle, transaction);
}

And this is just an occasional phenomenon. But once this happen, it cannot recover anymore unless perform a reset of slave chip.

Kang Cheng,

Is it possible you are modifying your Tx buffer at some point in the code? From the SPI.h documentation:

From calling SPI_transfer() until transfer completion, the SPI_Transaction structure must stay persistent and must not be altered by application code. It is also forbidden to modify the content of the SPI_Transaction.txBuf during a transaction, even though the physical transfer might not have started yet. Doing this can result in data corruption. This is especially important for slave operations where SPI_transfer() might be called a long time before the actual data transfer begins.

Additionally, can you verify that the SPI_transfer() is complete before another callback is triggered?

Regards,

Daniel

Hello Daniel, thanks for your advice.  What confused me is why it cannot recover any more once the data error happen, I mean if it is just a problem caused by critical region, it should be a temporary and occasional phenomenon and can be recovered I think. And also the error data seems like loop around.

Since the device is hanging, I would recommended using some of the TI-RTOS debugging tools to better determine the state of the device when it hangs. 

Please see the section Task 2 - Debugging Tools in the TI-RTOS Basics SimpleLink Academy lab: https://dev.ti.com/tirex/explore/node?node=AAvd2v6HXXe-QpjluM.XgA__pTTHBmu__LATEST The execution graph and Runtime Object View are both helpful tools in determining root cause of the system not responding.

For a more detailed explanation of the debugging tools, see the debugging section of the user guide, here: https://dev.ti.com/tirex/explore/node?node=AORHSvJNCJkn6rS93wDgGg__pTTHBmu__LATEST 

Regards,

Daniel