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.

MSP430FR2311: ADXL345 Sensor Interface with MSP430FR2311 uC

Part Number: MSP430FR2311

I have a interface ADXL345 with MSP430FR2311 with the help of I2C Protocol. The below code is working properly without error. But the data from the sensor what I am receiving is raw data. when I tilting this sensor the data from the sensor is remain same. 

The Data receiving in RX Buffer Every time is:

RX_Data[0] = 0x22;

RX_Data[1] = 0x22;

RX_Data[2] = 0x00;

RX_Data[3] = 0x00;

RX_Data[4] = 0x00;

RX_Data[5] = 0x00;

During Next Cycle:

RX_Data[0] = 0x00;

RX_Data[1] = 0xFE;

RX_Data[2] = 0x00;

RX_Data[3] = 0xFE;

RX_Data[4] = 0x00;

RX_Data[5] = 0x00;

The Above Sequence is repeated continuously. 

Please check whether my code is correct  or whether it needs any modification for proper working.

================================================================================

=================================================================================

#include <msp430fr2311.h>


volatile unsigned char TxData[3];
volatile unsigned char RX_Data[6];
volatile int Tx_Counter;
int RX_Counter;
volatile unsigned int Tx_Int_Counter;
volatile unsigned int Rx_Int_Counter;
volatile unsigned char Transmit[10];
volatile int Reg_Add1;
void TX_Data_For_Data_Demand(unsigned char Reg_Add);
void TX_Data_Format_Bit(unsigned char Reg_Add,unsigned char Reg_Data);

unsigned int UCB0CTVALUE;

int main(void)
{
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

// Configure Pins for I2C
P1SEL0 |= BIT2 | BIT3; // I2C pins

// Disable the GPIO power-on default high-impedance mode
// to activate previously configured port settings
PM5CTL0 &= ~LOCKLPM5;

// Configure USCI_B0 for I2C mode
UCB0CTLW0 |= UCSWRST; // put eUSCI_B in reset state
UCB0CTLW0 |= UCMODE_3 | UCMST | UCSYNC; // I2C master mode, SMCLK
UCB0BRW = 0x8; // baudrate = SMCLK / 8
UCB0CTLW0 &=~ UCSWRST; // clear reset register
UCB0I2CSA |= 0x0053;


__bis_SR_register(GIE);



//TX_Data_Format_Bit(0x2C,0x0A); // Power control
//while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent

TX_Data_Format_Bit(0x2D,0x00); // Power control
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent

TX_Data_Format_Bit(0x2D,0x08); // Power control
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent

TX_Data_Format_Bit(0x31,0x00); // Data format
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent



while(1)
{

while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent

TX_Data_For_Data_Demand(0x32);
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent



}

}

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector = USCI_B0_VECTOR
__interrupt void USCIB0_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(USCI_B0_VECTOR))) USCIB0_ISR (void)
#else
#error Compiler not supported!
#endif
{
switch(__even_in_range(UCB0IV,USCI_I2C_UCBIT9IFG))
{
case USCI_NONE: break; // Vector 0: No interrupts break;
case USCI_I2C_UCALIFG: break;
case USCI_I2C_UCNACKIFG:
UCB0CTL1 |= UCTXSTT; //resend start if NACK
break; // Vector 4: NACKIFG break;
case USCI_I2C_UCSTTIFG: break; // Vector 6: STTIFG break;
case USCI_I2C_UCSTPIFG: break; // Vector 8: STPIFG break;
case USCI_I2C_UCRXIFG3: break; // Vector 10: RXIFG3 break;
case USCI_I2C_UCTXIFG3: break; // Vector 14: TXIFG3 break;
case USCI_I2C_UCRXIFG2: break; // Vector 16: RXIFG2 break;
case USCI_I2C_UCTXIFG2: break; // Vector 18: TXIFG2 break;
case USCI_I2C_UCRXIFG1: break; // Vector 20: RXIFG1 break;
case USCI_I2C_UCTXIFG1: break; // Vector 22: TXIFG1 break;
case USCI_I2C_UCRXIFG0:
RX_Data[RX_Counter] = UCB0RXBUF;
RX_Counter++;
Rx_Int_Counter++;
break; // Vector 24: RXIFG0 break;
case USCI_I2C_UCTXIFG0: // Check TX byte counter
// Reg_Add1 = TxData[Tx_Counter];
UCB0TXBUF = TxData[Tx_Counter];
Tx_Counter--;
Tx_Int_Counter++;
break; // Vector 26: TXIFG0 break;
case USCI_I2C_UCBCNTIFG: break; // Vector 28: BCNTIFG
case USCI_I2C_UCCLTOIFG: break; // Vector 30: clock low timeout
case USCI_I2C_UCBIT9IFG: break; // Vector 32: 9th bit
default: break;
}
}


void TX_Data_Format_Bit(unsigned char Reg_Add, unsigned char Reg_Data)
{
Tx_Counter = 2;
UCB0IE |= UCTXIE0| UCNACKIE; // transmit and NACK interrupt enable
TxData[2] = Reg_Add;
TxData[1] = Reg_Data;
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent
UCB0CTLW0 |= UCTR | UCTXSTT; // I2C TX, start condition

while(Tx_Counter != 0)
{
__no_operation();
}

UCB0CTLW0 |= UCTXSTP;
UCB0IE &= ~UCTXIE; // Clear USCI_B0 TX int flag
}

void TX_Data_For_Data_Demand(unsigned char Reg_Add)
{
Tx_Counter = 1;
TxData[1] = Reg_Add;
RX_Counter=0;
while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent
UCB0CTLW0 |= UCTR | UCTXSTT; // I2C TX, start condition
UCB0IE |= UCTXIE0; // transmit and NACK interrupt enable

while(Tx_Counter != 0)
{
__no_operation();
}
UCB0IE &= ~UCTXIE; // Clear USCI_B0 TX int flag

UCB0CTLW0 |= UCTXSTP;
UCB0CTVALUE = UCB0CTLW0;

while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent
UCB0CTLW0 &= ~UCTR;
UCB0CTLW0 |= UCTXSTT; // I2C TX, start condition

UCB0IE |= UCRXIE0; // transmit and NACK interrupt enable
while (RX_Counter<6)
{
__no_operation();
}
UCB0CTLW0 |= UCTXNACK | UCTXSTP;

UCB0IE &= ~UCRXIE; // Clear USCI_B0 TX int flag
__no_operation();
}

  • Hi Kelvin,

    The E2E forum is best used with more direct questions. I'm happy to help but I can't simply review your code with the little direction you've provided. From your post it sounds like you have I2C working and you're just not getting the correct values from your sensor. I recommend using a logic analyzer to view the line and make sure the data you are RX/TXing is correct. If the questions is more specific to the functionality of the ADXL345, I may not be of much help because I only have expertise with the MSP430 family of devices.

    Best regards,
    Caleb Overbay
  • Hi Caleb,

    Thanks for your suggesation. 

    The Data what I'm sending to the sensor is correct and it has been observed on logic Analyzer.

  • Hi Kelvin,

    If you're sure that the correct data is being sent from the MSP430, then the problem most likely exists on the ADXL345 side. Either you are sending incorrect commands from the MSP430 or the ADXL345 isn't operating correctly Have you made anymore progress on this?

    Best regards,
    Caleb Overbay

**Attention** This is a public forum