CC2642R-Q1: SPI use case enter overrun from time to time

Hi,

Thank you for reaching out. Can you clarify if this behavior occurs on the latest SDK? Between the release of the 6.30 SDK and the latest SDK, there have been many fixes and improvements made to the SDK (including the drivers). It is possible one of these fixes or improvements may have an impact on the behavior you are seeing. Could you also clarify if you are seeing this on a custom board or a launchpad?

Best Regards,

Jan

hi ,this problem occurs on the custom board and CC2642 as SPI master, because our project development is based on the 6.3 SDK, we can not easily switch to the latest SDK. In addition, we can easily reproduce the problem, so you can provide a patch based on the 6.3 SDK to help us find the root cause.

Hi Sen,

I've reached out to the driver team to get some more information. I'll update you once I get a reply. Many members of the team are out on break until January 2nd, so expect a reply closer to January 4th.

In the meantime, I'll try to reproduce the issue on my end.

What example project are you using?
What are the parameters used for the SPI communication?

Best,

Nima Behmanesh

Hi Nima,

    SPI project: ti\simplelink_cc13xx_cc26xx_sdk_6_30_00_84\source\ti\drivers\spi;

    SPI parameters(SPI_MODE_BLOCKING):

Hi Seng Weng,

I've reached out to the driver team to get a comment on this. Expect an answer tomorrow morning.

Best,

Nima Behmanesh

Hello,

I have not received a response quite yet. Will update you tomorrow on the status of this.

Best,

Nima Behmanesh

Hi,

I have a couple questions:

What is the setup for your SPI? In our examples, we have pin dedicated to RX ready. If the RX isn't ready, and you transfer data you run into this state.
Were you able to reproduce this issue on a TI Launchpad?

Best,

Nima Behmanesh

hi，

    1.The SPI cfg:

 2.We call the following api to receive SPI data：

3.How to ensure that RX is ready?

Hello,

You would need to have a separate GPIO pin that would indicate that a transfer has completed and that the peripheral is ready to receive more data.

Best,

Nima Behmanesh

hi Nima,

        Our SPI transmission is a synchronous mechanism. The receiving and sending interfaces are called in the same task. There is no case that the receiving is called before the sending is completed. Please also provide the reason for the possibility according to the overrun by the spi register.

Hi,

SPI overrun occurs when SPI controllers send data to a peripheral before the RX data is read.

Can you verify that the RX data is being read?

Using a GPIO to indicate that RX is ready (that all data has been read and the RX buffer is empty) and having TX  read that pin, indicating that RX is ready to receive, should alleviate this error.

Best,

Nima Behmanesh

Hi , We measured the PIN of SPI and found that 300 us was interrupted in the middle of data transmission, which led to data failure. It was initially suspected that it was caused by abnormal interruption. We wanted to confirm whether the SPI driver in SDK was protected from interruption during data transmission.

Hi Sen,

The DMA will handle this, so interruption should not be a concern. Are you using blocking or non-blocking mode? If a syn pin is used in polling mode, it should not be a concern either.

Best,

Nima Behmanesh

Hi Nima,

          SPI uses blocking mode. We found that changing the buffer size of DMA can solve this problem. The size is changed from 10 to 255. Do you know why this change has this effect?

Hi Sen,

This could be because the buffer is being overrun too quickly. I'm happy you were able to solve the issue.

Best,

Nima Behmanesh