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.
Good morning everyone,
I am not entirely new to the MSP430 world, and I have a decent experience as embedded firmware programmer. Driverlib is something new from my previous experience with MSP430, and
I find it an excellent tool....once I will be able to make it work.....
I just added this so that once the problem will be solved I will look even more like a fool :).
My problem is that I need to develop a very simple project in which a sensor is connected via I2C to an MSP430 device, and the CPU periodically reads the value.
So far so good....I thought. So, I ordered 2 development kits of MSP430, I read the driverlib documentation and I decided to use the I2C example as a reference. The MSP used in the example are
the FR4133, but I thought the difference was just in the port and pins configuration.
To make the long story short, I am struggling since a few days to have the I2C working! No matter what I try, I always have nothing on my logic analyser, and this is driving me crazy!
I am now in the easiest configuration I can imagine: I have the development board connected via USB to the PC, I have my logic analyser connected to the Eusci_B0 pins which are supposed
to work as I2C (1.3 and 1.2) and I run the basic code that follows
#include "driverlib.h" volatile uint8_t transmitData; int main(void) { WDT_A_hold(WDT_A_BASE); GPIO_setAsPeripheralModuleFunctionInputPin( GPIO_PORT_P1, GPIO_PIN2 + GPIO_PIN3, GPIO_PRIMARY_MODULE_FUNCTION ); PMM_unlockLPM5(); //Initialize Master EUSCI_B_I2C_initMasterParam param = {0}; param.selectClockSource = EUSCI_B_I2C_CLOCKSOURCE_SMCLK; param.i2cClk = CS_getMCLK(); param.dataRate = EUSCI_B_I2C_SET_DATA_RATE_400KBPS; param.byteCounterThreshold = 1; param.autoSTOPGeneration = EUSCI_B_I2C_NO_AUTO_STOP; EUSCI_B_I2C_initMaster(EUSCI_B0_BASE, ¶m); //Specify slave address EUSCI_B_I2C_setSlaveAddress(EUSCI_B0_BASE, 0x48 ); //Set in transmit mode EUSCI_B_I2C_setMode(EUSCI_B0_BASE, EUSCI_B_I2C_TRANSMIT_MODE ); //Enable I2C Module to start operations EUSCI_B_I2C_enable(EUSCI_B0_BASE); transmitData = 1; while (1) { //Send single byte data. EUSCI_B_I2C_masterSendSingleByte(EUSCI_B0_BASE, transmitData ); //Delay until transmission completes while (EUSCI_B_I2C_isBusBusy(EUSCI_B0_BASE)) ; //Delay between each transaction __delay_cycles(50); //Increment transmit data counter transmitData++; } return (0); }
I would expect to see something on the logic analyser, but the signals are never moving (and yes, I double checked that the analyser works....it does).
So, my question is....what is wrong here? I already tried the example codes (singleTX, multipleSlaves, and so on), I already tried a second board, I tried all the possible clock system configurations and clock sources.....always the same issue. The out_of_box example works fine, and I am able also to blink on board leds and to move the pins high/low.....but the I2C does never work!
Please, someone point me to the right direction to understand this weirdness.....what am I missing??
Just as additional information....I read the AN concerning common issues and I tried running the i2c_standard_master.c recommended example, which does not use driverlib.....Still no luck, no sign of activity on the pins.
My first guess is the pullups -- does your analyzer show the pin state(s) as high or low? The Launchpad doesn't supply the pullups. Some sensor breakout boards supply the pullups.
In a pinch you might succeed with the internal pullups, something like:
> GPIO_setAsInputPinWithPullUpResistor(GPIO_PORT_P1, GPIO_PIN2 | GPIO_PIN3);
Do this before the setAsPeripheralModule call. In the worst case, this call won't hurt anything.
Of course, that was it.
I don't know why (I don't think I read it anywhere), but I assumed this was taken care of in the setAsPeripheralModule call.....
This fixed this first issue and I am now able to see a first communication on the lines.
I have another issue now but I think I will open a separate discussion.
Thanks a lot for your help!
The internal pullups aren't very strong, so you may want to slow the I2C down (100kHz, maybe). And keep your wires fairly short.
**Attention** This is a public forum