Hi,
OT because I don't think this is an MSP430 issue. I'm just hoping
someone has seen something like this.

I'm creating a datalogger with the MSP430. It will present itself to the
world as an I2C slave, I've posted the code before.

A couple of days ago I sat down and wrote a bitbang I2C master so I
could use a 24LCxx(EEPROM) to store data. That went well. I could write
16 bytes at a time, reset the memory counter, and read back the data.
So, I figured it would be a piece of cake to add a Dallas DS1631(I2C
Thermometer) to the local bus. I can't get an ack from the control word
to save my life. Both chips use the same plain I2C protocol and the
timing on the EEPROM is much tougher than the thermometer.

http://lakeweb.com/images/dl_scope.jpg
Left is the EEPROM and right is the thermometer.

I bought a tube of 25 of the Dallas chips on ebay. Now I'm wondering if
they may have been rejects even if they were never soldered soics. The
EEPROM, 24LC16, was lifted off an old receiver board. I've worked with
the EEPROM pulled from the circuit so there would be no question there.
I've tried two of the Dallas chips now.

Here is my code if it matters. Definitely not cleaned up.
http://lakeweb.com/test/main.c

EEPROM on the desk:
http://lakeweb.net/MSP430/msp430_dl1.jpg

Thanks, Dan.

--
email: y...@lakeweb.net but drop the 'x'.
Start a New Thread

I would suggest that you try to conform more closely to the bus idle
state recommendations, since from your 'scope traces it is clear that
the SDA and SCL signals were not left high after the preceding "stop"
command (or first startup of the code). Neither SDA nor SCL should go
low until a "start" is actually required, "when the bus is idle, both
SDA and SCL must remain in a logic-high state." Some i2c devices
tolerate this, others might receive a miss-aligned address. I assume
of course, that the hardware address line inputs (A0-2) are tied low,
which leaves just the i2c address decode (assuming the chip is not faulty).

From the data sheet (I'm sure you already know this, just fyi of
other readers):
Bus Idle or Not Busy: Both SDA and SCL remain high. SDA is held high
by a pull-up resistor when the bus is idle, and SCL must either be
forced high by the master (if the SCL output is push-pull) or pulled
high by a pull-up resistor (if the SCL output is open-drain).

Hugh

At 09:38 AM 1/8/2009, you wrote:

Hi,
OT because I don't think this is an MSP430 issue. I'm just hoping
someone has seen something like this.

I'm creating a datalogger with the MSP430. It will present itself to the
world as an I2C slave, I've posted the code before.

A couple of days ago I sat down and wrote a bitbang I2C master so I
could use a 24LCxx(EEPROM) to store data. That went well. I could write
16 bytes at a time, reset the memory counter, and read back the data.
So, I figured it would be a piece of cake to add a Dallas DS1631(I2C
Thermometer) to the local bus. I can't get an ack from the control word
to save my life. Both chips use the same plain I2C protocol and the
timing on the EEPROM is much tougher than the thermometer.

http://lakeweb.com/images/dl_scope.jpg
Left is the EEPROM and right is the thermometer.

I bought a tube of 25 of the Dallas chips on ebay. Now I'm wondering if
they may have been rejects even if they were never soldered soics. The
EEPROM, 24LC16, was lifted off an old receiver board. I've worked with
the EEPROM pulled from the circuit so there would be no question there.
I've tried two of the Dallas chips now.

Here is my code if it matters. Definitely not cleaned up.
http://lakeweb.com/test/main.c

EEPROM on the desk:
http://lakeweb.net/MSP430/msp430_dl1.jpg

Thanks, Dan.

--
email: y...@lakeweb.net but drop the 'x'.

Start a New Thread

Hugh Molesworth wrote:
> I would suggest that you try to conform more closely to the bus idle
> state recommendations, since from your 'scope traces it is clear that
> the SDA and SCL signals were not left high after the preceding "stop"
> command (or first startup of the code). Neither SDA nor SCL should go
> low until a "start" is actually required, "when the bus is idle, both
> SDA and SCL must remain in a logic-high state." Some i2c devices
> tolerate this, others might receive a miss-aligned address. I assume
> of course, that the hardware address line inputs (A0-2) are tied low,
> which leaves just the i2c address decode (assuming the chip is not faulty).
>
> From the data sheet (I'm sure you already know this, just fyi of
> other readers):
> Bus Idle or Not Busy: Both SDA and SCL remain high. SDA is held high
> by a pull-up resistor when the bus is idle, and SCL must either be
> forced high by the master (if the SCL output is push-pull) or pulled
> high by a pull-up resistor (if the SCL output is open-drain).
>

Hi Hugh,
Thanks.

Yes, the begging low to high on both lines is start up after a MSP430
reset. I'm using the internal MSP430 resistors. Tbuf is the bus free
time spec for the thermometer and is 1.6us. I'm leading by almost 250us.
Now it may be that the thermometer may be in a state that does not
respect a start condition, but I think that would be very unlikely.

(time goes by...)

So I figured, add a couple of pull up resistors in addition to REN
enabled so the lines would stay high from startup.

8.2.4 Pullup/Pulldown Resistor Enable Registers PxREN
Each bit in each PxREN register enables or disables the pullup/pulldown
resistor of the corresponding I/O pin. The corresponding bit in the PxOUT
register selects if the pin is pulled up or pulled down.

So what I found is that the outputs are disabled when you enable the
resistors!

And of course, this makes sense if they are controlled by PxOUT. It
appears I could get away with driving the EEPROM with resistors, but not
the thermometer. When I commented:

//I2C_MASTER_REN|= IC2_MASTER_SCL | I2C_MASTER_SDA;

And used my own pullups I started getting acks from the thermometer!!!!!

Head slap, duh, and I won't forget this lesson!!! Using external
resistors will be cheaper than trying to maintain the internals through
software for me.

Thanks again, Dan.

--
email: y...@lakeweb.net but drop the 'x'.
Start a New Thread