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.

MSP430F5438A: I2C Communication problem

Part Number: MSP430F5438A

hi, everyone.

My project is to send and receive 1 Byte to communicate with one MSP430 through I2C Communication.

I have configurated UCB0 I2C(P3.1,P3.2, Master), UCB1 I2C(P3.7, P5.4), transmission speed at 400Kbps and SMCLK at 1MHz. 

I have coded with driverlib of CCS.

It was working. But there are  problems. 

Blue is I2C_SDA and Yellow is I2C_SCL.

1) Frequency of SCL is 203.2KHz. I think the I2C_SCL should come close to 400KHZ. Because I set up  400Kbps.

USCI_B_I2C_initMasterParam I2cParam0 = {0,};
I2cParam0.selectClockSource = USCI_B_I2C_CLOCKSOURCE_SMCLK;
I2cParam0.i2cClk = UCS_getSMCLK();
I2cParam0.dataRate = USCI_B_I2C_SET_DATA_RATE_400KBPS;

USCI_B_I2C_initMaster(USCI_B0_BASE, &I2cParam0);

2) What does 1bit mean between Data Address and NACK ?

3) Is the NACK data signal normally this short? The NACK value could not be maintained for 1 clock.

This is my code.

#include <MSP430.h>
#include <MSP430F5xx_6xx/driverlib.h>

uint8_t transmitData = 0x52;
uint8_t receiveData;
/**
 * main.c
 */
void main(void)
{
	WDT_A_hold(WDT_A_BASE);// stop watchdog timer

	initGPIO();
	initClock();
	initI2C();

	__bis_SR_register(GIE);
	while(1)
	{
		USCI_B_I2C_masterSendSingleByte(USCI_B0_BASE, transmitData);

		while(USCI_B_I2C_isBusBusy(USCI_B0_BASE));

		//__delay_cycles(50);

		transmitData++;
	}
}



#pragma vector = USCI_B1_VECTOR
__interrupt void USCI_B1_ISR(void)
{
	switch(__even_in_range(UCB1IV, 0x0A)){
		case 0x0A:
			receiveData = USCI_B_I2C_slaveGetData(USCI_B1_BASE);
			break;
	default: //__never_executed();
	break;
	}
}
#include <MSP430F5xx_6xx/driverlib.h>

// Clock
#define XT1CLK_HZ 32768
#define XT2CLK_HZ 32768
#define DESIREDMCLK_KHZ 1000
#define MCLKXT1CLKRATIO	DESIREDMCLK_KHZ/(XT1CLK_HZ/1024)

// I2C Slave
#define SLAVEADDRESS 0x51

uint32_t myACLK, mySMCLK, myMCLK;


void initGPIO(void)
{
	//Configurate oscillator 
	GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P7, GPIO_PIN0 + GPIO_PIN1);

	//Configurate I2C
	GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P3, GPIO_PIN1 + GPIO_PIN2 + GPIO_PIN7);
	GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P5, GPIO_PIN4);

	//Configurate SMCLK
	//GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_P11, GPIO_PIN2);
}

	

void initClock(void)
{
	PMM_setVCore(PMM_CORE_LEVEL_3);

	UCS_setExternalClockSource(XT1CLK_HZ, XT2CLK_HZ);
	UCS_turnOnLFXT1(XT1DRIVE_0, XCAP_3);

	UCS_initClockSignal(UCS_ACLK, UCS_XT1CLK_SELECT, UCS_CLOCK_DIVIDER_1);

	//Configurate FLL

	UCS_initClockSignal(UCS_FLLREF, UCS_XT1CLK_SELECT, UCS_CLOCK_DIVIDER_1);
	UCS_initFLL(DESIREDMCLK_KHZ, MCLKXT1CLKRATIO);

	myACLK = UCS_getACLK();
	mySMCLK = UCS_getSMCLK();
	myMCLK = UCS_getMCLK();
}

void initI2C(void)
{
	USCI_B_I2C_initMasterParam I2cParam0 = {0,};
	I2cParam0.selectClockSource = USCI_B_I2C_CLOCKSOURCE_SMCLK;
	I2cParam0.i2cClk = UCS_getSMCLK();
	I2cParam0.dataRate = USCI_B_I2C_SET_DATA_RATE_400KBPS;

	USCI_B_I2C_initMaster(USCI_B0_BASE, &I2cParam0);
	USCI_B_I2C_initSlave(USCI_B1_BASE, SLAVEADDRESS);

	USCI_B_I2C_setSlaveAddress(USCI_B0_BASE, SLAVEADDRESS);

	USCI_B_I2C_setMode(USCI_B0_BASE, USCI_B_I2C_TRANSMIT_MODE);
	USCI_B_I2C_setMode(USCI_B1_BASE, USCI_B_I2C_RECEIVE_MODE);

	USCI_B_I2C_enable(USCI_B0_BASE);
	USCI_B_I2C_enable(USCI_B1_BASE);

	USCI_B_I2C_clearInterrupt(USCI_B0_BASE, USCI_B_I2C_TRANSMIT_INTERRUPT);
	USCI_B_I2C_clearInterrupt(USCI_B1_BASE, USCI_B_I2C_RECEIVE_INTERRUPT);

	USCI_B_I2C_enableInterrupt(USCI_B0_BASE, USCI_B_I2C_TRANSMIT_INTERRUPT);
	USCI_B_I2C_enableInterrupt(USCI_B1_BASE, USCI_B_I2C_RECEIVE_INTERRUPT);
}

  • 2) I see a 0 bit (Write) between the address and the ACK. The rising (SCL) edges are the significant moments, not the falling edges.

    3) The "blip" on SDA over at the right is actually an ACK (again: rising edge). The master released the data line, which was pulled up briefly before the slave asserted it.

    1) The [E]USCI has only a simple integer clock divider (BR0/1), so there are some bus speeds you can't achieve. With a 1MHz SMCLK you can get 250/333/500kHz (BR0=4/3/2). Driverlib's arithmetic truncates, so it always produces a clock greater than or equal to that requested (I personally don't agree with this). The SET_DATA_RATE_400KHZ definition is just the number 400000UL, so if you substitute e.g. 300000UL there you'll get 333kHz. Alternatively, if you can run your CPU (really SMCLK) at say 8MHz, you can get exactly 400kHz (BR0=20).

    That said, there's another more subtle thing (probably) going on here. I did some experiments some time back with the EUSCI (much in common with your USCI) and observed that as I stepped the I2C clock speed up, I reached a point where the (actual) clock slowed down. My hypothesis was that the I2C unit's internal clock monitor was backing off (in units of BR0) when it detected that it was running faster than the I2C spec allowed. I'm pretty sure I reported this in the Forum, but I didn't find it just now. This isn't wrong, but it was a bit of a surprise to me.

    [Edit: Minor clarification.]

  • I'm sorry about late response.

    I want to make some corrections in my writing.

    It changed from Data address to Data. 

    I have a few questions after seeing your answer. (2,3 question)

    1)  // this is not a question.

    I set SMCLK to 1MHz and  I2C to 400KBps (Actually SMCLK is 1.013~1.02 MHz). In debuging mode, UCBRW was 0x0002.

    I thoguht iwas getting 250kHz,  But I got 203kHz. 

    So In this setense

    Driverlib's arithmetic truncates, so it always produces a clock greater than or equal to that requested (I personally don't agree with this).

    I also agree with you.

    2) Question


    My code is to send and receive 1 Byte to communicate with one MSP430 through I2C Communication.

    In the picture above, there is no R / \W in data part. 

    Is your answer correct in the correction I made?

    3)  Question

    Is this ACK or NACK in "blip" on SDA over at the right ? (between ?? and SP)

     

**Attention** This is a public forum