USCI I2C Sending multiple bytes without ISR

Paolo Meriggi said:

Hence I'd kindly ask if the following code (meant for the USCI B2) might be correct or not.

THe sequence to send a byte is

set UCTXSTT
write first byte to send to TXBUF
wait for UCTXSTT to clear. If it clears, the start byte has been sent and the slave response (ACK/NACK) has been recorded
check for NACKIFG. If set, the slave didn't answer and the byte in TXBUF has been discarded. To free the bus, set UCTXSTP.
If not, then wait for UCTXIFG being set. At this point, the byte has started sending. And TXBUF is ready to take the second byte. If there is no second byte, set UCTXSTP. THis should clear UCTXIFG.
Wait for UCTXSTP being clear again before starting the next transfer.

Alternatively, you may clear UCTR and set UCTXSTT once more, to start receiving. No need to set UCTXSTP in between (repeated start).
Note that when receiving, you need to set UCTXSTP before the currently read byte is fully received, or you'll get another byte. Form the second byte on, you can do it once RXIFG is set. If you only want one byte, you'll have to check for UCTXSTT being clear, then imemdiately set UCTXSTP and the USCI will continue receiving teh first byte, then stop.

Many Thanks Jens-Michael. Just another question: if you suggest to use UCTR, this means that I dont' have to bother with the I2C Slave Address as a "normal byte" to transfer, but rather should I load the slave address to the UCB2I2CSA just once ?

Summing up, is the following a correct way to send a couple of bytes synchronously via USCI I2C (B2) ?

//===========================================================================
void I2C_WriteRegisterSync (UCHAR RegAddr, UCHAR Arg)
//===========================================================================
{
    //prevent IRQ to be fired
    UCB2IE = 0;
 
    //set UCTXSTT
    UCB2CTL1 |= UCTR + UCTXSTT;    // I2C transmitter mode (TX), send START condition

    //wait for UCTXSTT to clear.
    while(UCB2CTL1 & UCTXSTT);

    //If UCTXSTT clears, the start byte has been sent and the slave response (ACK/NACK) has
    // been recorded
    //check for NACKIFG. If set, the slave didn't answer and the byte in TXBUF has been discarded.
    //To free the bus, set UCTXSTP.    
   
   if( UCB2IFG & UCNACKIFG )
    {
        UCB2CTL1 |= UCTXSTP;    
        return;
    }

    //write first byte to send to TXBUF
    UCB2TXBUF = RegAddr;    

    //wait for UCTXIFG being set.
    while (!(UCB2IFG & UCTXIFG));    
    
    //check for NACKIFG. If set, the slave didn't answer and the byte in TXBUF has been discarded.
    // To free the bus, set UCTXSTP.    
    if( UCB2IFG & UCNACKIFG )
    {
        UCB2CTL1 |= UCTXSTP;    
        return;
    }
    
    //At this point, the byte has started sending. And TXBUF is ready to take the second byte.
    // Load TX buffer with Arg. this should clear UCTXIFG
    UCB2TXBUF = Arg;    

    //wait for UCTXIFG being set.
    while (!(UCB2IFG & UCTXIFG));    

    //either way, issue I2C stop condition
    UCB2CTL1 |= UCTXSTP;    // I2C stop condition
    
    while (UCB2CTL1 & UCTXSTP);    // Ensure stop condition got sent
}

Paolo Meriggi said:

Summing up, is the following a correct way to send a couple of bytes synchronously via USCI I2C (B2) ?

WQhen you set UCTR and UCTXSTT, the USCi will immediately set UCTXIFG to signal that it needs a data byte to be sent. Unless you write soemthing to TXBUF, the USCI will wait with the ACK cycle and not complete the start byte (and therefore not clear UCTXSTT).
If you write to TXBUF, UCTXSTT will eventually clear, and the USCI will immediately stat sending the byte (and set UCTXIFG once more to request the next byte for semaless transmission) or, if the slave didn't respond, the byte written to TXBUF will be discarded and UCNACKIFG is set.

So "write first byte to send to TXBUF" must be move before "wait fo UCTXSTT to clear".

Well well, hoping not to be too boring, are these two routines corrected ?

//===========================================================================
void I2C_WriteRegisterSync (UCHAR RegAddr, UCHAR Arg)
//===========================================================================
{
  UCB2IE = 0;                              //prevent IRQ to be fired
  UCB2CTL1 |= UCTR + UCTXSTT;      // I2C transmitter mode (TX), send START condition
  UCB2TXBUF = RegAddr;             //write first byte to send to TXBUF

  while(UCB2CTL1 & UCTXSTT);       //wait for UCTXSTT to clear.

  if( UCB2CTL1 & UCNACKIFG )         // check for NACKIFG.
  {
    UCB2CTL1 |= UCTXSTP;    
    return;
  }

  UCB2TXBUF = Arg;                        //write the second byte (argument)
  while (!(UCB2IFG & UCTXIFG));  //wait for UCTXIFG to set.
  UCB2CTL1 |= UCTXSTP;                 // I2C stop condition
  while (UCB2CTL1 & UCTXSTP);    // Ensure stop condition got sent
}


//===========================================================================
UCHAR I2C_ReadRegisterSync (UCHAR RegAddr)
//===========================================================================
{
  unsigned char ret = 0 ;
 
  UCB2IE = 0;                                        //prevent IRQ to be fired
  UCB2CTL1 |= UCTR + UCTXSTT;   // I2C transmitter mode (TX), send START condition
  UCB2TXBUF = RegAddr;              //write first byte to send to TXBUF
  while(UCB2CTL1 & UCTXSTT);        //wait for UCTXSTT to clear.
  if( UCB2CTL1 & UCNACKIFG )        // check for NACKIFG
  {
    UCB2CTL1 |= UCTXSTP;    
    return 0;
  }
  // I2C receiver mode (RX), send repeated START condition
  UCB2CTL1 &= ~UCTR;
  UCB2CTL1 |= UCTXSTT;    
  while (!(UCB2IFG & UCRXIFG));      //wait for UCRXIFG being set.
    ret = UCB2RXBUF;                            //read the actual data received
  UCB2CTL1 |= UCTXSTP;    // I2C stop condition
  while (UCB2CTL1 & UCTXSTP);    // Ensure stop condition got sent
  return ret;
}

Your read function assumes that the slave, once it has responded to the register address write, will also respond to the following repeated start. Well, this is usually the case, but a few slaves out there probably won't (because they are not ready yet to provide data).
It would be safer to also check NACKIFG after the repeated satart and maybe try again until the slave gives its ACK. But normally, this shouldn't be an issue.

There is a racing condition during receive. When you get the RX interrupt, the USCi has already started receiving the next byte. Also, once you read RXBUF, the next byte may already be received and will be written to RXBUF and receiving of the third byte has begun. THis could happen when your code is interrupted by an interrupt, so teh I2C transfer continues while your polling code doesn't.
Since you don't read RXBUF from these excess bytes, the system may stall and the stop never gets send. This is a possible deadlock condition.

You can limit this by setting UCTXSTP immediately after UCTXSTT is clear (maybe plus a small delay). And you can prevent any ISR interrupting by blocking interrupts around this point. So you can be sure that you initiate the stop while the first byte is still being received.