MSP430F5338: I2C slave not responding to ACLK.

I'm not quite sure what you're describing. Do you see a Start pulse and nothing more? Or no activity at all? Do you have a scope trace?

If you're suspicious of your ACLK, I would suggest:
1) Try running the I2C using SMCLK (with a suitable BR0 value) and see if it's different.
2) Configure P1.0 to output ACLK and check it on a scope

How are the TMP75 address pins (A0-A2) configured?

Hi Mohammed Zakariya,
I went through your configuration and I couldn't find anything implausible.
You can skip "UCB0CTL0 &= ~UCSLA10;" since you're clearing UCB0CTL0 a few lines prior, but it doesn't hurt to keep this in as long as this is not time critical.
You are only showing the initializations in the snippet above, so I hope you write to the TX buffer elsewhere in your code to actually start a I2C transmission.
I agree with Bruce that it makes sense to check if ACLK clock source works properly.

Please let me know if that helps to find the root cause.

Thanks for replying,  

1) Try running the I2C using SMCLK (with a suitable BR0 value) and see if it's different.

1. On using the SMCLK with the crystal oscillator operating at 16 MHz and using the DCO to output it at 8MHz the following waveform was observed,

the BR0 value given was 80, to get a clock of 100 Khz

On without giving any value for prescaling on giving 8Mhz, I am getting an unusual behaviour with the clock as follows, the obtained frequency in SCL is 125 hz

This was the obtained behaviour on configuring with SMCLK.  

2) Configure P1.0 to output ACLK and check it on a scope

Sorry this will not be possible to do ,The module currently in use is doesn't have a pin out and there are no test points on the ACLK and SMCLK pins respectively.

Hi Maximilian Albrecht,

Thanks for replying, sorry that I didn't attach the I2C function, I am attaching it along with this reply. This function issues the start bit and the purpose it serves is to receive two bytes


void receive_i2c(unsigned char byteCount, unsigned char data){
{
*TI_transmit_field = data;
unsigned char RX_Data[2];
byteCtr = byteCount;

UCB0CTL1 |= UCTR | UCTXSTT;

while(!(UCB0IFG & UCTXIFG));

UCB0TXBUF = data;

while(!(UCB0IFG & UCTXIFG)); // Wait for Tx flag to be set

UCB0CTLW0 &= ~UCTR; //Repeated start condition
UCB0CTLW0 |= UCTXSTT;

while(!(UCB0IFG & UCRXIFG)); // Wait for Rx flag to be set

RX_Data[0] = UCB0RXBUF;
while(!(UCB0IFG & UCRXIFG));

RX_Data[1] = UCB0RXBUF;
UCB0CTLW0 |= UCTXNACK;
UCB0CTLW0 |= UCTXSTP;

while(!(UCB0IFG & UCSTPIFG)); // Wait for stop flag to be set
}

I have explained in a reply to Bruce that we currently don't have the provision to see the ACLK or SMCLK. Please put forward your inputs after reviewing. Thanks in advance.

Hi Mohammed Zakariya,

Can you confirm that you have applied pull-up resistors at SCL and SDA lines? Since there seem to be no quicker clock than 125 hz that might indicate that the port is not pulled to high between clock pulses..?

Best regards,
Max

> UCB0IE |= (UCTXIE | UCRXIE) ; // Enable TX interrupt
You're enabling these interrupts, but I don't see an ISR. Your receive_i2c function seems to not expect them to be set.

My guess is that your program is resetting (or worse) after sending the address byte (TXIFG), and that's why SCL is going "dead". I recommend you remove that line.

[Edit: Actually, if you're using a recent version of CCS your program is probably spinning in ISR_fault, i.e. it's not restarting.]