MSP432E401Y: I2C-- How to send arbitrary I2C payloads?

Hi Charles,

I have proper pullups on SCL and SDA. I can't share what device I'm communicating with, but I can say that it has an initialization sequence that requires a single byte to be written to the I2C bus and NACK'ed.

I understand this is nonstandard behavior, but I was wondering how the I2C FSM works and how I could get it to send just a single byte.

• When the I2C peripheral receives a NACK, is the transmission halted? Do I need to do anything to "clear" that error flag?
• The docs you sent indicate I should use I2C_MASTER_CMD_SINGLE_SEND/RECEIVE or  I2C_MASTER_CMD_BURST_SEND/RECEIVE_START to get the address and direction bit written to the bus. What should I do afterwards to "reset" the FSM to an idle state?

EDIT: Also, can the burst mode be used to achieve equivalent behavior to the single-byte commands?

Thanks!

Shranav Palakurthi said:

that requires a single byte to be written to the I2C bus and NACK'ed.

Shranav Palakurthi said:

• When the I2C peripheral receives a NACK, is the transmission halted? Do I need to do anything to "clear" that error flag?

Hi Shranav,

  I'm only very clear here. Are you saying you are expecting a NACK from the slave device and that is a real intended behavior? If that is the case, the FSM will get an error. If the master receives a NACK then it will STOP and abort the transfer. 

18.3.1.4 Acknowledge
All bus transactions have a required acknowledge clock cycle that is generated by the master. During
the acknowledge cycle, the transmitter (which can be the master or slave) releases the SDA line.
To acknowledge the transaction, the receiver must pull down SDA during the acknowledge clock
cycle. The data transmitted out by the receiver during the acknowledge cycle must comply with the
data validity requirements described in “Data Validity” on page 1280.
When a slave receiver does not acknowledge the slave address, SDA must be left High by the slave
so that the master can generate a STOP condition and abort the current transfer. If the master
device is acting as a receiver during a transfer, it is responsible for acknowledging each transfer
made by the slave. Because the master controls the number of bytes in the transfer, it signals the
end of data to the slave transmitter by not generating an acknowledge on the last data byte. The
slave transmitter must then release SDA to allow the master to generate the STOP or a repeated
START condition.
If the slave is required to provide a manual ACK or NACK, the I2C Slave ACK Control
(I2CSACKCTL) register allows the slave to NACK for invalid data or command or ACK for valid
data or command. When this operation is enabled, the MCU slave module I2C clock is pulled low
after the last data bit until this register is written with the indicated response.

Shranav Palakurthi said:

• The docs you sent indicate I should use I2C_MASTER_CMD_SINGLE_SEND/RECEIVE or  I2C_MASTER_CMD_BURST_SEND/RECEIVE_START to get the address and direction bit written to the bus. What should I do afterwards to "reset" the FSM to an idle state?

If data is NACKed during a BURST and the STOP bit is set
in the I2CMCS register, the transfer terminates. If the STOP bit is not set, the software application
must issue a repeated STOP or START when a NACK interrupt is asserted. In the case of a NACK,
the I2CMBCNT register can be used to determine the amount of data that was transferred prior to
the BURST termination. If the Address is NACKed during a transfer, then a STOP is issued.

Charles Tsai said:

Are you saying you are expecting a NACK from the slave device and that is a real intended behavior?

Yes, that is what I am expecting from the device. Sorry if that complicates things.

So based on what you've sent me, I would do the following:

I2CMasterSlaveAddrSet(..., deviceAddr, false);
while (I2CMasterBusBusy(...)) {}
I2CMasterDataPut(..., 0x00); // 0x00 will never be sent since we expect a NACK
I2CMasterControl(I2C_MASTER_CMD_SINGLE_SEND); // addr is sent and NACK'ed.

assert I2CMasterErr(...) == I2C_MASTER_ERR_ADDR_ACK;

And to send data afterwards I could just retry according to the example code in the DriverLib SDK?