MSP430F5438 as I2C Master Receiver can't send NACK to I2C Slave

Samuele Forconi

Other Parts Discussed in Thread: MSP430F5438, MSP430F5510

Hi,

I'm using an MSP430F5438 connected with I2C to a Maxim DS2482-800, where the MSP430 is the I2C Master device and the DS2482-800 is the I2C Slave device.

The communication protocol needs that the I2C Master (MSP430) issues the following sequence of I2C operations:

[M - S] Start Tx
[M - S] Address
[S - M] Ack
[M - S] 1WRB
[S - M] Ack

[M - S] Repeated Start Rx
[M - S] Address
[S - M] Ack
[S - M] byte
[M - S] Ack
[S - M] byte
[M - S] Nack

[M - S] Repeated Start Tx
[M - S] Address
[S - M] Ack
[M - S] SRP
[S - M] Ack
[M - S] E1h
[S - M] Ack

[M - S] Repeated Start Rx
[M - S] Address
[S - M] Ack
[S - M] byte
[M - S] Nack
[M - S] Stop

My problem appears when the MSP430 (Master Receiver) needs to send the NACK (bold yellow line).

The function I'm using is the following:

unsigned char I2C_read(int mode)
{
unsigned char b;
  if(mode == I2C_READ_AND_NAK)
  {
      UCB0CTL1 |= UCTXNACK; // I2C nak
      while(!(UCB0IFG & UCRXIFG)); // Wait for RX data
      b = UCB0RXBUF;
      while(UCB0CTL1 & UCTXNACK);
  }
  else if (mode == I2C_READ_AND_STOP)
  {
      UCB0CTL1 |= UCTXSTP; // I2C stop condition
      while(!(UCB0IFG & UCRXIFG)); // Wait for RX data
      b = UCB0RXBUF;
  }
  else
  {
      while(!(UCB0IFG & UCRXIFG)); // Wait for RX data
      b = UCB0RXBUF;
  }
  return b;
}

My code hangs on the green line and never goes out, and I'm not understanding why the MSP430 (I2C Master Receiver) can't send out the NAK.

Thanks for any help and suggestions.

Regards,

Samuele.

over 12 years ago

0 Johnny Roberts over 12 years ago

Intellectual 350 points

The UCTXNACK bit is automatically cleared after the NACK is generated. I'm guessing that the NACK was already generated on the bus and the bit cleared before your program reached the highlighted portion of code, which would explain the hangup.

0 Chester Gillon over 12 years ago in reply to Johnny Roberts

Guru 92251 points

jdr said:
I'm guessing that the NACK was already generated on the bus and the bit cleared before your program reached the highlighted portion of code, which would explain the hangup.

I thought the highlighted line waited until the UCTXNACK bit was clear. So if the bit was already clear, why would that cause the highlighted line to hang up?

(I can't see any problem in the code listed)

0 Johnny Roberts over 12 years ago in reply to Chester Gillon

Intellectual 350 points

you're right, it shouldn't. I guess the NACK is never getting out onto the bus. Just curious, why do you read and NACK? Generating a stop after you're done reading will end the transaction.

0 Chester Gillon over 12 years ago in reply to Johnny Roberts

Guru 92251 points

jdr said:
Just curious, why do you read and NACK?

The DS2482-800 datasheet explains why:

Not Acknowledged by Master: At some time when receiving data, the master must signal an end of data to the slave device. To achieve this, the master does not acknowledge the last byte that it has received from the slave. In response, the slave releases SDA, allowing the master to generate the STOP condition.

0 Deepak Bansal over 12 years ago in reply to Chester Gillon

Expert 2395 points

Gillon,

I haven't check your code.

But in MSP, in I2C master receiver mode (check page 537 of SLAU144F)

Setting the UCTXSTP bit will generate a STOP condition. After setting
UCTXSTP, aNACKfollowed by a STOPcondition is generated after reception
of the data from the slave, or immediately if the USCI module is currently
waiting for UCBxRXBUF to be read.

0 Samuele Forconi over 12 years ago in reply to Deepak Bansal

Intellectual 350 points

I know that setting the UCTXSTP will cause the master to generate a stop condition, and it seems to work.

But on page 20 of the DS2482-800 datasheet there is the precise sequence of I2C bus communication to perform the Read Byte operation. The sequence is like the one I have written above, it requires that the Master sends a NACK and then issues a Repeated Start in TX mode. If I'll send the Stop condition instead of the Nack it will not be consistent to the datasheet and it may not work.

0 Jens-Michael Gross over 12 years ago in reply to Chester Gillon

Guru 227245 points

Chester Gillon said:
The DS2482-800 datasheet explains why:
Not Acknowledged by Master: At some time when receiving data, the master must signal an end of data to the slave device. To achieve this, the master does not acknowledge the last byte that it has received from the slave. In response, the slave releases SDA, allowing the master to generate the STOP condition.
[/quote]
This makes no sense. A stop condition is a low-to-high transition while clock is high. So to generate a stop condition, the master requires SDA to be low on the previous clock low cycle. Which would be an ACK sent by the master. Then during clock high, the master can release SDA which causes a stop condition. If the master sends a NACK, SDA is high and the master could only generate a repeated start during the next clock-high cycle.

In master send mode, the master of course has no control over the ACK of the slave, so in order to send a stop condition, it just starts another byte, with the first bit a '0' bit, then gnerates a stop after this first bit, which cancels the byte transfer and frees the bus.

However, looking at the flow diagram in the users guide, the master software just needs to set UCTXSTP before a byte has received (due to the double-buffering, it won't wait until the byte is read to proceed reading the next byte), and the master will do a nack, produce another clock cycle that sends a '0' bit while the slave is hopefully not sending anyting anymore, then does the stop condition by releasing SDA. Or the diagram is wrong here and does not really send a NACK, which would make much more sense (see above). I never looked at it with a protocol analyzer.

No need to manually set UCTXNACK. Just set UCTXSTP and wait for it to clear.

0 Chester Gillon over 12 years ago in reply to Jens-Michael Gross

Guru 92251 points

Jens-Michael Gross said:
This makes no sense.

I admit that when I quoted that text from the DS2482-800 datasheet I hadn't actually performed any I2C programming which involves sending a NACK so can't verify if the DS2482-800 datasheet makes sense or not.

However, have got a WII-NUNCHUK to try and use. From the datasheet ZX-NUNCHUK the Data read command requires the master to send a NACK prior to the STOP:

Will attempt to investigate if sending a NACK is really required to perform the read from a MSP430F5510, and look at the data with a LSA.

0 Samuele Forconi over 12 years ago in reply to Jens-Michael Gross

Intellectual 350 points

It worked. I've just set the UCTXSTP and then perform a Start in TX mode, no need to set the UCTXNACK manually.

Thanks for your help.

0 Jens-Michael Gross over 12 years ago in reply to Samuele Forconi

Guru 227245 points

Samuele Forconi said:
I've just set the UCTXSTP and then perform a Start in TX mode, no need to set the UCTXNACK manually.

Alternatively, you may set the UCTX bit and then just set UCSTT for a repeated start. This doe snto require an additional clock cycle to bring SDA down after a NCK for a stop condition, and also spares the stop condition itself. The I2C standard defines that a start condition is an implicit stop for the previous transfer.
In a multi-master environment, this prohibits a different master to take over the bus (or start another arbitration) after the stop: the previously active master still owns the bus for the next transfer when it does a repeated start.

0 Sunglin Chen over 9 years ago in reply to Samuele Forconi

Expert 2335 points

Hi Samuele,

Would mind to explain it more clearly or step by step ? I have the same problem like this, but I don't know how to send out a NACK signal. Thank you.

Sunglin.

0 Jens-Michael Gross over 9 years ago in reply to Sunglin Chen

Guru 227245 points

Unfortunately, the USCI I2C makes it difficult to just receive one single byte (or rather: to receive an exact number of n bytes and not n+1).
To achieve maximum throughput, it does not wait when a byte has been received but proceeds with the next byte (well, at least with the first 7 bits, until the previous byte was read).

To receive exactly one byte, polling has to be used (which is of course a very inefficient way of reading I2C data).
After the repeated start, the code needs to wait until the UCTXSTT bit clears. This means the address byte has been sent and an ACK was received. Now receiving of the first byte starts. At this point (well, add a small delay of 1 I2C clock cycle, just to be sure), the code needs to set UCTXNACK. When the first byte was received, a NACK is sent instead of the normal ACK.

For receiving exactly 2 bytes (n bytes), the approach is similar. When you get the interrupt for the forelast byte, don't read the byte. Instead wait until UCSCLLOW is set and stays set. This means, that the first 7 bits of the last byte have already been received and the USCI has stalled. At this point, set UCTXNACK. then read RXBUF for the forelast byte, which lets the USCI continue with the last bit of the last byte, and the NACK.

The eUSCI of newer MSPs has a counter to set the exact number of bytes to be transfered. However, it can only be modified during UCSWRST=1 and therefore won't work well with a repeated start. It can also trigger an interrupt when BIT#2 of byte#n was received, so the ISR can set UCTXNACK manually.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5438 as I2C Master Receiver can't send NACK to I2C Slave