• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 81 subscribers
  • Views 1053 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.

SPI Slave mode is right-rotating its output.

Francis Israel
Prodigy 70 points

So, I've been toying with an MSP-EXP4305529 board, and was trying to get the SPI to work.

I have taken the MSPware SPI slave example and modified it so that: 

  1. It used the SPI pins available on the board.
  2. Its response was the received byte + 1

I've found that, looking through the debugger and looking at the sent/received data from an SPI unit, that I could either have the master understand the board, the board understand the master, but not both. If one got valid input, the other was getting nonsense. Turns out, the slave end was shifting/rotating its output by arbitrary amounts, where the previous input would bump into the next input; any extra would then bump into

I found the last post in this thread, where we emulate the effects of a chip select pin:

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/19004.aspx

And this has mostly resolved the issue, with one exception: The least significant bit of the previous outgoing slave message is now the most significant bit of the following slave message. The LSB of the later message is then bumped into the MSB of the message after it, and so on.

Pastebin of the main.c contents:

http://pastebin.com/KpT6kNbt

Polarity/phase mismatches can be ruled out as the cause, because the bytes are obviously coming from the master to the slave properly when viewed in debug. It's just that the incremented response is coming back with the bits right-rotated. Fault with the master can be reasonably eliminated, because it has successfully communicated to a PIC32 and a Cortex M3 before this. So, what's going on?

Thanks for any help

Francis

  • 0
    Guru 227245 points

    Francis Israel said:
    Polarity/phase mismatches can be ruled out as the cause, because the bytes are obviously coming from the master to the slave properly when viewed in debug.

    That's no proof. The debugger may show correctly what the slave doesn't understand due to wrong phase/polarity settings.
    Phase and polarity need to match both, master and slave. Also, TI has the polarity (or was it the phase) defined inverted to Motorola, so the SPI mode numbers do not match.

    Just try with all four combinations. It's faster than writing here. :)

    However, if phase and polarity are correct, there still might be line capacitance that causes a phase shift on higher frequencies. Or a too-low supply/core voltage that limits the SPI hardware internal operation speed (see datasheet).

  • 0 in reply to Jens-Michael Gross
    Prodigy 70 points

    Jens-Michael Gross said:

    The debugger may show correctly what the slave doesn't understand due to wrong phase/polarity settings.

    I'm not sure I follow what you're saying here; I'm using the debugger (ezFET/eZUSB or something like that with Code Composer Studio and some breakpoints) to look directly at the memory location that the slave is storing the data it gets from SPI_receiveData(). Could the debugging tools be lying to me, then?

    Jens-Michael Gross said:

    Just try with all four combinations. It's faster than writing here. :)

    Already did so; I make it a point to exhaust all of my options before I turn to support forums (this is not a jab at you, you are being helpful/responsive, so thanks). The described state in the first post is the closest I can get to 'working.'  I even toggled the bit order, and tried 125, 1000, and 8000 kHz.

    The slave MSP seems to be keeping one bit in the buffer, too; it's not that it's sending the last bit while the master is just ignoring it; it saves it to send in the next frame (even if it's seconds away). While it's somehow managing to see the full bits 7 down to 0 of the master's message, it's sending bits 8 down to 1 (where 8 is the LSB of the last message), if that makes sense. Wouldn't that, combined with the fact that it is reading in successfully, rule out capacitance issues? It would seem to me that if there were line capacitance issues, there would be shifting with truncation, as opposed to spilling into the next message.

  • 0 in reply to Francis Israel
    Guru 92251 points

    Francis Israel said:
    Could the debugging tools be lying to me, then?

    Probably not, but stepping in the debugger can change the timing / halt some peripheral clocks while stopped.

  • 0 in reply to Francis Israel
    Guru 227245 points

    Francis Israel said:
    I'm not sure I follow what you're saying here; I'm using the debugger (ezFET/eZUSB or something like that with Code Composer Studio

    Sorry, I thought you were talking about an I2C debugger/Analyzer that listens to the signal on the line.

    Francis Israel said:
    I make it a point to exhaust all of my options before I turn to support forums

    Me too, but there are lots of people around here who ask first and think later. Well, their usual post is 'I have to do this or that, please give code for it' ;( And then there are those somewhere in the middle.

    However, if it is not the configuration of the PSI, then it might be the initialization sequence.

    SPI has no implicite byte syncing. SPI si a bitstream without any eypressed byte boundaries. Once the slave is ready, it starts responding to the clock signal. The CS signal is usually used to tell the slave to discard everyhting before and start with a fresh byte (for the MSP slave, this means setting UCSWRST when CS is high and clearing it as soon as CS goes low). If this is not properly done, then the port init of the master can be interpreted by the slave as clock pulses, putting the slave out of sync with the master. The STE signal input is of no help with this - it won't reset the current count state, it will just put SOMI inactive and latch the current clock input state. If the clock is latched at the wrong moment, this may even cause a wrong 'half-bit' received when STE is released.

    Proper software implementation of CS handling is vital for proper SPI communication. STE input can help to minimize latency, but the sychronization on CS has to be done by software.

  • 0
    TI__Guru 56650 points

    Hi,

    i think i had the same problem as yours. I tried to find out the reason, and the answer i got is quite simple:

    due to the limitation of USCI module, when using the MSP430 in slave made, with another MSP430 as the master, you should not use UCCKPH = 1.

    Hope this helps.

  • 0
    Prodigy 70 points

    Okay, I've come across something odd. After fiddling around with a number of other things, I finally went to hook it up to the logic analyzer to see what was going on.

    Something weird happened: The system worked when I have the logic analyzer plugged in, and only then. Removing the analyzer probes and resetting the board broke communication, while adding the probes back and resetting the board fixed it.

    So naturally, I start removing/adding probes until I find which one 'fixes' the setup: it's the USA1CLK pin that depends on the logic analyzer; the other pins didn't care about the analyzer's presense. This finding leads me to three questions:

    • Should I be putting a pull resistor on the clock port? Since the probes measure between ground and the signal, I would think that would indicate a need for a pull-down, rather than a pull-up. EDIT: It's a pull-up that makes it work.
    • If so, will I need to add them in myself, or is there a register/bit/something in the MSP430 which will set up an internal resistor or something to that effect?
    • I've not encountered this with other SPI systems. My guess is that it's an unfortunate combination of opendrain/what-have-you mismatching between the master and the MSP430. Is there a theory/guess/statement that makes more sense than that?
    Thanks for your responses so far, guys, I appreciate the time you've taken to read/respond.
    EDIT: Pullup (not pulldown) resistor works. Just tossed a 10K resistor from pin 4.0 to VCC, and it works now. Would still like to know if there are settings for internal pullups or the like.
  • 0 in reply to Francis Israel
    Guru 227245 points

    Francis Israel said:
    Should I be putting a pull resistor on the clock port?

    Normally not. In SPI mode, the lines should be driven both ways. Only I2C requires pullups as I2C is open-collector (well CMOS has no collector anymore, but still the name sticks).

    For some reason it doesn't work in your case. Besides a defective port pin that doesn't drive high properly, there is only one other explanation that comes in mind:
    your SPI master and SPI slave have different supply voltages and a different meaning about what is high.

    It seems that you're at the edge of the slave's high level detection for the clock signal. So the additional pullup slightly rises the voltage, pushing the signal 'over the edge'. In this case, the MOSI signal would be also critical. And the MISO signal is probably too high for the MSP (but clipped by the internal clamp diodes).
    Since the clamp diodes have a voltage drop of 0.2V, the pullup may rise the signal level to MSPs VCC +0.2V.
    It may also be, that the clock line has a high load that causes a voltage drop on the port pin, so the MSP output voltage is significantly below VCC. Then again, the pullup may push the signal over the edge. But this shouldn't happen - a clock line shouldn't be loaded so much that a significant voltage drop appears on the output drivers. A possible explanation could be an 'almost shortcut'  of the clock line to a different signal or even GND.

    Francis Israel said:
    Would still like to know if there are settings for internal pullups or the like.

    Since the port pin should be in active driving mode, the pullups are inactive.

  • 0 in reply to Jens-Michael Gross
    Prodigy 70 points

    Sounds reasonable to me. I'll go ahead and mark this as resolved, then.  Thanks for the help/explanations!

**Attention** This is a public forum