Epic/MSP430 - I2C Issue after using SPI

[GoogleCodeExporter]

What steps will reproduce the problem?

Try to use I2C after using the SPI0 module on the TI MSP430.

In TinyOS:
call HplUsart.enableSpi();      // Usart0
call HplUsart.disableSpi();
call HplI2C.setModeI2C();

What is the expected output? What do you see instead?
I2C commands should work. Instead, with a write() the address is sent 
correctly, but the actual data isn't put on the wires. The I2C write() never 
finishes and doesn't signal writeDone().

What version of the product are you using? On what operating system?
Latest SVN on Ubuntu.

Please provide any additional information below.
The fix I found was to clear the I2CTCTL by setting it to 0x01 before 
configuring it properly. I don't think it has to be 0x01, necessarily, but I 
don't think just any value will work. I could not find this in the MSP430 
documentation or the errata sheet.

$ svn diff HplMsp430I2C0P.nc 
Index: HplMsp430I2C0P.nc
===================================================================
--- HplMsp430I2C0P.nc   (revision 5326)
+++ HplMsp430I2C0P.nc   (working copy)
@@ -81,6 +81,8 @@
       U0CTL &= ~I2CEN;

       U0CTL = (config->i2cRegisters.uctl | (I2C | SYNC)) & ~I2CEN;
+      I2CTCTL = 0x01;  // resetting I2CTCTL first,
+                       // before configuring it,
+                       // for some reason causes the I2C module to +           
            // work after SPI has been used
       I2CTCTL = config->i2cRegisters.i2ctctl;
       I2CPSC = config->i2cRegisters.i2cpsc;

Original issue reported on code.google.com by brad...@gmail.com on 4 Feb 2011 at 6:09

[GoogleCodeExporter]

Original comment by philip.l...@gmail.com on 15 Feb 2011 at 6:23

• Changed state: Started

[GoogleCodeExporter]

Hi,

Can you provide a bit more info on the platform that you are using, i.e. which 
epoc core design and what devices are attached to the port? Switching between 
SPI and I2C has always been very tricky on the 1611, and the errata is full 
with I2C issues. 

If the I2CEN was not disabled, your proposed change would effectively send a 
START condition. Did you check if the I2CSTT is indeed the culprit? I.e. did 
all successful modifications of I2CTCTL include a set I2CSTT? I wonder if this 
is again some timing issue or the internal I2C state machine somehow gets 
confused by the previous SPI signaling...

Vlado

Original comment by vlado.handziski on 16 Feb 2011 at 2:18

[GoogleCodeExporter]

No problem. The Epic core version I'm using is the 11-28-2007 version that has 
the flash and radio on the same bus. The only I2C device on the I2C bus is my 
light sensor, a Rohm BH1721FVC. I'm using a new board that I created, and I 
have attached the schematic.

I know that setting I2CTCTL to the particular value 0x01 isn't required, and 
that that value wasn't chosen because of the I2CSTT bit. I believe writing 0x00 
will work. I tried some variations to determine if the value mattered, and I 
think I found some that didn't work (closer to 0xFF), but I didn't try too 
hard. After looking at the errata sheet it does seem that just writing I2CTCTL 
resets the I2C state machine which takes care of the problem, but I don't know 
for sure.

Brad

PS. The origin of writing 0x01 is because the U0TCTL register is reset to 0x01, 
and I found the U0TCTL register as the problem before I realized it was the 
same as I2CTCTL.

Original comment by brad...@gmail.com on 17 Feb 2011 at 11:48

Attachments:

• hemera_C.pdf

[GoogleCodeExporter]

Patch applied as temp. fix in rev 5508. I still can not recreate the problem on 
my hw though.

Vlado

Original comment by vlado.handziski on 12 Mar 2011 at 12:40

• Changed state: Fixed

[GoogleCodeExporter]

Since I had this issue I've made more of the hemera boards and some have this 
problem and some don't. I have no idea why.

Original comment by brad...@gmail.com on 12 Aug 2011 at 8:07