• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 575 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LP-MSP430FR2476: I2C communication breaks between debug sessions on Code Composer Studio

Sourabh Marathe
Prodigy 195 points
Part Number: LP-MSP430FR2476
Other Parts Discussed in Thread: LP5569, MSP430WARE

Hello TI experts,

I have been working on getting multi-byte I2C communication between two TI parts, an LP-MSP430FR2476 and an LP-5569 EVM (LED driver). I have had some success with writing basic values to the board, but I've noticed some difficulty between debug sessions. Namely, when I open a debug session for the first time, I have no problems with operating I2C communication between the two parts. However, when I close a debug session and reopen a new one, I notice that the code gets blocked in the call to EUSCI_B_I2C_masterMultiByteSendStart in the line immediately following the start generation.

I am using the basic configuration for the I2C module from the example code provided in MSP430Ware. Here's a rough sketch of the function I am using to write to the control registers of the LP5569:

EUSCI_B_I2C_masterSendMultiByteStart(EUSCI_B0_BASE, control_reg);

//Optimistically waits (if no NACK or ARBITRATION LOST, continue with writing the next value to the bus
__delay_cycles(100);

EUSCI_B_I2C_masterSendMultiByteFinish(EUSCI_B0_BASE, value);

I find that the code typically gets stuck on the following line of code in eusci_b_i2c.c from MSP430Ware's driverlib when I make the first call to the function described above: while (!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG)) ;

Any assistance is greatly appreciated!

  • 0
    Guru 99715 points

    If the bus hang survives a (debugger) restart cycle, that suggests that the slave (LP5569) is holding SCL and/or SDA low, so the master (MSP430) can't issue a Start (or a Stop). The LP5569 data sheet doesn't mention clock-stretching, but that doesn't mean it doesn't do it.

    If you're using the Booster Pack (LP5569EVM) I don't see any programmatic way to reset the slave. A quick experiment might be to remove then replace the VINSEL jumper, which I think will cause a (slave) power cycle.

  • 0 in reply to Bruce McKenney
    Prodigy 195 points

    Thank you for your response!

    I am using the booster pack. I have also noticed that when I unplug both devices (powered via USB from my computer), the I2C communications start to work again. Programmatically, is there a way to get the slave to stop holding the SDA/SCL lines down? I had tried to send a STOP condition to the slave before starting any communications, but that just leaves the program hanging waiting for an interrupt just like it does with a START condition (e.g. on the while (!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG)) ; line of code).

  • 0 in reply to Sourabh Marathe
    Guru 99715 points

    In the general case, there's not much you can do. [Ref I2C Spec (UM10204 r6 Sec 3.1.16]

    Re-reading the L5569/EVM data sheets, it looks as though you have access to the EN/PWM pin via (I think) P4.7. If you hold this low for 15ms, the chip becomes "disabled" which I suspect means it gets off the bus. [Ref L5569 data sheet Secs 8.3.1.2.4 and 7.9].

    While I expect this will get you around the immediate roadblock, the fact that the slave is acting like this suggests you're mistreating it in some subtle way. For this, the interesting scope trace will be of the final successful transaction, which I suspect didn't finish in exactly the way the slave wanted.

**Attention** This is a public forum