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.

MSP430FR5994: I2C Problem with ADS112C04

Part Number: MSP430FR5994
Other Parts Discussed in Thread: ADS112C04

Hello,

I am trying to read data from a ADS112C04. Therefore I have written functions that basically work like corresponding functions from eusci_b_i2c library but with repeated start conditions. The initialisation of the ADC works fine and I can write all the registers, the IDAC current will be switched on and the PGA also works. I am also receiving the first measurement correctly. But when sending the RDATA command for the second measurement the code gets stuck.

The measurement is triggered by TimerB four times per second and this is the complete sequence:

TimerB Interrupt -> Send START_SYNC Command (function ADS112C04_Measure) -> DRDY falling edge IRQ -> Send RDATA and switch to receive (see function ADS112C04_receive) -> I2C RX IRQ -> process measurement data

This cycle works one time in the beginning and gets stuck the second time (see source):

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
bool ADS112C04_init(void)//(uint8_t eUSCI_MODULE)
{
uint8_t i;
const uint16_t delay = 80;
const uint8_t regSend[8] = {CMD_WREG0, REG0, CMD_WREG1, REG1, CMD_WREG2, REG2, CMD_WREG3, REG3};
// I2C_ Init
EUSCI_B_I2C_initMasterParam i2c_master_init = {
EUSCI_B_I2C_CLOCKSOURCE_SMCLK,
CS_getSMCLK(),
EUSCI_B_I2C_SET_DATA_RATE_100KBPS,
0,
EUSCI_B_I2C_NO_AUTO_STOP
};
ADS112C04_powerOn();
EUSCI_B_I2C_initMaster(AFE_USCI_BASE, &i2c_master_init);
EUSCI_B_I2C_clearInterrupt(AFE_USCI_BASE, UCRXIE); // neu
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • From your description I suspect you're issuing a (new) Start while a Stop-request is pending, which causes trouble with the I2C unit. You're waking up main() while the (n+1)th byte is being received, so the UCTXSTP latency could be up to (9+1)/100k=100usec.

    I suggest you add something like this to the beginning of your _receive():

    >     while(HWREG16(AFE_USCI_BASE + OFS_UCBxCTLW0) & UCTXSTP); // make sure previous operation is complete.

  • Thank you for your fast answer. I added your suggested polling for stop with no success. The stop bit is already cleared when it comes to that point. Also I am already sending the stop condition before receiving the last byte (see line 138) as it is recommended in SLAU208.  

    The problem is that after sending the RDATA byte which should make the ADC send its conversion result, the TX polling loop in line 93 will timeout or if you remove the timeout it will loop forever. And I can really see no reason for that.

  • To answer your question: [Ref User Guide (SLAU367P) Fig 32-12] The first TXIFG comes "for free", before the Start is issued. There's almost nothing that can go wrong before then. The next TXIFG only appears after (1) the Start has completed (2) the SLA has been ACK-ed, so things can go wrong.

    The usual suspects: (a) Something wrong with the bus, preventing issuing the Start (missing pullups, slave clock-stretching, slave holding SDA low for some reason) (b) NACK from the SLA byte (c) a Start was requested while a Stop was pending. 

    We can probably discount pullups/NACK since prior operations succeeded, and the slave data sheet claims it never clock-stretches. The other failures originate in the previous operation which is (I missed this before) the Start/Synch command. I'll just mention here that sendSingleByte doesn't wait for its UCTXSTP to complete.

    You mention that some operations are triggered by IRQ(s). Are you issuing the I2C operations inside the ISR(s)?

**Attention** This is a public forum