Getting Started with I2C on MSP MCUs

Aguilera

Getting Started with I2C on MSP MCUs [Copy link]

This is an introductory guide to get started with an I2C communication project using an ultra-low-power MSP microcontroller (MCU): Introduction I2C (or I2C, Integrated Circuit Bus) is a two-wire communication format used primarily for low-speed communication between microcontrollers and peripheral ICs in short-distance, board-to-board applications. Because of its widespread adoption, learning how 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 another MCU or processor.

Physical Bus

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

I2CSoftware Protocol

Regardless of the application, each I2C-capable device must adhere to 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). The 7 data bits are placed in the upper 7 bits of a byte, with the LSB (least significant bit) being used to store the read/write (R/W) bit. This bit lets the slave know whether it is being written to (bit value 0) or read from (bit value 1). For a write operation, the sequence of operations is as follows:

• Send start sequence
• Send slave address with R/W bit low
• Send register number
• Send data byte
• Send stop sequence The read operation sequence is very similar to the write operation, except that instead of sending 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 sequence of read operations:
  • Send start sequence
  • Send slave address with R/W bit low
  • Send number of registers
  • Issue start sequence again (repeated start)
  • Issue slave address with R/W bit high
  • Read data bytes
  • Issue stop sequence
  MSP MCUCommunication Peripherals
  For serial communication, there are four different peripherals available on the 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 the 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. An alternative, simpler form of communication used in cost-effective or space-constrained devices such as some components within the MSP430G2xx family. There is no I2C state machine on the device and this must be implemented in software. This is typically done using separate functions.
  • USCI: Universal Serial Interface. A standard communication peripheral optimized for ISR and flag usage. This peripheral is commonly found 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 the specific MSP family of devices. 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 for your situation when beginning application development. Texas Instruments (TI) provides basic I2C code examples for USI, USCI, and eUSCI communications; these code examples can be found in Tools & software -> Software -> Examples.The MSP family of devices can be found on the product page for the MSP family of devices under . (ZIP files are available, and it is important to note that these packages only contain code examples related to the peripherals present on the 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, pull-up resistors are always required to achieve I2C communication. Some MSP devices have internal pull-up resistors, but their use is not recommended because several slave devices require specific resistance values that cannot be met internally. Tips for Implementing I2C with MSPs To help avoid common implementation errors when trying to use I2C to communicate between a peripheral IC and an MSP, the following suggestions are worth looking over: 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's guide (always make sure you are looking at the correct peripheral section) so that 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 may vary depending on the input variant). 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.
• Begin by writing to a register and monitoring the ACK from the MSP device. Use fault flags and lab equipment to alert communication failures. Use debugging tools provided by CCS or IAR to understand how the code is running, which registers are accessed, when functions/ISRs are accessed, and how they are accessed. Once this has been 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 along with the UCTXSTT bit. If multiple bytes are being 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 Tips

Before giving up on 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 values & slave address values, verify them with the slave device datasheet.
• Double-check the initialization of the communication peripherals, including: register setup, correct pin assignments, interrupts enabled, peripherals armed/released for operation, etc.
• Use any provided tools (IDE debugger, logic analyzer, oscilloscope, etc.) to confirm that the MSP430 and slave devices strictly follow the I2C software protocol.
• Check the errata for known I2C issues and see if the errata description matches the application's failure symptoms.
• Research the issues in the E2E forum to see if similar situations have been solved. Try different combinations of I2C-related keywords and make good use of the search filters.

E2ESupport

If proper debugging and research methods are not successful, the TI E2E Community forums 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 device, LaunchPad or TI target board being used, or circuit schematic for custom board being used Slave device, Exact description of the condition or issue being observed, Exact description of the condition or issue being observed, while using a debugger (CCS or IAR)

I2C initialization and function/ISR code snippets (not all code)

Logic analyzer and oscilloscope images with appropriate labels Examples). Look at the changes to the I2C registers according to the family user's guide (make sure you are looking at the correct peripheral section) 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 with the input variant). 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 the 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 to communication failures. Use CCS or the debugging tools provided by IAR to understand how the code is running, which registers are accessed, when the functions/ISRs are accessed, and how they are accessed. Once this has been 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 along 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 Tips

Before giving up on 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 values & slave address values, verify them with the slave device datasheet.
• Double-check the initialization of the communication peripherals, including: register setup, correct pin assignments, interrupts enabled, peripherals armed/released for operation, etc.
• Use any provided tools (IDE debugger, logic analyzer, oscilloscope, etc.) to confirm that the MSP430 and slave devices strictly follow the I2C software protocol.
• Check the errata for known I2C issues and see if the errata description matches the application's failure symptoms.
• Research the issues in the E2E forum to see if similar situations have been solved. Try different combinations of I2C-related keywords and make good use of the search filters.

E2ESupport

If proper debugging and research methods are not successful, the TI E2E Community forums 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 device, LaunchPad or TI target board being used, or circuit schematic for custom board being used Slave device, Exact description of the condition or issue being observed, Exact description of the condition or issue being observed, while using a debugger (CCS or IAR)

I2C initialization and function/ISR code snippets (not all code)

Logic analyzer and oscilloscope images with appropriate labels Examples). Look at the changes to the I2C registers according to the family user's guide (make sure you are looking at the correct peripheral section) 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 with the input variant). 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 the 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 to communication failures. Use CCS or the debugging tools provided by IAR to understand how the code is running, which registers are accessed, when the functions/ISRs are accessed, and how they are accessed. Once this has been 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 along 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 Tips

Before giving up on 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 values & slave address values, verify them with the slave device datasheet.
• Double-check the initialization of the communication peripherals, including: register setup, correct pin assignments, interrupts enabled, peripherals armed/released for operation, etc.
• Use any provided tools (IDE debugger, logic analyzer, oscilloscope, etc.) to confirm that the MSP430 and slave devices strictly follow the I2C software protocol.
• Check the errata for known I2C issues and see if the errata description matches the application's failure symptoms.
• Research the issues in the E2E forum to see if similar situations have been solved. Try different combinations of I2C-related keywords and make good use of the search filters.

E2ESupport

If proper debugging and research methods are not successful, the TI E2E Community forums 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 device, LaunchPad or TI target board being used, or circuit schematic for custom board being used Slave device, Exact description of the condition or issue being observed, Exact description of the condition or issue being observed, while using a debugger (CCS or IAR)

I2C initialization and function/ISR code snippets (not all code)

Logic analyzer and oscilloscope images with appropriate labels The E2E Community Forums can be an excellent resource for direct communication with device experts. Regardless of the issue, it is important to have detailed information about it to help community members and TI engineers better support your request, including:

• MSP430 family device
• Schematic diagram of the LaunchPad or TI target board being used, or custom board
• Slave device
• An exact description of the condition or issue being observed
• Operation observed while using a debugger (CCS or IAR)
• I2C initialization and function/ISR code snippets (not all code)
• Logic analyzer and oscilloscope images with appropriate labels

The E2E Community Forums can be an excellent resource for direct communication with device experts. Regardless of the issue, it is important to have detailed information about it to help community members and TI engineers better support your request, including:

• MSP430 family device
• Schematic diagram of the LaunchPad or TI target board being used, or custom board
• Slave device
• An exact description of the condition or issue being observed
• Operation observed while using a debugger (CCS or IAR)
• I2C initialization and function/ISR code snippets (not all code)
• Logic analyzer and oscilloscope images with appropriate labels