• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 787 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 polling issue

Pawel Piwowarski87949
Intellectual 805 points
Other Parts Discussed in Thread: MSP430F2274

I am using MSP430F2274 to communicate via SPI-B with another microcontroller. MSP430 is the master and I have a problem with polling the receive buffer flag - it seems it is not set when the data is available but immediately after the UCB0TXBUF is filled in with data. Anyway, I have the problem that the other controller gets all data correctly and the return slave MISO messages are read sometimes with 50%, and sometimes 10% accuracy.

The setup code is:

P3SEL |= 0x0E;  // P3.3,2, 3.1 USCI_B0 option select

// P3DIR |= 0x01; // P3.0 output direction

UCB0CTL0 = UCMSB + UCMST+ UCSYNC ;

UCB0CTL1 |= UCSSEL_2;

UCB0BR0 = 0x04*4;

UCB0BR1 = 0;

IE2 |= UCB0RXIE;

UCB0CTL1 &= ~UCSWRST;

The polling part is:

while (!(IFG2 & UCB0RXIFG)) ;

SPI_Slave->bmsg= UCB0RXBUF;

Is there anything I am missing or do wrong  in the setup or flags use ?

  • 0
    Guru 227245 points

    I tlooks liek some details of SPi have slippe doyur attention.

    To receive something on SPI, you'll need to send something. The master generates teh SPI clock. The clock is only active when the master sends something. One clock puls efor each bit the master sends. At the same time, the slave will send its data, one bit per clock pulse. So if you want to receive  abyte, you have to send a (dummy) byte.

    Also, to get an answer for something you sent, you'll ahve to send a dummy byte becaus while you're still sending the command, you obviously cannot receive the answer. This would require second sight on the slave side.

    so "it seems it is not set when data is available but immediately after UCTXBUF is filled" means: data available at the slave and written to slave TXBUF is sent when the master sends something and generates the clock pulses. So it is received by the master at the same time (well 1/2 clock cycle off)  the master has sent its own data.
    And "immediately" most likely means "8 SPI clock cycles later", which is only a few MCLK cycles when SPI is running on maximum speed. Depending on your MSP, the SPI hardware doesn't stop when the debugger hits a breakpoint, so if you single-step and do register view to check the flags, ages of hardware time pass between two single steps. And when you step past the write to TXBUF, the whole write (and at the same time read) transfer has already happened.

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

    Thanks Jens-Michel. You are right about the SPI workings but I think I took care of them just did not paste all the code. So immediately before the SPI read I issue:
    UCB0TXBUF = val;
    And I did not have this problem under single-step debugging, all the SPI characters I receive are put into an int[] table and I analyze them after the code runs for a while, so this is actually a runtime record.
    But shall I understand I am not missing any setup code and I am monitoring the right flag ? And is this flag automatically cleared when read ?

  • 0 in reply to Pawel Piwowarski85631
    Guru 227245 points

    Pawel Piwowarski85631 said:
    And I did not have this problem under single-step debugging

    Single stepping (or hitting a breakpoint, as signle steppign is just a moving breakpoint) doesn't stop the world turning. it jsut stops the CPU (and on some MSPs also some selected clocks). But the hardwar ewill continue working. So ages before you hit the 'next instruction' key, all pending transfers started by the last isntruction are already done.

    Don't trust your debugger if you don't know how it works.

    However, you should post the whole code as the excerpt obviously wasn't enough to find the problem.

**Attention** This is a public forum