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.
Part Number: MSP432P401R
Tool/software: Code Composer Studio
I am trying to communicate with a lidar (lidarlite) and am able to read from it continuously (if i don't write to it); If i try to write to it, one sequence is generated (with proper communication back), but after a significant delay, (to allow for the lidar to process) a second write (whether for read or write) is unsuccessful. the i2C module on the MSP seems to think the bus is busy, even though both lines are high and the first communication was successful; the second start condition never generates.
all of this is on the msp432p401r Development board with the XDS110 debugger
What i have tried: using autostop with 2 bytes (commented out below); manually stopping; two stop conditions; resetting the module; changing modules (worked once, then same problem);
things verified: on the second time around: stop condition generated; after STOP, status says bus busy; UCTXSTT Bit is set; remains busy;
Below is my code:
#include "msp.h"
#include <stdint.h>
#include <stdbool.h>
#include <debug.h>
#include "driverlib.h"
#include <stdint.h>
#include <string.h>
#include "i2c_driver.h"
#define SLAVE_ADDRESS 0x62
void main(void)//
{
WDT_A->CTL = WDT_A_CTL_PW | WDT_A_CTL_HOLD; // stop watchdog timer
//USING INTERNAL 12MHz CLOCK CODE
CS_setDCOCenteredFrequency(CS_DCO_FREQUENCY_12);
CS_setDCOFrequency(12000000); //TUNES TO 12MHz
MAP_CS_initClockSignal(CS_MCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1);
MAP_CS_initClockSignal(CS_SMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1);
//--------------------initialize---------------------------------------------------
EUSCI_B3->CTLW0 = UCSWRST; //reset state
MAP_GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P10,
GPIO_PIN2 | GPIO_PIN3, GPIO_PRIMARY_MODULE_FUNCTION);
UCB3CTLW0 |= UCMST | UCMODE_3 | UCSYNC | UCSSEL_3 | UCTR;
//UCB3CTLW1 = UCASTP_2;
//UCB3TBCNT = 2; //auto stop at 2 bytes
UCB3BRW = 120;
UCB3I2CSA = SLAVE_ADDRESS;
EUSCI_B3->CTLW0 &= ~UCSWRST; //OUT OF reset state
while(1)
{
UCB3CTLW0 |=UCTR; //ensures in transmit mode for writing to register
UCB3CTLW0 |= UCTXSTT; //START condition; ALSO SENDS SLAVE ADDRESS
while ((UCB3CTLW0 & UCTXSTT)); //wait to stabilize
UCB3TXBUF = 0; //register of device for writing
while (!(UCTXIFG0 & UCB3IFG)); //wait for ACK,
UCB3TXBUF = 0; //command
while (!(UCTXIFG0 & UCB3IFG)); //wait for ACK,
UCB3CTLW0 |= UCTXSTP;
while((UCB3CTLW0 & UCTXSTP));//stop condition
__delay_cycles(220000);//allow for reset
UCB3CTLW0 &= ~UCTR;
};
}
Dear customer,
Thank you for your inquiry related to the MSP432 product. We recommend that you consult the many resources at dev.ti.com, including SDK user’s guides, libraries, utilities, software examples and SimpleLink Academy training modules.
Thank you for your time and consideration,
Seong
I have tried many using all of the resources at my disposal, including all that you have provided. I have tried copying and pasting example code to no avail. I have tried two different dev boards with the same results (using the example code from resource explorer) and still had no luck. I have scoured forums on this website trying to find a similar issue.
To reiterate, I successfully send one write sequence; however, the second write sequence refuses to initiate a start even though both lines are high.
Updates to what has been tried: changing pull ups to 4.7k and 9.2k; using pull up/down resistors on the msp432p401r; using multibyte start (and finish); manual start, send single byte (x2) and manual stop;
Hi Chad,
Apologies for the late reply. Could you share oscilloscope shots of the i2c lines?
Have you tried toggling the clock line before the second write in case it is stuck?
Do you have another MCU board other than the MSP432 to test if there are any differences?
I see you're using driverlib. Have you tested communication using TI Drivers?
BR,
Seong
Hi Seong,
Don't worry about it, I used a different form of communication in order to get it to work, thanks though.
BR
Chad
**Attention** This is a public forum