• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 1076 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 STE pin issue

David Engineer
Intellectual 340 points
Other Parts Discussed in Thread: MSP430F5638

Everyone,

I am using a MSP430F5638 to communicate with a ADXL345 accelerometer through 4-pin SPI. I have been unable to get a signal from any of the 4 pins using an oscilloscope. I have used the following settings to initialize the SPI:

UCB1CTL1 = UCSWRST + UCSSEL_2; 
UCB1CTL0 = UCCKPH + UCCKPL + UCMST + UCMODE_2;
UCB1CTL1 &= ~UCSWRST; //Enable USCI
UCB1BR0 = 3; 
UCB1BR1 = 0;
UCB1IE |= UCRXIE;

After initialization, I have a while loop with the following code (interrupt is included).

while(1)
{
if(i > 2)
{
while (!(UCB1IFG&UCTXIFG)); // USCI_A0 TX buffer ready
UCB1TXBUF = 0x36;
i++;
}
}

#pragma vector=USCI_B1_VECTOR
__interrupt void USCI_B1_ISR(void)
{
temp = UCB1RXBUF;   
P6DIR |= BIT1;
P6SEL &= ~BIT1;
P6OUT &= ~BIT1;
}

I have googled about SPI/STE issues, looked over this forum, reviewed sample code and read the family and chip-specific datasheets multiple times to try and figure out what I am doing wrong. My question is 1) what am I doing wrong in my code? 2) Do I need to set the STE in my code before Tx/Rx or does setting the UCMODE_2 make the software handle that automatically (Page 777 and 778 in the family manual are a bit ambiguous on how to set STE)?

  • 0
    Intellectual 340 points

    I found out what I was doing wrong, two things:

    1) In my code "if(i>2)" should be changed to "if(i<2)" to allow the transmission to take place.

    2) I did not understand what the STE function was for until I made sense out of the diagram in the manual. I thought STE was some sort of automatic chip select handled by the peripheral, when it is actually meant for selecting the MSP when it is a slave. I therefore changed the setup to UCMODE_0 and the STE pin back to a low driven I/O.

    I now have signals coming from my MSP and I must now figure out how to communicate with my accelerometer.

  • 0 in reply to David Engineer
    Guru 227245 points

    David Engineer said:
    I thought STE was some sort of automatic chip select handled by the peripheral, when it is actually meant for selecting the MSP when it is a slave.

    This, and also for immediately silencing the slave output (bus disconnection). It does not, however, control any low- or high-level protocol featuers (such as synchronizing to a byte border or resetting the whole high-level transfer). The reason is simple: the PSI hardware doe snot know of any high-level protocol and also does not know which of the possibly many devices ont eh SPI bus wou want to select in master mode. So teh CS handling is completely left to the software. For both, master and slave mode.

    You're not the first one falling into this '4-wire-mode' trap.

    David Engineer said:
    I now have signals coming from my MSP and I must now figure out how to communicate with my accelerometer.

    SPi is pretty simple. There are only two things to keep care of: first, to receive a byte you'll have to send a byte. Writing to the amsters TXBUF starts a sequence of 8 cloc kpulses which sends 8 bit and receives 8 bits. Since teh slave waits for clock pulses and there is no continuous clock signal on teh bus (which would request data even when none is wanted), there is no 'automatic receive' as in an UART connection. To get a byte, you'll have to send a byte, even if it is a dummy value. All high-level protocols are aware of this and there are eitehr 'dummy comamnds' defined or command bytes are ignored at certain positions of the high-level protocol.

    The other thing is the double-buffering of the USCI module. When you write to TXBUF, this starts a transfer, but TXBUF is immediately empty again, requesitong the next byte whiel the first is sitll being sent. The first byte received is available when the first byte is sent (so quite some time later), righ tbefore the second byte is moved from TXBUF to output and the third TX byte is requested.
    So when using interrupts, you'll have an interleave between bytes sent and bytes received.

**Attention** This is a public forum