Getting Started with I2C on MSP MCUs

fish001

Getting Started with I2C on MSP MCUs [Copy link]

Guide you how to start a project related to I2C communication using ultra-low power MSP microcontroller (MCU):

Introduction

I2C (or I2C, Integrated Circuit Bus) is a two-wire communication form used primarily for low-speed communication between microcontrollers and peripheral ICs in short-distance, board-to-board applications. Because of its widespread adoption, learning to use ^I2C to communicate with MSP MCUs has become essential in helping engineers develop applications. This guide provides the tools and resources needed to understand the I2C protocol and implement it using an ultra-low-power MSP MCU to access and control IC devices.

Device Terminology

The device that drives the SCL clock line is called the master, and the device that responds to it is called the slave. In most applications, the MSP MCU is the master and the peripheral IC is the slave, although sometimes the MSP device is a slave to other MCUs or processors.

Physical Bus

The I2C bus consists of two lines, SCL and SDA. SCL is the clock line used to synchronize all data transfers, while SDA is the actual data line. A third line is also required, which is common ground, but it is not usually mentioned. Since both lines are "open drain" drivers, they both require pull-up resistors to the power line so that the output remains high during no operation. For MSP MCU applications, the power supply voltage should match the Vcc of the MSP MCU. Traditionally, the value of the pull-up resistor is 4.7kΩ, but this value can range from less than 1kΩ to 10kΩ, depending on the slave device used. For the correct pull-up resistor value, please refer to the device datasheet. Multiple slave devices can share an I2C bus, and a single pull-up resistor

I2C Software Protocol

Regardless of the application, each I2C-capable device needs to follow a common software protocol defined for all I2C devices, and its general structure remains the same. Communication begins with a start sequence and ends with a stop sequence, with an 8-bit data transfer sequence between the two sequences. The start bit is followed by the slave address, which is usually 7 bits (although 10-bit addressing is rarely used). These 7 data bits are placed in the upper 7 bits of a byte, and the LSB (least significant bit) is used to store the read/write (R/W) bit. This bit lets the slave device know whether it is being written to (bit value 0) or read (bit value 1). For a write operation, the operation sequence is as follows:

1. Sending the Startup Sequence
2. Send slave address with R/W bit low
3. Number of send registers
4. Send data byte
5. Send stop sequence

The read operation sequence is very similar to the write operation, except that instead of sending the data bytes, it resends the start sequence (called a repeated start) and the slave address (but this time, the R/W bit is high for a read operation) so that it can receive data instead of sending it. This operation ends with the typical stop sequence from the master. Here is the read operation sequence:

1. Sending the Startup Sequence
2. Send slave address with R/W bit low
3. Number of send registers
4. Issue the boot sequence again (repeat boot)
5. Send out slave address with R/W bit high
6. Read data bytes
7. Issue a stop sequence

MSP MCU Communication Peripherals

To implement serial communication, there are four different peripherals that may be available on an MSP device. Only one of these peripherals will vary from device to device. The peripherals used are listed below in order of difficulty (from most difficult to easiest) to implement I2C communication on an MSP MCU:

• UART: Universal Synchronous/Asynchronous Receiver/Transmitter. This is the oldest form of communication and is present on most MSP430F1xx MCUs. It does not support I2C, so a software-based bit-bang solution must be used to communicate with I2C devices.
• USI: Universal Serial Interface. Another simpler form of communication used for cost effective or space constrained devices such as some components within the MSP430G2xx family. There is no I2C state machine on the device and it must be implemented in software. Typically this is done using separate functions.
• USCI: Universal Serial Interface. A standard communication peripheral optimized for ISR and flag usage. This peripheral is common in the MSP430F5xx/F6xx families and includes a hardware-based I2C state machine, so less code is required to run.
• eUSCI: Enhanced Universal Serial Communications Interface. The most advanced communication peripheral available on MSP devices, it improves upon the existing USCI functionality and is included in all MSP430FRxx (FRAM) MCUs.

When considering using an MSP device with an I2C application, the user should understand that the code structure will vary depending on the peripherals present on a particular MSP family device. Each variant includes different registers, ISRs, and functions that must be taken into account. It is also important to clarify that not all device families use the same peripherals (USCI and eUSCI are present in the MSP430F5xx/6xx, USI and USCI are present in the MSP430G2xx family, etc.), which can be confusing when referring to the family user's guide. Therefore, it is important to review the correct material and select the appropriate example code when beginning application development. Texas Instruments (TI) provides basic I2C code examples for USI, USCI, and eUSCI communications; these code examples can be found on the MSP family device product pages under Tools & software -> Software -> Examples (available in ZIP format, it is important to note that these packages only contain code examples related to the peripherals present on a specific device). For those devices that use a USART, or do not include a communication peripheral, we provide an online I2C bit response solution within the Community Technical Support. Regardless of whether a peripheral is used or not, pull-up resistors are always required to achieve I2C communication. Some MSP devices have internal pull-up resistors, but these are not recommended because several slave devices require specific resistance values that cannot be met internally.

Tips for implementing I2C with MSP

To help avoid common implementation errors when attempting to use I2C to communicate between a peripheral IC and an MSP, it is worth looking at some of the following suggestions:

• Start with the example I2C code provided specifically for your MSP family device (product page -> Tools & software -> Software -> Examples). Review the changes to the I2C registers according to the family user guide (always make sure you are looking at the correct peripheral chapter) so you have a firm grasp on the changes necessary to achieve communication.
• Use the pull-up resistors and addresses specified in the slave device datasheet (this sometimes varies for different input variants). One thing to keep in mind is that the 7 bits of the slave address are stored in the upper 7 bits of this byte, followed by a R/W bit set by the communication peripheral, so this value may need to be shifted left one bit when setting the slave address register.
• Start by writing to a register and monitoring the ACK from the MSP device. Use fault flags and lab equipment to alert on communication failures. Use CCS or the debugging tools provided by IAR to understand how the code is running, which registers are accessed, when functions/ISRs are accessed, and how they are accessed. Once this is done, it will be much easier to add register read functionality.
• The USCI/eUSCI state diagram shows that the UCTXSTP bit needs to be set before the last byte is received. In applications where only one byte is received, the UCTXSTP bit is set together with the UCTXSTT bit. If multiple bytes are received, then UCTXSTP should be set after the N-1th byte is received. This ensures that the stop sequence is sent immediately after the last byte is received.

Debugging suggestions

Before you abandon code that doesn't seem to be working correctly, here are some key points to consider when debugging this system:

• Confirm the pull-up resistor value & slave address value, verify them with the slave device datasheet.
• Double-check communication peripheral initialization, including: register setup, correct pin assignment, interrupts enabled, peripherals turned on/off for operation, etc.
• Use any of the provided tools (IDE debugger, logic analyzer, oscilloscope, etc.) to confirm that the MSP430 and slave device strictly follow the I2C software protocol.
• Check the errata for known I2C issues and see if the errata description matches your application's failure symptoms.
• Research issues in the E2E forums to see if similar situations have been solved. Try different combinations of I2C-related keywords and make good use of the search filters.

E2E Support

If proper debugging and research methods are unsuccessful, the TI E2E Community forum can be an excellent resource for direct communication with device experts. Regardless of the issue, be sure to have detailed information about it to help community members and TI engineers better support your request, including:

• MSP430 Family Devices
• Schematic diagram of the LaunchPad or TI target board used, or custom board
• Slave Device
• An accurate description of the situation or problem that was discovered
• How the debugger is used (CCS or IAR)
• I2C initialization and function/ISR code snippets (not all code)
• Logic analyzer and oscilloscope images with appropriate labels

resource

Migrating from USCI Module to eUSCI Module (SLAA522): 查看详情

Using the USCI I2C Master (SLAA382): 查看详情

Using the USCI I2C Slave (SLAA383): http://www.ti.com/lit/an/slaa383/slaa383.pdf

Using the I2C bus (blog): http://www.robot-electronics.co.uk/i2c-tutorial