• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 986 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.

Extra leading SPI bit

Eric Jonardi
Intellectual 305 points
Other Parts Discussed in Thread: MSP430G2231, TLC5947

I am using a MSP430G2231 to communicate with a TLC5947 LED driver (24 channel, 12-bit grayscale control). I am using the SPI register in 16-bit mode, and writing 0x0C to the count register (USICNT) to shift out the 12 bits. The issue I am running into is that the first set of bits that I shift out over SPI has an extra bit. There is an extra clock pulse with MOSI held high, even if MOSI was previously low. This only occurs on the first SPI transfer of the program, then SPI functions without error for the remainder of the program. (Below is my code in it's simplest form. Also, this problem occurs without fail, and is observed when the MSP430 is connect only to an oscilloscope)

The TLC5947 will ignore anything past the last 288 bits that it received (they are essentially shifted out the other side of the TLC5947's shift register), so I have been able to run a workaround by sending an extra byte over SPI prior to the body of my program loop, but I would very much like to figure this out as I have other projects in mind that are a little more sensitive to SPI traffic.

WDTCTL = WDTPW + WDTHOLD;
USICTL0 |= USIPE6 + USIPE5 + USIMST + USIOE;
USICTL1 |= USICKPH + USIIE;
USICKCTL = USIDIV_0 + USISSEL_2;
USICNT = USI16B;
USICTL0 &= ~USISWRST;

USISRL |= 0xFFFF;
USICNT = 0x0C;            // 13 bits are sent, firs bit is high regardless of USISRL

USISRL |= 0xFFFF;
USICNT = 0x0C;            // 12 bits sent, all correct

  • 0
    Guru 47900 points

    This is a pure "swag" - do like the clarity with which you've described your problem.

    As this only happens on the first SPI transfer - and that first transfer immediately follows the SPI set-up/initialization - could this be cured by inserting a delay between the set-up and first transfer? 

    Should my guess fail - observe/log all SPI related registers during both the "bad" and "good" transfers.  Anything different?  I would look especially at the registers after spi set-up (and prior to the errant, first transfer)

    Should nothing reveal - try the test in 8 bit mode and see if problem occurs there as well.  Again - study registers in the hope of discovery...

  • 0 in reply to cb1
    Intellectual 305 points

    I have also tested the code in a loop (shift out 24x12-bit sets for the TLC5947), and the problem still manifests itself with the overhead of the loop between the SPI initialization and the actual transfer.

    Also, I doubt this is a noise issue (or interference from the initialization settling out), as I have been looking at the signals with a 500MHz scope and the CLK/MOSI waveforms are as clean as a whistle. The only reason I noticed that there was an extra bit (and not just normal traffic) was that I went and manually counted the number of clock pulses while troubleshooting another issue.

    I will try your suggestions (including a longer delay) to see what pops up.

  • 0 in reply to Eric Jonardi
    TI__Intellectual 2225 points

    Eric,

       You might be experiencing the USI5 errata.  Please review the errata at the link below.

    SLAZ061B

  • 0 in reply to Brian P
    Intellectual 305 points

    Thanks Brian_P, that would explain exactly what I am experiencing.

    For my application I think I will need to keep the extra byte at beginning of my program, as the loop is too slow already and I don't want to introduce the extra overhead of checking if it is the first transmission during each iteration of the loop (as suggested in the workaround). Regardless, this is good to know (plus, now I know to always check the errata).

  • 0 in reply to Eric Jonardi
    Guru 227245 points

    The problem is the clock polarity. The shift register seems to recognize the clock signal shift due to the clock polarity as a clock impulse.

    I'm not sure whether this applies only after the transmission started of right after releasing SWRST.

    In the second case, it would help to select the slave (setting the slave's CS low) after the state machine has been released. In the first case, well, making a dummy 1-bit transfer after clearing SWRST, with the slave still unselected, would get rid of this anomaly too.

**Attention** This is a public forum