• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 896 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Knowing when SPI transaction complete on F2812

Gary Lynch
Expert 1310 points
Other Parts Discussed in Thread: TMS320F2812

I am using the SPI port on a TMS320F2812 in a single-master,
multiple slave configuration, and thus must select my
devices with GPIO pins. Devices are serviced asynchronously,
so it is important to know that the prior SPI transaction
has finished before starting a new one. As far as I can
tell, there is no bit in any status register dedicated to
this condition.

I have had this problem on other processors and got around
it by polling the SPI interrupt bit (SPIST.6 = SPI INT
FLAG).  This is giving me trouble as the hardware apparently
sets the bit on the leading edge of the last bit, or half a
bit time before the transaction is complete, causing me to
pull chip select high too soon (sending 0xAA):

  SCK  ___|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|___


  MOSI ___|¯¯¯|___|¯¯¯|___|¯¯¯|___|¯¯¯|_____
            1   0   1   0   1   0   1   0  
  __   __                              _____
  CS     |____________________________|

I got it to work by inserting a 'twiddle-thumbs' loop to
waste 1 bit time after SPI INT FLAG goes true before raising
CS-L, but I don't like kludges.

The SPI reference guide shows the SPISTEA output of the
F2812 staying low all the way to the last clock edge when
operating as a master, and I have confirmed this with my
scope. It occurs to me I could route this signal back in
through an unused GPIO pin and poll it, but again, this
seems like a lot of effort to achieve basic functionality.

Am I missing something obvious?

  • 0
    TI__Genius 15260 points

    Unfortunately, you are correct.  We do not have a status bit to determine when the full transaction is complete.  I'm not very familiar with the F2812, but I believe you should just be able to enable the STE output and poll the pin data register to see the state (i.e. you shouldn't have to route this back to an input to do this).  At least this is true for more recent devices.  

    Another option if you don't want to waste the CPU cycles polling the pin is to connect STE to an external interrupt if the F2812 supports this.

    Kris

  • 0 in reply to Kris Parrent
    Expert 1310 points

    Thanks for all the options I hadn't thought of. I'm now
    trying to read the state of SPISTE (which is on GPIOF3) from
    its data register. I initialize the port as follows:
      Mux register:       1
      Direction register: 1
      Data register:      0 (shouldn't matter)

    I then try to read GpioDataRegs.GPFDAT.bit.GPIOF3 and use
    the '1' state as my cue that SPISTE has gone back high.

    That particular snippet looks like this:
         /* + + + + + + + + + + + + + + */
         /* Wait until SPISTE goes high */
         /* + + + + + + + + + + + + + + */
      while(GpioDataRegs.GPFDAT.bit.GPIOF3 == 0)
        ;

    But when I run it, execution hangs at the while statement. I
    captured the actual output on the SPISTE pin:

    and see it going high after every transaction, but when I
    look at GPIO port F:

    bit 3 is zero.

    I didn't re-read the entire SPI reference guide, but the
    string "SPISTE" occurs in SPRU059 25 times, and none of
    those paragraphs makes any reference to being able to use
    SPISTE as an interrupt source.

    Is this what you meant me to try?

  • 0 in reply to Gary Lynch
    TI__Genius 15260 points

    Gary,

    Let me investigate if you can read the state of the IO on the F2812 while it is a peripheral pin.  This works for all devices I'm aware of, but the IO structure may have changed between this and the following devices.

    Not quite what I was going for with the STE.  Again, not sure if the F2812 supports this, but my suggestion for more recent devices is to externally connect the SPI STE to a pin configured to generate a XINT (external interrupt) on a rising edge.  This way you don't throw away any MIPS just waiting for the STE pin to go high.

    Let me speak with some members on my team regarding these questions.  I'll get back to you when I find out.

    Kris