This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am designing a device that will interface with the Piccolo's SPI port. Through the course of ensuring proper & sufficient setup and hold times, I have noticed what appear to be several key issues in the SPI Slave Mode External Timing requirements (as indicated on page 106 of the TMS320F2806x Piccolo™ Microcontrollers Datasheet, SPRS698E). I wonder if anyone else has run into these potential issues?
1. Pulse duration, SPICLK high and SPICLK low (items no 13 and 14 of table 6-37): The maximum time for SPICLK high is 0.5 x the SPICLK cycle time (0.5tc(SPC)S per the table). The maximum time for SPICLK low is also 0.5tc(SPC)S, per the table. On one hand, the table would have you believe that if either of these pulse durations is slightly less than half the SCLK period, then timing is OK. But the moment you reduce the high pulse duration, you increase the low pulse duration. This implies both pulse durations must be exactly one half the period, with no margin! Can anyone clarify this timing requirement?
2. Related to #1, above: Why must the slave have such a stringent duty cycle requirement on SCLK when the Master mode can generate asymmetrical SCLKs? Insight as to what's going on inside the SIP peripheral would be helpful (though probably TI proprietary).
3. Why are several of the parameters based on the SPICLK cycle time ( tc(SPC)S ) at all? The clock is being generated externally and delivered to the slave. How is it that the SPI port would even care as long as the minimum SCLK cycle time is satisfied? This does not seem like an appropriate way to spec the timing as the following example might illustrate: Suppose we are interested in determining when/how long SPISOMI data is valid. If SCLK is externally generated at 8MHz (tc(SPC)S = 125 ns cycle time), then using the numerically indexed parameters of table 6-37, the SPISOMI valid time is calculated as:
t16 + (0.5)tc(SPC)S - t15
= 0.75tc(SPC)S + (0.5)tc(SPC)S - 21 ns
= 93.75 ns + 62.5 ns -21 ns
= 135.25 ns. But this is longer than the SCLK period!
Bottom line: the datasheet is seemingly unclear. Perhaps it is my interpretation of the datasheet, but I could sure use some guidance on the proper interpretation. I'm not sure how anyone can design an interfacing design with the spec as it is written. But I'm sure people have done it.
Is there any better or more explanatory references than the Datasheet and the Tech Ref Manual? Are there simply typos in the existing Datasheet?
Bob,
I'm also trying to use the Piccolo as a SPI slave and am finding issues in the datasheet.
Based on the SPI timing specs it doesn't look like two Piccolo's could talk to each other at the rated maximum freq of 10MHz.
The time it takes the slave to put the data on the bus (T15 delay time) is 21ns.*
The setup time (T10) is 26ns.
The minimum clock pulse duration (T2) is (0.5tspc -10) which is 40ns in the case of a 10MHz SPICLK. So 40ns is the minimum available time to latch valid data, but the minimum total time required to latch valid data = 21 + 26 = 47ns.
*In testing I'm finding the delay time (T15) can be up to 50ns which is over double the spec.
Dave
Hi Dave,
Your note about T15 is interesting to me and consistent, I think, with what I've seen. I was looking at a 1-bit-wide data pulse on the Slave's data output, comparing to the SCLK. Watching the scope continuosly triggering on the first rising edge of the SCLK, I could see the pulse "dancing" between two locations. The pulse was meeting timing in one case, but then would move one SYSCLK period (12.5 ns in my case) to the right (exceeding the T15 spec).
It would appear that the DSP SPI peripheral samples the SCLK input and acts upon this sampled info. A little history: initially, I had an 8MHz SCLK waveform that had a 40% duty cycle. Things appeared to work just fine. But upon further examination of the Piccolo datasheet, I realized I had to change this to a 50% duty cycle. To do so, my SCLK master now needed to output the falling SCLK edge (latching edge) on a falling edge of its HF internal clock. Since this HF clock is synchronized with the DSP's external clock, I believe SCLK falling edge is now nearly coincident with the falling edge of SYSCLK within the DSP. It was only upon making this change that the "dancing" referenced above became evident.
Until TI chimes in, I am merely speculating on the sampling nature of the slave SPI behavior. And while it may be an interesting observation, it doesn't clear up any of my datasheet confusion I'm afraid.
Sincerely,
Bob
Bob,
I think you're right that SPICLK is sampled. I increased the SYSCLK freq from 50 to 80MHz and T15 is now ~30ns instead of 50 in our case. In fact, it jumps around between 25 and 40ns further supporting your sampling theory.
Dave
Bob,
To fix the "sampling" issue TI reminded me to set the GPxQSEL register for the SPI pins to asynchronous (3).
Dave
Bob,
Apologies for the delay, there has been a little back and forth while we looked into your questions.
1) As long as the minimum pulse width is being met, then the max will be a ‘don’t care’.
2) You are correct that a MAX timing does not make sense. As long as the minimum pulse duration is met for both High and low pulse, the SPI should operate properly. If SPICLK is significantly slower than LSPCLK, then an asymmetric clock will be ok.
3) We are looking at how this is implemented in the design, but T16, tv(SPCL-SOMI)s, will in fact be held until the next clock edge. If no clock ever comes, the data will still be held. This is incorrect on the diagram as well as the timing provided. Ideally, SOMI will have been sampled at the second clock edge.
As David has seen, the QSEL configuration will have an impact on the output of the SPI signals. Please verify that your QSEL is properly configured to be Asynchronous w.r.t. SYSCLK on the SPI input signals.
We are still discussing this with our design team and will be revising the datasheets to reflect our findings.
I hope this will help you out. Of course, if you still have questions, don't hesitate to ask.
-Mark
Mark,
Thank you for your time and effort to answer these questions. Is it possible to quantify "If SPICLK is significantly slower than LSPCLK" as you've indicated in 2), above? Would a factor of 5x, 8x, or 10x suffice?
If I may, I'd like to ask one additional question. Note 3 of Table 6-37 of the datasheet says the following:
Internal clock prescalers must be adjusted such that the SPI clock speed is limited to the following SPI clock rate:
... Slave mode transmit 10-MHz MAX, slave mode receive 10-MHz MAX.
Is this an absolute maximum clock rate as the note suggests? Specifically, if an external clock is driving the DSP at 10MHz, PLL1 is multiplying up to 80MHz internally, and the prescalars are adjusted such that the SPI clock rate is 10MHz (i.e. dividing SYSCLK by 8), would this spec be violated if the external clock was running fast? I assume that since everything would scale with the exernal clock source, then SCLK would exceed 10MHz and this would be in volation. But then I must ask: what if the internal oscillator (10MHz) were in use in a similar fashion? Since this can run a bit faster than 10MHz, would it violate this spec given the same prescalar values? If not, how high could the 10MHz oscillator go?
Sorry to expand the original question set. I should have perhaps included it in the original posting.
Again, thanks to you and those working with you for your help/support. Thanks also to David who forwarded your guidance on setting the GPxQSEL to asynchronous for the SPI pins. This is in fact improperly set in my present design.
Sincerely,
Bob W
Bob,
As long as the minimum pulse duration (T13/T14) are met, then ideally there shouldn't be a problem with the asymmetric clock.
Regarding the clock rate, yes, 10MHz is the absolute maximum clock rate for SPI slave TX and RX.
If an external clock is driving the DSP at 10MHz, and the PLL is scaling this up to 80MHz, 10MHz SPI Slave operation requires that the LSPCLK to SPI is at least 40MHz (SYSCLK by 2). These timings are all specified with a bit of margin; i.e.: if the incoming SPICLK is 10.1 MHz, the SPI should still be able to operate provided all timings are met.
Please see section 5.3 Device Clock Tables of SPRS698 for Table 5-3 for the Internal Zero-Pin Oscillator characteristics on the F2806x family devices.
Please let me know if I have misunderstood any of your questions or you need more clarification.
-Mark
Mark,
I believe you have answered all my questions.
Thanks for your time and effort. My apologies for this overdue/late response.
Sincerely,
Bob