LAUNCHXL-CC26X2R1: SPI Slave 0 on first frame

Shyam Shankar79

Hello M-W,

I would like to reopen this post with a related question.

Its concerning the 0 byte being transmitted by slave upon the SPI transfer.

If I call 2 SPI transfers back to back without delay then in the first transfer 0 is sent first, but in the second transfer it appears to avoid that behaviour. i.e. Say, I want to transfer 2,3,4 on first transfer; then 5,6,7 on the second transfer The data is received as 0,2,3 on first transfer and then 4,5,6 on the second(due to the 0 pre pended on the first transfer).

I do the same with a 1 or 2s delay in between transfers and what I get is 0,2,3 on first transfer and 0,5,6 on the second.

How do I workaround with this? I have transfers with and without delays to be implemented in my code.

Also is this issue solely in the Launchapad or would it be in the Chip CC2652 as well.

Regards,

Shyam

over 7 years ago

0 TER over 7 years ago

TI__Guru**** 317180 points

Could you please post a plot showing the transfer of all the transfers you are referring to?

0 Shyam Shankar79 over 7 years ago in reply to TER

Expert 2330 points

Hi TER,
I am sorry. Unfortunately, currently I am unable to post a plot. I shall try to provide a plot.
But I had discussed the issue previously as well , I guess, and had mentioned of this being a bug in the TI launchpad cc26x2r1.
The following is quoted from the cc26x2r1 SPI Slave example provided by TI (readme.html) :

"Note: The SPI peripheral on CC13x0, CC26x0, and CC26x0R2 devices have a bug which may result in TX data being lost when operating in SPI slave mode (SSI Advisory 04 & 05 in device errata). This bug causes the first SPI frame sent from the slave to be 0 instead of the actual data. When the master prints the received message to the display, the 0 will be interpreted as a NULL termination character & the message will not be printed. When this occurs, halt the master SPI device & check the contents of the receive buffer; the slave message should have been received with the first frame as 0."

But the issue is that if my transfers are immediate without much delay, then 0 gets pre-pended only for the first transfer. This would make it hard to program, like I had mentioned in the previous post.

Regards,
Shyam

0 TER over 7 years ago in reply to Shyam Shankar79

TI__Guru**** 317180 points

I read part of your previous thread and based on what I saw there I wanted to see the SPI communication plot before looking further into the details.

0 Shyam Shankar79 over 7 years ago in reply to TER

Expert 2330 points

Hi,
Could you please tell me if the reported bug in the SPI slave example readme file (which I had quoted in the previous post) is relating to the Launchpad or will it be present in the cc26x2 Chip?

Regards,
Shyam

0 TER over 7 years ago in reply to Shyam Shankar79

TI__Guru**** 317180 points

I need to check this with someone that will be back in the office next week.

0 Shyam Shankar79 over 7 years ago in reply to TER

Expert 2330 points

Okay. Thanks for the time.

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to Shyam Shankar79

TI__Guru 58425 points

Hi Shyam,

I believe this is the same behavior as discussed in this thread:

e2e.ti.com/.../2807384

If you agree, are you OK with us closing this thread and focusing on the the other thread?

0 Shyam Shankar79 over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2330 points

Yes M-W. You may close this thread.
I do hope we reach a solution to this in the thread link you have provided. I shall keep a watch on the other thread.

Regards,
Shyam

Other wireless

Other wireless technologies forum

LAUNCHXL-CC26X2R1: SPI Slave 0 on first frame