TMS320F2812 / SPI-IF / Clock-Polarity & Clock-Phase

I have come to almost the same conclusion as you on this
issue. Your post is over a year old.  Did you ever resolve
this issue and if so, how?

Hi Gary,

Can you point me to the version of the doc you are looking at?  I am looking at the F2812 SPI user's guide and everything appears to be fine.  Thanks,

Kris

Let's start with the SPI standard, which was defined by
Motorola around 20 years ago in App Note 991:
  - http://cache.freescale.com/files/microcontrollers/doc/app_note/AN991.pdf

There is a timing diagram on page 4 where the concepts CPOL
and CPHA are defined inductively, meaning you have to study
all four cases to understand the meaning of the signals. As
drawn:
  CPOL: Denotes the idle state of the SCK signal from master
        to slave: 0 for idle low and 1 for idle high.
  CPHA: Denotes the clock edge on which both MOSI and MISO
        values change states: 0 for trailing edge and 1 for
        leading edge.

Then the same timing diagram is in the TI F2812, SPI
Reference Guide (SPRU059E):
  - http://www.ti.com/lit/ug/spru059e/spru059e.pdf

on page 21.  I am equating Motorola's CPHA bit with TI's
Clock Phase. In that diagram, when Clock Phase = 0, the data
change on the clock's leading edge, and on trailing when 1.

This is not easy to see with the naked eye. I had to print
out both diagrams and draw lines though the data transition
points to be sure what I was seeing.

TI's definition of clock polarity is the same as Motorola's
while clock phase is the opposite. 

I am in the middle of writing a test for this using my own
hardware and planned to post the results on here when I get
done.

Gary,

I printed both of these out and drew the lines as you mentioned.  I see what you are saying about the opposites of the clock phase bits.  Motorola has CLOCK PHASE = 0 being delayed a half cycle and CLOCK PHASE = 1 with the clocking beginning on the same edge as the data is changed.

I will look into this as far as SPI standards.  If it is indeed opposite it will probably just be a note in the documentation indicating this for communicating with other SPI devices.  Thank you for bringing this up.  I will follow up with any additional information I uncover.

Without going into what the actual protocol is, from a simple term definition having phase = 0 aligns with the data makes more sense conceptually (meaning there is no phase).  However, I do understand the concern here.

Kris

I have completed my hands-on evaluation of my TMS320F2812's
handling of these SPI parameters, running the processor in
all 4 modes and can summarize it with this timing diagram:

       TI
       Clk
       P
       o
       l
 Moto  a P
  C C  r h
  P P  i a
  O H  t s Moto                                         TI
  L A  y e Signal                                       Signal
  - -  - - ------    _   _   _   _   _   _   _   _      ------------
  0 0  0 1 SCK  ____| |_| |_| |_| |_| |_| |_| |_| |___  SPICLK
                  :   :   :   :   :   :   :   :   :
                  :_  :_  :_  :_  :_  :_  :_  :_  :
  0 1  0 0 SCK  __| |_| |_| |_| |_| |_| |_| |_| |_____  SPICLK
                  :   :   :   :   :   :   :   :   :   
                __:_  :_  :_  :_  :_  :_  :_  :_  :_  
  1 0  1 1 SCK      |_| |_| |_| |_| |_| |_| |_| |_| |_  SPICLK
                  :   :   :   :   :   :   :   :   :   
                __:  _:  _:  _:  _:  _:  _:  _:  _:   
  1 1  1 0 SCK    |_| |_| |_| |_| |_| |_| |_| |_| |___  SPICLK
                  :   :   :   :   :   :   :   :   :   
                  ____:   :___:___:   :___:   :___:   
     MISO/MOSI  XX    |___|       |___|   |___|   XXXX  SPISOMI/SIMO
           __   _                                   __  _______
           SS    |_________________________________|    SPISTEA

I styled it after Motorola's example, but show a value of
0xB5 = 1011 0101b on the MISO/MOSI line.

- My dotted lines denote times when the bus driver changes
  its outputs (Master drives MOSI/slave drives MISO).
- It is not stated in the spec, but implied by the "internal
  strobe" lines, that the receiver samples the data on the
  opposite clock edge, and with a 50% duty clock data will
  be stable.
- Motorola's CPOL and TI's "Clock polarity" both denote the
  idle state of the clock: 0 for low and 1 for high.
- Motorola's CPHA denotes the edge where the driver changes
  its data line; 0 for trailing and 1 for leading.
- TI's "Clock phase" also denotes this edge, but is the
  exact opposite of Motorola's: 0 for leading, 1 for
  trailing.

So the F2812 does what the data sheet claims.

Like not a few other engineers, I have wished over the past
2 decades that Motorola had assigned a meaning to those
abbreviations that I could easily remember, and avoid a lot
of head scratching, repeated digging in data sheets, and
needless mistakes in my work (and maybe a few other folks'
as well).

But I am finding that the standards with the most enduring
lagacy have the least amount of forethought put into their
naming conventions (CAN comes to mind here).

Thanks for the follow up.  I'm pretty sure we are correct about the phase settings being opposite.  I'm going to spend some time double checking just to be sure, but I believe I'll be adding a note in the SPI User's Guides at least indicating it is opposite the standard to save everyone some trouble.

If you have any suggestions on how to make these two settings differentiated a bit more conceptually, please feel free to send those my way as well.

Kris

Hi Kris,

years later the TRMs still state "Compatibility Mode of the MibSPI makes it behave exactly like a standard platform SPI module" (e.g. SPNU 515b Sect. 28.1.2.2, my emphasis) letting customers searching the web or experimenting on their own to be sure whether "exactly" is wrong or the figures are wrong.

Besides, there is no "better" definition. It is clear that the larger phase (1 instead of 0) shall indicate a delay, but it is arbitrary whether it is the delay of the data with respect to the clock or the delay of the clock with respect to the data.

Rainald

Hi Rainald,

The behavior in the TRM correctly describes the operation of our SPI module. Since we have been documenting it to our customers for this way for so long we have decided to leave it as is currently documented. If there is anything we can help you with please let us know.

Thanks,

Kris