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.
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.
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.
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?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 can't see any problem in the code listed)
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.
The DS2482-800 datasheet explains why:jdr said:Just curious, why do you read and NACK?
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.
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.
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.
Chester Gillon said:The DS2482-800 datasheet explains why:[/quote]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.
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.
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.Jens-Michael Gross said:This makes no sense.
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.
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.
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.Samuele Forconi said:I've just set the UCTXSTP and then perform a Start in TX mode, no need to set the UCTXNACK manually.
**Attention** This is a public forum