CC1201: CC1201 SPI Timing

Hi

Just wanted to let you know that we are looking into this, but I am waiting for feedback from the responsible designer. He has not been in the office today.

Siri

Siri,

Thanks - please let me know whether you need any further info from me. This is currently blocking issue for me.

Thanks
santosh

Hi Santosh

First of all, I 'am sorry for the late reply. I have talked to one of the designers and he could confirm that the 100 ns delay should not be needed for the FIFO access, and max frequency is 7.7 MHz so you are below that.

If you lower the speed from 6 MHz, will it then work without delay between bytes?

Have you looked at your SPI lines with a scope to see that all your edges etc. are within the spec?

Writing to the FIFO without delay should be faster than doing it with delays in-between, so it really does not make any sense at all that your TX FIFO will underflow in the case where you have no delays.

Can you make a test were you write the complete packet to the TX FIFO before strobing TX (The packet needs to be smaller than the FIFO size)

Does this work?

If you write 120 bytes to the TX FIFO this way and then read the NUM_TXBYTES register to see how many bytes has been written, is the number correct?

It would also be helpful if you can share a plot of the SPI traffic both in the case that is OK, and in the case that fails.

How many bytes are left in the FIFO when you start to write to it?

How many bytes do you write, and what is the time it takes to write these bytes in the two different cases?

Are you testing on our HW or have you made your own?

What data rate is the RF configured for?

I hope answering the above questions and doing some more testing will help us figuring our what is wrong.

BR

Siri

Hi Siri,

Really appreciate the response. The delay didn't hurt much since i can get back onto this only in next couple of days.

Reducing the SPI speed hasn't helped. The controller (LPC) is running at 180MHz right now. I have not tried reducing the controller speed as yet.

Regard SPI edges all look very good, there is little bit of ringing but nothing that would stand out. I will capture the scope traces and post it by Monday.

Radio is configured for 1Mbps, currently i am sending 12 byte packets, the final application will have 18 bytes. I have tried strobing after i write the packet, but that did not make any difference. But i can redo that test as well. The failure happens within the first couple of packets. In the good scenario, the TXFIRST and TXLAST pointers increment nicely after every packet write, while in the bad case TXLAST is one less. Radio is configured for variable packet length - so there is a mismatch between length and bytes in fifo and marcstatus reads an error.

The HW is our design, right now we have 5 different designs with CC1201, this particular design has higher throughput requirements than others. I had a previous version of this design where i was doing back to back transmit with the controller running at 96MHz and i didn't have any issues.

In the working case, the total transaction time is about 50uS and in the non-working case it is about 17uS.

I will provide you with following info:
a) scope traces for both working and non-working case
b) Test with strobe TX after write to FIFO

I will test with controller running at a lower speed as well.

Thanks, and again really appreciate the support.

Hi Siri,

I have attached traces for the working and non-working scenarios. In both cases STX is being issued after FIFO write is complete. The data string is "Hello-World" radio is configured in variable packet length mode.

Overall in this case the total transaction time to complete FIFO write is about 45uS. 

1. Working Case full capture - 

2. Not Working Case Full Capture

In this case the total transaction time is around 25uS.

Working case FIFO capture 

Not working case FIFO capture.

In both cases same data is being sent.

I did try changing the controller speed, that doesn't really help. Whether i keep the strobe on, or strobe after the FIFO write is complete, the result is the same. So i have not captured traces where i have STX is on and FIFO is being updated.

Thanks

santosh

I will try to reproduce your problem here but it might take a couple of days, as it is not possible to do SPI back-to-back with the MCU that is on our CC1200 Kit. In the mean time, can you read back the FIFO content in both failing and non-failing case using direct FIFO access? Also, what value do you read for the NUM_TXBYTES in the two cases?

Siri

Siri,

Thanks for the update. I will try replicating your test with a lower data rate. However, my application does require 1Mbps data rate. I will test with different data rates, hopefully that will help in narrowing down the issue.

Thanks
santosh