Pumpkin, Inc.

Pumpkin User Forums

Issue with UCB0 I2C on MSP430

Discussions pertaining to the electrical issues (e.g. circuitry, power, etc.) of Pumpkin's CubeSat kit.

Issue with UCB0 I2C on MSP430

Postby JWalnut » Sat Dec 02, 2017 11:08 am

Greetings,

I'm working with an MSP430F2618 plugged into a Development Board (hardware revision E). I recently developed an I2C driver for the MSP, and during testing I came across some very odd things with our hardware. I want to know if the issues I was running into are user error, or if there is a problem with our hardware (either a manufacturing defect, or if our particular device is broken). I have looked through the recent post about issues with the I2C (viewtopic.php?f=30&t=2511), but the problems I was seeing are not exactly those addressed in that post.

First, allow me to provide a little background.

As far as I can tell, in order to properly communicate over I2C using this hardware (MSP430F2618, Dev. Board), there are three things that must be configured.
1. The four jumpers connected to the MSP, that have three labeled configurations. One for F261x UCB0, one for F261x UCB1, and one for a different MSP430. These, I understand from the forum post mentioned above, control the isolator chip in some way (they are not mentioned in the datasheet, so I have no more information than that implies).
2. The physical pin connections to the peripheral with which one wishes to communicate. The peripheral must be connected to the CubeSat headers in the following way.
Ground must be connected to, well, ground (CubeSat header pins H2.29, H2.30, H2.32).
VCC for the peripheral must be connected to VCC_SYS (CubeSat header pins H2.27, H2.28).
For UCB0, SCL must be connected to SCL_SYS (CubeSat header pin H1.43). SDA must be connected to SDA_SYS (CubeSat header pin H1.41).
For UCB1, SCL must be connected to CubeSat header pin H1.6. SDA must be connected to CubeSat header pin H1.7. Both of these must be connected to VCC_SYS via a pull-up resistor (I used 1.5kΩ).
3. Any I2C driver software must be configured to use either UCB0 or UCB1 by changing pin settings, configuration registers, etc.
3b. When using UCB0, one must also set the I2C isolator enable pin (CubeSat header pin H1.24) high.

The particular peripheral I was using to test is not important. The point is that my test code read a particular register on the device, which should (if successful) return the value 0x71. The address of the peripheral is 0x68. All transmissions follow the form
1. Start condition
2. Address of peripheral (0x68, write mode)
3. Address of register to be read (0x75)
4. Repeated start condition
5. Address of peripheral (0x68, read mode)
6. Value from peripheral (should be 0x71)
7. NACK and stop condition


Now, here is what I hope is a detailed and clear description of the issues I was coming across while I was testing. After testing my I2C code on another MSP430 (a G2553 - different board, but same family, so the code was almost identical except that I had to set an extra mode select register for the I2C pins) and finding that it works (so I am 99.8% certain it is not the issue), I tested the code on the CubeSat hardware in the following three setups.
1. Jumpers in labeled " 'F261x UCB0 " position (Left Left Left Right)
Peripheral plugged into primary I2C interface (UCB0): bus pins H1.41, H1.43
Software in primary I2C interface (UCB0)
Isolator enable pin: high
Hardware result: Everything looks good on oscilloscope, except that low voltage (on clock line, and when MSP430 is controlling data line) is consistently approx. 355mV. When peripheral is controlling data line, low is proper ground (approx. -35mV).
Software result: returns 0x20 - wrong

2. Jumpers in labeled " 'F261x UCB1 " position (Right Right Right Right)
Peripheral plugged into secondary I2C interface (UCB1) bus pins H1.6, H1.7, pulled up to VCC_SYS via 1.5kΩ resistors
Software in secondary I2C interface (UCB1)
Hardware result: All correct. Minor transients on lines that go to approx. -82mV.
Software result: returns 0x20 - wrong

3. Jumpers in labeled "'F261x UCB0 " position (Left Left Left Right)
Peripheral plugged into secondary I2C interface (UCB1): bus pins H1.6, H1.7, pulled up to VCC_SYS via 1.5kΩ resistors
Software in secondary I2C interface (UCB1)
Hardware result: All correct. Minor transients on lines that go to approx. -221mV.
Software result: returns 0x71 - correct!


So, the only configuration that actually works is running through UCB1, with the jumpers configured for UCB0, and that other configurations, while they seem to work ok (the peripheral ACKs things, and in fact responds with data), for some reason it produces incorrect data. Also, when configured for communication through UCB0 (both via the jumpers and in software), a low voltage on the development board is not consistently not proper ground, and it takes the peripheral to pull the voltage to proper ground during an ACK, or during transmission. I'm, well, very confused. I don't know if this is an issue with something I'm doing, or if there's a hardware mis-wiring that was there when we got the development board, or whether there is something broken.

Thank you in advance for your assistance.

John Walnut
Virginia CubeSat Constellation
University of Virginia
JWalnut
 
Posts: 1
Joined: Sat Dec 02, 2017 6:58 am

Re: Issue with UCB0 I2C on MSP430

Postby aek » Tue Dec 05, 2017 5:58 pm

Hi John.

1. The best way to help you resolve this issue is for you to refer to the schematics for the parts in question. In the download area you have access to, there is a tech section. The P/N on the board with the jumpers is 705-00506, so look for the 00506A.ZIP folder. That will contain schematics for that board.

2. While it's nice to see I2C signals on a 'scope, a good protocol analyzer is also invaluable in figuring out what is wrong. We recommend the Total Phase Beagle, but some others (e.g. Saelea (sp?), and built into certain scopes) is also useful.

3. JP4 selects whether P3.3 (1-2, Left) or P3.2 (2-3, Right) is the source for the MSP430's SCL. This addresses the fact that TI did a "hybrid I2C" on this chip, in terms of how the I2C peripheral pins out.

4. When JP1, JP2 and JP3 are connected 1-2 (Left), then the I2C flows in/out of the MSP430 and through a PCA9515A isolator.

5. When JP1, JP2 and JP3 are connected 2-3 (Right), then the I2C bypasses the PCA9515A isolator altogether and shows up directly on SCL_SYS and SDA_SYS.

What you are seeing is probably related to the PCA9515A isolator -- read up on its datasheet. It does some weird level-shifting and is not chainable. This is an important and subtle point.

If you have the freedom to run your (single) I2C any way you like, then the Right-Right-Right-Left/Right choice is the best, as it omits the isolator altogether, and presents unfiltered I2C onto SCL_SYS and SDA_SYS.
-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to CubeSat Electrical

Who is online

Users browsing this forum: No registered users and 1 guest

cron