Page 1 of 1

Issues with CSK /MSP430 and I2C

PostPosted: Mon Aug 19, 2013 4:53 pm
by aek
Recently, some CubeSat Kit users with MSP430-based PPMs have encountered problems talking to certain I2C devices, notably items from ISIS (like the AntS antenna). The reported problems often look like this:
We have a PUMPKIN DB, a 1U EPS by Clyde, a MSP430 OBC and a ISIS radio. We are unable to make the OBC control the radio because the I2C clock and Data from the OBC do not reach the I2C lines of the radio.

This post addresses why this happens, and how to solve the problem. This particular exchange between Pumpkin and a CubeSat Kit user revolved around PPM A3.

1. First, you should try to communicate with the RTC on the Dev Board via I2C. There should not be any issues with this I2C communications between PPM Ax and the RTC.

2. The ISIS AntS antenna (and other ISIS CubeSat modules) uses a PCA9515A I2C isolator. If you consult the PCA9515A datasheet, you will see that it cannot be used "in series" with another PCA9515A. Your problem is that when using UCB0 on the MSP430F2618 on the Dev Board (and on the PPM A3), your I2C is passing through a PCA9515A (U5) as well as a PCA9515A on the ISIS transceiver. That will (never) work.

3. The solution is to switch to the MSP430F2618's UCB1. On the Pumpkin TS430PM64 Adapter board, see the silkscreen legend "I2C Config" and set the jumpers JP1-JP4 to the setting for 'F261x UCB1. This will connect UCB1 to SCL_SYS and SDA_SYS, without a PCA9515A in the signal chain, and will solve your problem.

When you use UCB0 on the CubeSat Kit /MSP430, you have Master (PPM Ax) <-> PCA9515A (PPM Ax (Master)) <-> PCA9515A (ISIS (Slave)) <-> Slave (ISIS), and that will not work.

So, when using PCA9515As, only the I2C Slaves can have the PCA9515A, i.e. Master <-> PCA9515A (Slave) <-> Slave. This is done with PPM A3 by choosing UCB1, and using jumper settings JP1-JP4 on the MSP-TS430PM64 Adapter (705-00506A) and by the change of resistors R4-R9 on PPM A3 (see schematic 00378B-2.PDF).

Note that this problem cannot be solved with PPM A1 (MSP430F1611) or PPM A2 (MSP430F1612), because of the different way that I2C is implemented on those processors. Customers with CubeSat Kits that have PPM A1 or PPM A2 must upgrade their PPMs to PPM A3.

Re: Issues with CSK /MSP430 and I2C

PostPosted: Wed Mar 19, 2014 4:51 pm
by Andrew
IMPORTANT NOTICE

We have discovered in-house that the jumper settings on the TS430PM64 Adapter board (used with the Development Board) are inadequate to isolate the (unused) PCA9515A from the main I2C bus (SDA_SYS & SCL_SYS) when the jumper settings for JP1-JP4 select 'F261x UCB1.

Customers should remove U5 (the PCA9515A) and resistors R6 and R7 when using an MSP430F2618 and its second I2C module (UCB1).

The reason for this modification is as follows: The ENABLE pin on a PCA9515A should only be changed when the I2C bus is in an idle state. This is not a problem when the MSP430 (either '16x or '261x) is the I2C Master and its I2C signals are passing through the PCA9515A (i.e., the first or second listed I2C configs on the TS430PM64 Adapter). However, when hen using UCB1:I2C on the '2618, while the PCA9515A remains unpowered, its enable pin is going up and down based (typically) on the activities of the SD Card and the I2C bus is knocking on its SCL1 and SDA1 pins. The fact that it is unpowered is apparently not enough to actually keep it off the I2C bus -- it is likely bleeding a small amount of power via the two resistors R6 and R7, and staying alive. In fact, the typical voltage on the PCA9515A's (unpowered) VCC pin is 1.7V. The net result is that it is entirely possible that the PCA9515A's EN pin may change during an I2C active bus read or write. even though the host '2618's signals are no longer passing through the PCA9515A. This may lead to an I2C bus conflict, that can only be resolved by power-cycling the PCA9515A (which means power-cycling The CubeSat Kit's +5V_SYS, the source for VCC coming off PPM Ax). Customers can appreciate this by reviewing the schematics for PCB 705-00506A.

Please note that this problem applies only to the the TS430PM64 Adapter board when used with an MSP430F1611|F1612|F2618. The PPM Ax are not affected, as it is already required that the PCA9515A and its two pull-up resistors be removed on PPM A3 when the '2618's UCB1:I2C is used (see chart in PCB 705-00378x schematics).

We apologize for any problems this may have caused. We first saw this in long-term testing in a system with the '2618, utilizing UCB1:I2C, and a GPSRM 1 GPS receiver (which isolates itself from the I2C bus via its own PCA9515A). It is likely that the PCA9515A on the TS430PM64 Adapter board was locking up, thereby causing a conflict on the I2C bus.