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.

MSP430F5529: Reading from ADS1118

Part Number: MSP430F5529
Other Parts Discussed in Thread: ADS1118, MSP430G2553

Hello,  I had a problem with ADS1118 communication to MSP430F5529, as posted on this forum https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/725664

That issue was never resolved, so we decided to use an FPGA to talk to the ADS1118, and that was working momentarily but is now having issue, and we want to re-investigate the MSP439FF5529.  However, I'm still having issue with this MSP430F5529-to-ADS1118 communication.

Is there an ADS1118 Apps Engr I can communicate to? Or example ADS1118-MSP430F5529 code I can look at?  Thanks.

  • Hello Amy,

    I will be routing this post to the appropriate group to speak on the ADS1118. In the meantime, please check out the following application note for the MSP430F5529 side of things. This should help in general for SPI debugging.
    http://www.ti.com/lit/slaa734
  • Hi Jace,

    This was helpful, thanks. I'll keep that in mind for future projects. It seems like my communication is correct since I can see correct ADS1118 output data on the scope.  It seems like my issue is still the MSP430's inability to capture LSB of the ADS1118's output data.  To summarize my problem:

    1. I'm using MSP430F5529 to communicate to ADS1118
    2. My communication is correct since I can see the correct ADS1118 output code on the oscilloscope. 
    3. However, the MSP430 cannot capture the ADS1118's LSB output code. The MSP430 can only capture the ADS1118's MSB output code. 
    4. Whenever I try stepping through the codes, the UCA0RXBUF__SPI registers don't get updated with the LSB output code UNLESS I put a break-point at just ReceiveBuffer[1].  If I put a breakpoint at both ReceiveBuffer[0] and ReceiveBuffer[1] and cycle through my codes, then the ReceiveBuffer just reports the MSB.  See my code in the previous forum 
    5. It seems like a timing issue, and I've tried adding delays in various places but that didn't help much. 

    Any help would be appreciated. Thanks.

  • Amy,


    I'm sorry I didn't see this earlier.

    As Bob had mentioned in a previous post, it seems like a timing issue from sending the TX buffer contents. I'm not sure if this will help, but there is at least a template available on how to read the ADS1118 using an MSP430 device. There is an ADS1118 Booster pack available that connects to an MSP430G2553, which should be similar. It comes with some downloadable code that you can find here:

    www.ti.com/.../430BOOST-ADS1118

    Within the code, you can find functions that read and write to the ADS1118. It's a bit different than yours as it does use the 32-bit data transmission cycle.

    Again, I'm not sure if it will help - I'm generally not the coder of the group. Bob's out on vacation until next week and might be able to add a few comments when he's back.


    Joseph Wu
  •                     uca0_rx_val = UCA0RXBUF;
                        ReceiveBuffer[0] = uca0_rx_val;
                        uca0_rx_val = UCA0RXBUF;
                        ReceiveBuffer[1] = uca0_rx_val;
                        uca0_rx_val = UCA0RXBUF;
                        ReceiveBuffer[2] = uca0_rx_val;

    This code reads RXBUF without waiting for RXIFG.

    In the interrupt handler, the received byte already is stored in uca0_rx_val, and each invocation of the interrupt must handle only one byte. You have to do it the same way as with RX_DATA_MODE.

  • Amy,

    I think Clemens is correct (thanks Clemens!).  In the link that I posted earlier from here:

    The ADS1118.c has code for the 32-bit data transmission cycle:

    /******************************************************************************
     * function: WriteSPI(unsigned int config, int mode)
     * introduction: write SPI to transmit the configuration parameter for ADS11118, and receive the convertion result.
     * parameters: config: configuration parameter of ADS11118's register, mode (0/1): internal temperature sensor, far-end temperature
     * return value: ADC result
    *******************************************************************************/
    int WriteSPI(unsigned int config, int mode)
    {
    	int msb;
    	unsigned int temp;
    	char dummy;
    
    	//change the polarity of UCI0B_CLK to driver ADS1118.
        UCB0CTL1 |= UCSWRST;
        UCB0CTL0 = UCMSB + UCMST + UCMODE_0 + UCSYNC;
        UCB0CTL1 &= ~UCSWRST;
    
    	temp = config;
    	if (mode==1)
    		temp = config | 0x8000;		// mode == 1, means to read the data and start a new convertion.
    
    
    	while(!(UC0IFG&UCB0TXIFG));
    	UCB0TXBUF = (temp >> 8 );		// Write MSB of Confige
    	while(!(UC0IFG&UCB0RXIFG));
    	msb=UCB0RXBUF;					// Read MSB of Result
    
    	while(UCBUSY & UCB0STAT);
    
    	while(!(UC0IFG&UCB0TXIFG));
    	UCB0TXBUF= (temp & 0xff);		// Write LSB of Config
    	while(!(UC0IFG&UCB0RXIFG));
    	msb = (msb << 8) | UCB0RXBUF ;	//Read LSB of Result
    
    	while(UCBUSY & UCB0STAT);
    
    	while(!(UC0IFG&UCB0TXIFG));
    	UCB0TXBUF = (temp >> 8 );		// Write MSB of Config
    	while(!(UC0IFG&UCB0RXIFG));
    	dummy=UCB0RXBUF;				// Read MSB of Config
    
    	while(UCBUSY & UCB0STAT);
    
    	while(!(UC0IFG&UCB0TXIFG));
    	UCB0TXBUF= (temp & 0xff);		// Write LSB of Config
    	while(!(UC0IFG&UCB0RXIFG));
    	dummy=UCB0RXBUF;				//Read LSB of Config
    
    	while(UCBUSY & UCB0STAT);
    
    	//change back the polarity of UCI0B_CLK for deriving LCD
        UCB0CTL1 |= UCSWRST;
        UCB0CTL0 = UCCKPL + UCMSB + UCMST + UCMODE_0 + UCSYNC;
        UCB0CTL1 &= ~UCSWRST;
    
    	return msb;
    }

    For each byte there is a check for RXIFG.

    I'll close this post for now, but if you're still having problems, post back and we can try to help again.

    Joseph Wu

  • Historical note: The code that Clemens (correctly) highlighted is not present in the "V2" version of this program, which appears as an attachment in the other thread.

    I ran the V2 code on an F5529 Launchpad using (1) pin loopback and (2) an "echo" slave (an FR2311 as I recall) and got correct results. This would seem to point away from a simple timing bug.

    At that point I had to stop since I don't have an ADS1118 here. It's not obvious to me how an SPI slave would influence the behavior of a master, but the symptom described doesn't seem to appear in its absence.

**Attention** This is a public forum