• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 2321 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.

MSP430 I2C slave transmit

Raymond Dunn
Prodigy 190 points

I have a slave I2C setup using interrupts, and I see an extra interrupt that I can't account for.  I'm doing a simple master-RX / slave-TX of 4 data bytes, and the master and slave both seem to operate correctly, and a bus-decode shows the expected activity.  But the slave shows 5 TX interrupts, instead of the anticipated 4 - one for each data byte.  The data is correct, nothing is missing, the master receives the correct data, so it must be working correctly as far as the data transfer goes.  This is the first implementation of I2C on the MSP430 that I've done, so I want to be sure I'm not letting some bug get into my component code.

The following screen-captures illustrate the issue:

There are two TX interrupts close together, just after the START shown on STAT-change

Here is a closeup detail

The I2C Slave Transmitter Mode discussion says:

Then the address is acknowledged, the UCSTTIFG flag is cleared, and the data is transmitted. As soon as the data is transferred into the shift register the UCBxTXIFG is set again.

So it seems like this is normal operation, but I don't understand it fully.  Could someone enlighten me on this, please?

- Ray

  • 0
    Guru 227245 points

    The USCI signals with a TX interrupt that its TXBUF register is empty. It doesn't meant hat the previous byte has been sent. Or (in case of I2C) that the byte you write to TXBUF after the interrupt wille ver be sent (TXIFG is set as soon as you set UCTXSTT, but if the slave doesn't respond, the byte is discarded adn UCNACKIFG is set instestead)

    Yes, the double-buffering might be a bit confusing at first. However, it allows for maximum throughput, as you can prepare and write the next byte while the previous one is still being sent.

    Your diagram shows that you apparently set the TXIE bit after you detected a successful start condition. So the first TX interrupt comes after the address. And the second immediately after, when the first byte has been moved from TXBUF to the shft register.

    When the 5th TX interrupt comes, you know that the 4th byte is just being sent and you can set the UCTXSTP bit to follow the last byte with a stop condition, then clear the TXIE bit, as you don't want to send more bytes and don#t want more TX interrupt to come until you start the next transfer.
    Teh USCI itself doesn't know how many bytes you want to send, so unless you say 'stop' (or the slave sends NACK), it will keep giving you TX interrupts.

    I'd say: congratulations! Your I2C master transmit code seems to work as it should.

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

    Thanks Jens-Michael,

    I had a thought last night that it might be the 5th TXBUF interrupt that was the trouble-maker, but since the master terminates the bus-cycle, that last data gets thrown away.  I have code in my component that prevents the attempt to overrun the (software) data buffer, so it isn't a problem.

    I added a bit of debug code to test the theory of what data gets written to TXBUF and when.  You can clearly see the double-buffer action that you spoke of in the following screen shot.  The first data 0x57 gets loaded after the SLA+R, then about 30us later, the second data 0x58 is loaded while the first data is beginning to transmit.

    the bus data is shown on I2C, and the data written to TXBUF (by the interrupt) is on TXBUF.  It is clear that the TX interupt is one char ahead of what is happening on the bus.  It is also clear that when the bus gets to the last byte to transmit, I trap the attempted (software) buffer overrun and display 0xFF instead to illustrate the attempted error.  This error display data doesn't actually get loaded into the I2C TXBUF, it is only used here to verify what the last interrupt is doing.

    Thanks for all your help on the I2C subsystem, it works a little differently than the subsystems I've used in the past.

    - Ray

**Attention** This is a public forum