Sign in
Search msp430
Subscribe to msp430
Ads
Discussion Groups
See Also
Discussion Groups | MSP430 | MSP430 to TMP102. Anyone done that?
The purpose of this group is to foster exchange of information on the Texas Instruments MSP430 family of microcontrollers and related tools. Everyone welcome, all levels of familiarity/expertise.
MSP430 to TMP102. Anyone done that? - James Newton - Jun 4 15:08:40 2009
We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code is producing
EXACTLY what the datasheet for the TMP102 says it needs, as evidenced by the screen shot
from the 'scope, but the chip is not ACKing the transmission.
It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
I can't figure out how to attach a picture to this... maybe I can email the picture directly?
We have contacted our TI support person, but haven't heard back yet.
Actually, I would really just love to hear from someone that they have made this chip work? It's probably just something stupid I'm doing, but knowing that is has been done by someone would increase my confidence that I will get it working eventually.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
I can't figure out how to attach a picture to this... maybe I can email the picture directly?
We have contacted our TI support person, but haven't heard back yet.
Actually, I would really just love to hear from someone that they have made this chip work? It's probably just something stupid I'm doing, but knowing that is has been done by someone would increase my confidence that I will get it working eventually.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - James Newton - Jun 4 18:06:22 2009
--- In m...@yahoogroups.com, "James Newton" wrote:
>
> We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code is producing EXACTLY what the datasheet for the TMP102 says it needs, as evidenced by the screen shot from the 'scope, but the chip is not ACKing the transmission.
>
> It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
>
> I can't figure out how to attach a picture to this... maybe I can email the picture directly?
I managed to figure out how to post a picture in the Photos section here... Its in a folder called TMP102 and it is the "... screen shot 1" photo. I would REALLY appreciate it if anyone could look at that photo and tell me if you see something that isn't correct about the first 8 clocks that would explain why the 9th clock isn't being ACK'd.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>
> We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code is producing EXACTLY what the datasheet for the TMP102 says it needs, as evidenced by the screen shot from the 'scope, but the chip is not ACKing the transmission.
>
> It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
>
> I can't figure out how to attach a picture to this... maybe I can email the picture directly?
I managed to figure out how to post a picture in the Photos section here... Its in a folder called TMP102 and it is the "... screen shot 1" photo. I would REALLY appreciate it if anyone could look at that photo and tell me if you see something that isn't correct about the first 8 clocks that would explain why the 9th clock isn't being ACK'd.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - Mike Baxter - Jun 4 18:19:05 2009
Hi James
=A0
We have been using the MSP430 to TMP102 chip for several years and had no p=
roblems.
I think your problem is you are not changing the direction of the output da=
ta line from an output to an input for the ACK to be seen.
=A0
The routine is as follows:
=A0
// Initialise the TMP102 temperature sensor chip with parameters
unsigned char Init_TMP102()
//-----------------------------------------------------------------
// Write a byte to the TMP102 temperature sensor chip=20
char TMP102_WriteByte(unsigned char Data_Byte)=20
// TMP102 Temperature sensor start pulse to initialise the chip
void TMP102_Start()=A0 =A0=A0=A0=A0=A0=A0
// After all the bytes are written or read from TMP102 this routine is call=
ed
void TMP102_Stop()
// Whenever a byte is written or read from TMP102 an ack is given by TMP102
char TMP102_Ack() =A0// If the input data line is low, it's an ack
=A0=A0=A0// If the input data is high it's not an ack
=A0=20
//----------------------------------------------------------------
// Read 2 data bytes from the TMP102 chip temperature registors
unsigned char TMP102_TempRead()=A0=A0 =A0
// TMP102 Temperature sensor start pulse to initialise the chip
void TMP102_Start()
// After all the bytes are written or read from TMP102 this routine is call=
ed
void TMP102_Stop()
// Whenever a byte is written or read from TMP102 an ack is given by TMP102
char TMP102_Ack() =A0// If the input data line is low, it's an ack
=A0=A0=A0// If the input data is high it's not an ack
=A0=A0=A0=20
Hope it helps.
Mike
--- On Thu, 6/4/09, James Newton wrote:
From: James Newton
Subject: [msp430] MSP430 to TMP102. Anyone done that?
To: m...@yahoogroups.com
Date: Thursday, June 4, 2009, 12:08 PM
We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code =
is producing EXACTLY what the datasheet for the TMP102 says it needs, as ev=
idenced by the screen shot from the 'scope, but the chip is not ACKing the =
transmission.=20
It may be that I'm not reading the scope waveforms correctly, so I would li=
ke to have someone who knows these signals look at it and tell me if that l=
ooks right.
I can't figure out how to attach a picture to this... maybe I can email the=
picture directly?
We have contacted our TI support person, but haven't heard back yet.
Actually, I would really just love to hear from someone that they have made=
this chip work? It's probably just something stupid I'm doing, but knowing=
that is has been done by someone would increase my confidence that I will =
get it working eventually.
=20=20=20=20=20=20
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
=A0
We have been using the MSP430 to TMP102 chip for several years and had no p=
roblems.
I think your problem is you are not changing the direction of the output da=
ta line from an output to an input for the ACK to be seen.
=A0
The routine is as follows:
=A0
// Initialise the TMP102 temperature sensor chip with parameters
unsigned char Init_TMP102()
//-----------------------------------------------------------------
// Write a byte to the TMP102 temperature sensor chip=20
char TMP102_WriteByte(unsigned char Data_Byte)=20
// TMP102 Temperature sensor start pulse to initialise the chip
void TMP102_Start()=A0 =A0=A0=A0=A0=A0=A0
// After all the bytes are written or read from TMP102 this routine is call=
ed
void TMP102_Stop()
// Whenever a byte is written or read from TMP102 an ack is given by TMP102
char TMP102_Ack() =A0// If the input data line is low, it's an ack
=A0=A0=A0// If the input data is high it's not an ack
=A0=20
//----------------------------------------------------------------
// Read 2 data bytes from the TMP102 chip temperature registors
unsigned char TMP102_TempRead()=A0=A0 =A0
// TMP102 Temperature sensor start pulse to initialise the chip
void TMP102_Start()
// After all the bytes are written or read from TMP102 this routine is call=
ed
void TMP102_Stop()
// Whenever a byte is written or read from TMP102 an ack is given by TMP102
char TMP102_Ack() =A0// If the input data line is low, it's an ack
=A0=A0=A0// If the input data is high it's not an ack
=A0=A0=A0=20
Hope it helps.
Mike
--- On Thu, 6/4/09, James Newton
From: James Newton
Subject: [msp430] MSP430 to TMP102. Anyone done that?
To: m...@yahoogroups.com
Date: Thursday, June 4, 2009, 12:08 PM
We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code =
is producing EXACTLY what the datasheet for the TMP102 says it needs, as ev=
idenced by the screen shot from the 'scope, but the chip is not ACKing the =
transmission.=20
It may be that I'm not reading the scope waveforms correctly, so I would li=
ke to have someone who knows these signals look at it and tell me if that l=
ooks right.
I can't figure out how to attach a picture to this... maybe I can email the=
picture directly?
We have contacted our TI support person, but haven't heard back yet.
Actually, I would really just love to hear from someone that they have made=
this chip work? It's probably just something stupid I'm doing, but knowing=
that is has been done by someone would increase my confidence that I will =
get it working eventually.
=20=20=20=20=20=20
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Re: MSP430 to TMP102. Anyone done that? - Jon Kirwan - Jun 4 18:48:27 2009
On Thu, 04 Jun 2009 22:05:11 -0000, you wrote:
>I managed to figure out how to post a picture in the Photos section
>here... Its in a folder called TMP102 and it is the "... screen shot
>1" photo. I would REALLY appreciate it if anyone could look at that
>photo and tell me if you see something that isn't correct about the
>first 8 clocks that would explain why the 9th clock isn't being
>ACK'd.
Can you take a moment and address yourself to Mike's earlier comment?
Namely:
>: We have been using the MSP430 to TMP102 chip for several years and
>: had no problems.
>: I think your problem is you are not changing the direction of the
>: output data line from an output to an input for the ACK to be seen.
In other words, is it possible that the ACK isn't appearing because
you are holding an output line active?
Jon
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>I managed to figure out how to post a picture in the Photos section
>here... Its in a folder called TMP102 and it is the "... screen shot
>1" photo. I would REALLY appreciate it if anyone could look at that
>photo and tell me if you see something that isn't correct about the
>first 8 clocks that would explain why the 9th clock isn't being
>ACK'd.
Can you take a moment and address yourself to Mike's earlier comment?
Namely:
>: We have been using the MSP430 to TMP102 chip for several years and
>: had no problems.
>: I think your problem is you are not changing the direction of the
>: output data line from an output to an input for the ACK to be seen.
In other words, is it possible that the ACK isn't appearing because
you are holding an output line active?
Jon
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - Dan Bloomquist - Jun 4 19:45:58 2009
James Newton wrote:
> We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code is producing EXACTLY what the datasheet for the TMP102 says it needs, as evidenced by the screen shot from the 'scope, but the chip is not ACKing the transmission.
>
> It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
>
> I can't figure out how to attach a picture to this... maybe I can email the picture directly?
>
> We have contacted our TI support person, but haven't heard back yet.
>
> Actually, I would really just love to hear from someone that they have made this chip work? It's probably just something stupid I'm doing, but knowing that is has been done by someone would increase my confidence that I will get it working eventually.
>
It sure looks like SDA is racing ahead of SCL high to low in all but the
first. How are you doing it? Expand it and make sure you never change
SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
is 100ns.
Best, Dan.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> We are using the MSP430F5437 via I2C on UCB1 to talk to a TMP102. The code is producing EXACTLY what the datasheet for the TMP102 says it needs, as evidenced by the screen shot from the 'scope, but the chip is not ACKing the transmission.
>
> It may be that I'm not reading the scope waveforms correctly, so I would like to have someone who knows these signals look at it and tell me if that looks right.
>
> I can't figure out how to attach a picture to this... maybe I can email the picture directly?
>
> We have contacted our TI support person, but haven't heard back yet.
>
> Actually, I would really just love to hear from someone that they have made this chip work? It's probably just something stupid I'm doing, but knowing that is has been done by someone would increase my confidence that I will get it working eventually.
>
It sure looks like SDA is racing ahead of SCL high to low in all but the
first. How are you doing it? Expand it and make sure you never change
SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
is 100ns.
Best, Dan.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - James Newton - Jun 4 21:19:47 2009
--- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
> It sure looks like SDA is racing ahead of SCL high to low in all but the
> first. How are you doing it? Expand it and make sure you never change
> SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
> is 100ns.
>
> Best, Dan.
>
Thanks for taking a look Dan. It may be hard to see in the uploaded photo, but SDA never changes while SCL is high. It does change very quickly after, but if you note the (ultra) low speed we are running (in the KHz) I'm pretty sure the SDA change is happening far enough after... I'll have to check that.
We are using the sample code from the MSP430 for I2C master to slave comms. The only changes were to move to B1 and clock from ACLK divided by 4 instead of the faster SMCLOCK divided by...er... 17 if I remember.
Humm... I wonder if we are running it to slow? Another thing I'll check.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>
> It sure looks like SDA is racing ahead of SCL high to low in all but the
> first. How are you doing it? Expand it and make sure you never change
> SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
> is 100ns.
>
> Best, Dan.
>
Thanks for taking a look Dan. It may be hard to see in the uploaded photo, but SDA never changes while SCL is high. It does change very quickly after, but if you note the (ultra) low speed we are running (in the KHz) I'm pretty sure the SDA change is happening far enough after... I'll have to check that.
We are using the sample code from the MSP430 for I2C master to slave comms. The only changes were to move to B1 and clock from ACLK divided by 4 instead of the faster SMCLOCK divided by...er... 17 if I remember.
Humm... I wonder if we are running it to slow? Another thing I'll check.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Re: MSP430 to TMP102. Anyone done that? - Dan Bloomquist - Jun 4 21:46:27 2009
James Newton wrote:
> --- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
>> It sure looks like SDA is racing ahead of SCL high to low in all but the
>> first. How are you doing it? Expand it and make sure you never change
>> SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
>> is 100ns.
>>
>> Best, Dan.
>>
>>
> Thanks for taking a look Dan. It may be hard to see in the uploaded photo, but SDA never changes while SCL is high. It does change very quickly after, but if you note the (ultra) low speed we are running (in the KHz) I'm pretty sure the SDA change is happening far enough after... I'll have to check that.
>
> We are using the sample code from the MSP430 for I2C master to slave comms. The only changes were to move to B1 and clock from ACLK divided by 4 instead of the faster SMCLOCK divided by...er... 17 if I remember.
>
> Humm... I wonder if we are running it to slow? Another thing I'll check.
>
Hi James,
I've found the TI code wanting for a slave. But you are doing a master.
I have bitbanged a master rather than use hardware.
If you are sure about the timing, you have a mystery. The only other
thing I can think of is you don't have a hard sink for the tmp102. I had
a problem with the DS1631 because of that. Going slow should not matter.
I have stepped commands to the DS1631 and eeproms that have taken a
minute or more. Timeouts on the I2C would not be in the millisecond
range even if there were one.
Best, Dan.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> --- In m...@yahoogroups.com, Dan Bloomquist
>
>> It sure looks like SDA is racing ahead of SCL high to low in all but the
>> first. How are you doing it? Expand it and make sure you never change
>> SDA while SCL is high. See the t(SUDAT) in the device spec, setup time
>> is 100ns.
>>
>> Best, Dan.
>>
>>
> Thanks for taking a look Dan. It may be hard to see in the uploaded photo, but SDA never changes while SCL is high. It does change very quickly after, but if you note the (ultra) low speed we are running (in the KHz) I'm pretty sure the SDA change is happening far enough after... I'll have to check that.
>
> We are using the sample code from the MSP430 for I2C master to slave comms. The only changes were to move to B1 and clock from ACLK divided by 4 instead of the faster SMCLOCK divided by...er... 17 if I remember.
>
> Humm... I wonder if we are running it to slow? Another thing I'll check.
>
Hi James,
I've found the TI code wanting for a slave. But you are doing a master.
I have bitbanged a master rather than use hardware.
If you are sure about the timing, you have a mystery. The only other
thing I can think of is you don't have a hard sink for the tmp102. I had
a problem with the DS1631 because of that. Going slow should not matter.
I have stepped commands to the DS1631 and eeproms that have taken a
minute or more. Timeouts on the I2C would not be in the millisecond
range even if there were one.
Best, Dan.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - James Newton - Jun 5 18:58:47 2009
--- In m...@yahoogroups.com, Jon Kirwan wrote:
>
> On Thu, 04 Jun 2009 22:05:11 -0000, you wrote:
>
> >I managed to figure out how to post a picture in the Photos section
> >here... Its in a folder called TMP102 and it is the "... screen shot
> >1" photo. I would REALLY appreciate it if anyone could look at that
> >photo and tell me if you see something that isn't correct about the
> >first 8 clocks that would explain why the 9th clock isn't being
> >ACK'd.
>
> Can you take a moment and address yourself to Mike's earlier comment?
> Namely:
>
> >: We have been using the MSP430 to TMP102 chip for several years and
> >: had no problems.
> >: I think your problem is you are not changing the direction of the
> >: output data line from an output to an input for the ACK to be seen.
>
> In other words, is it possible that the ACK isn't appearing because
> you are holding an output line active?
>
> Jon
>
Jon and Mike, thanks much for taking the time to post.
I'm not bit banging the I2C; the signals are being produced by the 430. I copied the code from the examples provided. The signals are comming from UCB1 in I2C mode. The SEL registers are set for the SCK and SDA pins, so I have no control over thier being inputs or outputs. If the output line is being held active, it's the fault of the MSP430...
Again, thanks for your input.
--
James.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>
> On Thu, 04 Jun 2009 22:05:11 -0000, you wrote:
>
> >I managed to figure out how to post a picture in the Photos section
> >here... Its in a folder called TMP102 and it is the "... screen shot
> >1" photo. I would REALLY appreciate it if anyone could look at that
> >photo and tell me if you see something that isn't correct about the
> >first 8 clocks that would explain why the 9th clock isn't being
> >ACK'd.
>
> Can you take a moment and address yourself to Mike's earlier comment?
> Namely:
>
> >: We have been using the MSP430 to TMP102 chip for several years and
> >: had no problems.
> >: I think your problem is you are not changing the direction of the
> >: output data line from an output to an input for the ACK to be seen.
>
> In other words, is it possible that the ACK isn't appearing because
> you are holding an output line active?
>
> Jon
>
Jon and Mike, thanks much for taking the time to post.
I'm not bit banging the I2C; the signals are being produced by the 430. I copied the code from the examples provided. The signals are comming from UCB1 in I2C mode. The SEL registers are set for the SCK and SDA pins, so I have no control over thier being inputs or outputs. If the output line is being held active, it's the fault of the MSP430...
Again, thanks for your input.
--
James.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
RE: Re: MSP430 to TMP102. Anyone done that? - "Redd, Emmett R" - Jun 5 19:07:17 2009
Please see below.
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA
"In theory there is no difference between theory and practice. In
practice there is." -- Yogi Berra or Jan van de Snepscheut
> -----Original Message-----
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]
> On Behalf Of James Newton
> Sent: Friday, June 05, 2009 5:58 PM
> To: m...@yahoogroups.com
> Subject: [msp430] Re: MSP430 to TMP102. Anyone done that?
>
I'm not bit banging the I2C; the signals are being produced
> by the 430. I copied the code from the examples provided. The
> signals are comming from UCB1 in I2C mode. The SEL registers
> are set for the SCK and SDA pins, so I have no control over
> thier being inputs or outputs. If the output line is being
> held active, it's the fault of the MSP430...
I'm sorry, but the MSP430 does not have free will. You are the
controlling god, either by writing software or the selection of tools
you use. Therefore, it cannot be the "fault of the MSP430." :-{
>
> Again, thanks for your input.
>
> --
> James.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA
"In theory there is no difference between theory and practice. In
practice there is." -- Yogi Berra or Jan van de Snepscheut
> -----Original Message-----
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]
> On Behalf Of James Newton
> Sent: Friday, June 05, 2009 5:58 PM
> To: m...@yahoogroups.com
> Subject: [msp430] Re: MSP430 to TMP102. Anyone done that?
>
> by the 430. I copied the code from the examples provided. The
> signals are comming from UCB1 in I2C mode. The SEL registers
> are set for the SCK and SDA pins, so I have no control over
> thier being inputs or outputs. If the output line is being
> held active, it's the fault of the MSP430...
I'm sorry, but the MSP430 does not have free will. You are the
controlling god, either by writing software or the selection of tools
you use. Therefore, it cannot be the "fault of the MSP430." :-{
>
> Again, thanks for your input.
>
> --
> James.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - James Newton - Jun 5 22:42:34 2009
--- In m...@yahoogroups.com, "Redd, Emmett R" wrote:
> > -----Original Message-----
> > James Newton said:
> > I'm not bit banging the I2C; the signals are being produced
> > by the 430. I copied the code from the examples provided. The
> > signals are comming from UCB1 in I2C mode. The SEL registers
> > are set for the SCK and SDA pins, so I have no control over
> > thier being inputs or outputs. If the output line is being
> > held active, it's the fault of the MSP430...
>
> I'm sorry, but the MSP430 does not have free will. You are the
> controlling god, either by writing software or the selection of tools
> you use. Therefore, it cannot be the "fault of the MSP430." :-{
>
Thanks for your time Emmett.
Could you possibly give me an example of how the UCB1 module in the MSP430F5xxx could be configured to:
A) give the signals shown in the screen shot I uploaded
B) put out I2C clock, data to send an address while the main code in the chip is asleep, and yet
C) NOT let the SDA line float when it was time for an ACK?
I'm trying to imagine how that could even be possible. If the UC module is configured (as per the example code) to be in I2C mode, 7 bit address, with an address of 0x48, and done correctly enough that it puts out all the signals seen in the capture... how the heck could it NOT float the SDA line when it needs to be looking for an ACK?
I'm going to regret this, but here is the code, or most of it: As you can see, it's mostly copied from the example code, with a couple of macros to make ports and pins easier to re-assign... *sigh* I guess people will freak out about the macros.. They DO work, I've been using macros like that for years now.
#define PortReg(x,reg) P ## x ## reg
#define PnR(x,reg) PortReg(x, reg ## )
//call with a port number and the name of port control register. E.g.
// #define 232Port 3
// #define 232TX BIT3
// PnR(232Port,SEL) |= 232TX;
// actually generates P3SEL |= BIT3;
// the advantage is that the port number and pin can be defined at the
// start of the code rather than hardcoded throughout.
#define UCReg(x,reg) UC ## x ## reg
#define UCnR(x,reg) UCReg(x, reg ## )
#define TMP102UC B1
#define TMP102DataPort 3
#define TMP102DataPin BIT7
#define TMP102ClkPort 5
#define TMP102ClkPin BIT4
#define TMP102AlertPort 2
#define TMP102AlertPin BIT2
#pragma vector = USCI_B1_VECTOR
__interrupt void USCI_B1_ISR(void)
{
switch(__even_in_range(UCB1IV,12))
{
case 0: break; // Vector 0: No interrupts
case 2: break; // Vector 2: ALIFG
case 4: // Vector 4: NACKIFG
__no_operation(); // For debugger
break;
case 6: break; // Vector 6: STTIFG
case 8: break; // Vector 8: STPIFG
case 10: break; // Vector 10: RXIFG
case 12: // Vector 12: TXIFG
if (I2CBufLen) // Check TX byte counter
{
UCB1TXBUF = *I2CBufPtr++; // Load TX buffer
I2CBufLen--; // Decrement TX byte counter
}
else
{
UCB1CTL1 |= UCTXSTP; // I2C stop condition
UCB1IFG &= ~UCTXIFG; // Clear TX int flag
// __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
}
default: break;
}
}
//in main():
PnR(TMP102DataPort,SEL) |= TMP102DataPin;
//this macro produces "P3SEL |= 0x10;"... really, I checked.
PnR(TMP102ClkPort,SEL) |= TMP102ClkPin;
//I have verified that P3.7 and p5.4 SEL bits are set. At that point,
//UCB1 is in control of those pins, NOT ME.
UCnR(TMP102UC,CTL1) |= UCSWRST; // Enable SW reset
UCnR(TMP102UC,CTL0) = 0 // I2C Master, synchronous mode
| UCSYNC // Synchronous
// | UCMODE_0 // 3 pin SPI (default) Use only one mode line here.
// | UCMODE_1 // 4 pin SPI STE is /HOLD (active high)
// | UCMODE_2 // 4 pin SPI STE is /EN (active LOW)
| UCMODE_3 // I2C mode
| UCMST // Master
// | UCMM // Multi-Master
// | UCSLA10 // Slave address is 10 bits (vs 7 bits)
// | UCA10 // Own address is 10 bits (vs 7 bits),
;
// *sigh* please don't freak out about the C syntax here... this is
// perfectly legal C code. The lines that are commented out at the left
// are simply skipped over by the compiler when building up the value
// for the UCB1CLT0 register. I have verified that UCB1CLT0 is in
// syncronus, mode 3 (I2C), single master, 7 bit address.
UCnR(TMP102UC,CTL1) = 0 // Use SMCLK, keep SW reset
| UCSWRST // Hold in reset state
// | UCSSEL_0 // UCLKI
| UCSSEL_1 // ACLK
// | UCSSEL_2 // SMCLK
;
UCnR(TMP102UC,BR0) = 12; // slow
UCnR(TMP102UC,BR1) = 0;
UCnR(TMP102UC,I2CSA) = 0x48; // Slave Address
UCnR(TMP102UC,CTL1) &= ~UCSWRST; // Clear SW reset, resume operation
UCnR(TMP102UC,IE) |= UCTXIE; // Enable TX interrupt
// Now, given this configuration, or ANY configuration that would
// produce the wave forms I posted from the 'scope screen shot,
// how can the MSP430 UCB1 module possible be driving SDA at the
// point when the ACK is expected?
//send data
I2CBuf[0]=0x01; //address the config register
I2CBuf[1]=0 // Configuration register Byte 1
// | BIT0 // Shut down mode
// | BIT1 // Themostat mode
// | BIT2 // Polarity of alert pin output is active high vs low
// | (0<<3) // Alert after 1 reading outside of limits.
// | (1<<3) // Alert after 2 readings outside of limits.
// | (2<<3) // Alert after 4 readings outside of limits.
// | (3<<3) // Alert after 8 readings outside of limits.
;
I2CBuf[2]=0 // Configuration register Byte 2
| BIT4 // Extended mode 13 bit data vs 12
// | (0<<6) // Conversion rate is 0.25Hz
| (1<<6) // Conversion rate is 1Hz
// | (2<<6) // Conversion rate is 4Hz (default)
// | (3<<6) // Conversion rate is 8Hz
;
// I2CBuf[]=0x; //
I2CBufLen = 3;
UCnR(TMP102UC,CTL1) |= UCTR | UCTXSTT; // I2C TX, start condition
__no_operation(); //should be sending address now.
//we never get past this next line, as the ACK is not recieved.
while (UCnR(TMP102UC,CTL1) & UCTXSTT) //wait for Address ACK.
__no_operation(); //should be sending commands now.
while (I2CBufLen //wait until all the characters are sent
|| (UCnR(TMP102UC,CTL1) & UCTXSTP) // Ensure stop condition got sent
);
Again, I don't think the code really matters: The UCB1 module couldn't be configured in a way that would produce those signals and still be driving SDA at the point of the ACK.
I guess we could try reversing the pull up resistor and check the scope again to see if the pin follows the pull...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> > -----Original Message-----
> > James Newton said:
> > I'm not bit banging the I2C; the signals are being produced
> > by the 430. I copied the code from the examples provided. The
> > signals are comming from UCB1 in I2C mode. The SEL registers
> > are set for the SCK and SDA pins, so I have no control over
> > thier being inputs or outputs. If the output line is being
> > held active, it's the fault of the MSP430...
>
> I'm sorry, but the MSP430 does not have free will. You are the
> controlling god, either by writing software or the selection of tools
> you use. Therefore, it cannot be the "fault of the MSP430." :-{
>
Thanks for your time Emmett.
Could you possibly give me an example of how the UCB1 module in the MSP430F5xxx could be configured to:
A) give the signals shown in the screen shot I uploaded
B) put out I2C clock, data to send an address while the main code in the chip is asleep, and yet
C) NOT let the SDA line float when it was time for an ACK?
I'm trying to imagine how that could even be possible. If the UC module is configured (as per the example code) to be in I2C mode, 7 bit address, with an address of 0x48, and done correctly enough that it puts out all the signals seen in the capture... how the heck could it NOT float the SDA line when it needs to be looking for an ACK?
I'm going to regret this, but here is the code, or most of it: As you can see, it's mostly copied from the example code, with a couple of macros to make ports and pins easier to re-assign... *sigh* I guess people will freak out about the macros.. They DO work, I've been using macros like that for years now.
#define PortReg(x,reg) P ## x ## reg
#define PnR(x,reg) PortReg(x, reg ## )
//call with a port number and the name of port control register. E.g.
// #define 232Port 3
// #define 232TX BIT3
// PnR(232Port,SEL) |= 232TX;
// actually generates P3SEL |= BIT3;
// the advantage is that the port number and pin can be defined at the
// start of the code rather than hardcoded throughout.
#define UCReg(x,reg) UC ## x ## reg
#define UCnR(x,reg) UCReg(x, reg ## )
#define TMP102UC B1
#define TMP102DataPort 3
#define TMP102DataPin BIT7
#define TMP102ClkPort 5
#define TMP102ClkPin BIT4
#define TMP102AlertPort 2
#define TMP102AlertPin BIT2
#pragma vector = USCI_B1_VECTOR
__interrupt void USCI_B1_ISR(void)
{
switch(__even_in_range(UCB1IV,12))
{
case 0: break; // Vector 0: No interrupts
case 2: break; // Vector 2: ALIFG
case 4: // Vector 4: NACKIFG
__no_operation(); // For debugger
break;
case 6: break; // Vector 6: STTIFG
case 8: break; // Vector 8: STPIFG
case 10: break; // Vector 10: RXIFG
case 12: // Vector 12: TXIFG
if (I2CBufLen) // Check TX byte counter
{
UCB1TXBUF = *I2CBufPtr++; // Load TX buffer
I2CBufLen--; // Decrement TX byte counter
}
else
{
UCB1CTL1 |= UCTXSTP; // I2C stop condition
UCB1IFG &= ~UCTXIFG; // Clear TX int flag
// __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
}
default: break;
}
}
//in main():
PnR(TMP102DataPort,SEL) |= TMP102DataPin;
//this macro produces "P3SEL |= 0x10;"... really, I checked.
PnR(TMP102ClkPort,SEL) |= TMP102ClkPin;
//I have verified that P3.7 and p5.4 SEL bits are set. At that point,
//UCB1 is in control of those pins, NOT ME.
UCnR(TMP102UC,CTL1) |= UCSWRST; // Enable SW reset
UCnR(TMP102UC,CTL0) = 0 // I2C Master, synchronous mode
| UCSYNC // Synchronous
// | UCMODE_0 // 3 pin SPI (default) Use only one mode line here.
// | UCMODE_1 // 4 pin SPI STE is /HOLD (active high)
// | UCMODE_2 // 4 pin SPI STE is /EN (active LOW)
| UCMODE_3 // I2C mode
| UCMST // Master
// | UCMM // Multi-Master
// | UCSLA10 // Slave address is 10 bits (vs 7 bits)
// | UCA10 // Own address is 10 bits (vs 7 bits),
;
// *sigh* please don't freak out about the C syntax here... this is
// perfectly legal C code. The lines that are commented out at the left
// are simply skipped over by the compiler when building up the value
// for the UCB1CLT0 register. I have verified that UCB1CLT0 is in
// syncronus, mode 3 (I2C), single master, 7 bit address.
UCnR(TMP102UC,CTL1) = 0 // Use SMCLK, keep SW reset
| UCSWRST // Hold in reset state
// | UCSSEL_0 // UCLKI
| UCSSEL_1 // ACLK
// | UCSSEL_2 // SMCLK
;
UCnR(TMP102UC,BR0) = 12; // slow
UCnR(TMP102UC,BR1) = 0;
UCnR(TMP102UC,I2CSA) = 0x48; // Slave Address
UCnR(TMP102UC,CTL1) &= ~UCSWRST; // Clear SW reset, resume operation
UCnR(TMP102UC,IE) |= UCTXIE; // Enable TX interrupt
// Now, given this configuration, or ANY configuration that would
// produce the wave forms I posted from the 'scope screen shot,
// how can the MSP430 UCB1 module possible be driving SDA at the
// point when the ACK is expected?
//send data
I2CBuf[0]=0x01; //address the config register
I2CBuf[1]=0 // Configuration register Byte 1
// | BIT0 // Shut down mode
// | BIT1 // Themostat mode
// | BIT2 // Polarity of alert pin output is active high vs low
// | (0<<3) // Alert after 1 reading outside of limits.
// | (1<<3) // Alert after 2 readings outside of limits.
// | (2<<3) // Alert after 4 readings outside of limits.
// | (3<<3) // Alert after 8 readings outside of limits.
;
I2CBuf[2]=0 // Configuration register Byte 2
| BIT4 // Extended mode 13 bit data vs 12
// | (0<<6) // Conversion rate is 0.25Hz
| (1<<6) // Conversion rate is 1Hz
// | (2<<6) // Conversion rate is 4Hz (default)
// | (3<<6) // Conversion rate is 8Hz
;
// I2CBuf[]=0x; //
I2CBufLen = 3;
UCnR(TMP102UC,CTL1) |= UCTR | UCTXSTT; // I2C TX, start condition
__no_operation(); //should be sending address now.
//we never get past this next line, as the ACK is not recieved.
while (UCnR(TMP102UC,CTL1) & UCTXSTT) //wait for Address ACK.
__no_operation(); //should be sending commands now.
while (I2CBufLen //wait until all the characters are sent
|| (UCnR(TMP102UC,CTL1) & UCTXSTP) // Ensure stop condition got sent
);
Again, I don't think the code really matters: The UCB1 module couldn't be configured in a way that would produce those signals and still be driving SDA at the point of the ACK.
I guess we could try reversing the pull up resistor and check the scope again to see if the pin follows the pull...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430 to TMP102. Anyone done that? - James Newton - Jun 5 22:45:09 2009
--- In m...@yahoogroups.com, Dan Bloomquist wrote:
> Hi James,
> I've found the TI code wanting for a slave. But you are doing a master.
> I have bitbanged a master rather than use hardware.
> If you are sure about the timing, you have a
mystery. The only other
> thing I can think of is you don't have a hard sink for the tmp102. I had
> a problem with the DS1631 because of that. Going slow should not matter.
> I have stepped commands to the DS1631 and eeproms that have taken a
> minute or more. Timeouts on the I2C would not be in the millisecond
> range even if there were one.
>
> Best, Dan.
>
Thanks so much again Dan, I really appreciate your time on this.
If we have to, we will bit bang the code, but the application wants to be doing other things at the same time and with lower power if at all possible.
Pardon my lack of electronics knowledge but could you explain what you mean by a "hard sink"?
Again, thanks so much for your time and especially for sharing your code.
--
James.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> Hi James,
> I've found the TI code wanting for a slave. But you are doing a master.
> I have bitbanged a master rather than use hardware.
>
> thing I can think of is you don't have a hard sink for the tmp102. I had
> a problem with the DS1631 because of that. Going slow should not matter.
> I have stepped commands to the DS1631 and eeproms that have taken a
> minute or more. Timeouts on the I2C would not be in the millisecond
> range even if there were one.
>
> Best, Dan.
>
Thanks so much again Dan, I really appreciate your time on this.
If we have to, we will bit bang the code, but the application wants to be doing other things at the same time and with lower power if at all possible.
Pardon my lack of electronics knowledge but could you explain what you mean by a "hard sink"?
Again, thanks so much for your time and especially for sharing your code.
--
James.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Re: MSP430 to TMP102. Anyone done that? - Dan Bloomquist - Jun 6 14:54:55 2009
James Newton wrote:
> Thanks so much again Dan, I really appreciate your time on this.
>
You are welcome. Many here helped me get going. And I'm sure I'm not
done with the head scratchers.
> If we have to, we will bit bang the code, but the application wants to be doing other things at the same time and with lower power if at all possible.
>
A couple of things. While moving data on the I2C you will be sinking
more current than a sleepy processor would ever save. I have delays that
are almost unnecessary. A 1mhz MCLK and full speed I2C and you would not
need them. One beauty of a synchronous buss is you can leave it for as
long as you want and pick it up latter. This code can be called in the
main loop and interrupted continuously. As a master, there is no real
point in responding to a signal like 'done'. So, simpler code as you
don't have to flag and come out of LPM that won't really save power.
Will you have time critical stuff in the tens of microseconds in the
main loop or need to move I2C data in a time critical manor? Yea, you
can save some uP time and do the com with hardware. But I think if you
don't really need to, why bother. You still have the DIR overhead for
ACK. So far as I can see, 'having' to do an I2C master in hardware
should be almost non existent.
> Pardon my lack of electronics knowledge but could you explain what you mean by a "hard sink"?
>
I thought I would be clever and turn on the internal resistor for pull
up, but left it on for sink. The scope didn't show a problem other than
a lazy fall time. As it worked with the eeprom but not the temp device,
it threw me. With the code I've posted you only need a pullup on SDA. Or
modify the code to switch REN on for input, if you have one.
Best, Dan.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
> Thanks so much again Dan, I really appreciate your time on this.
>
You are welcome. Many here helped me get going. And I'm sure I'm not
done with the head scratchers.
> If we have to, we will bit bang the code, but the application wants to be doing other things at the same time and with lower power if at all possible.
>
A couple of things. While moving data on the I2C you will be sinking
more current than a sleepy processor would ever save. I have delays that
are almost unnecessary. A 1mhz MCLK and full speed I2C and you would not
need them. One beauty of a synchronous buss is you can leave it for as
long as you want and pick it up latter. This code can be called in the
main loop and interrupted continuously. As a master, there is no real
point in responding to a signal like 'done'. So, simpler code as you
don't have to flag and come out of LPM that won't really save power.
Will you have time critical stuff in the tens of microseconds in the
main loop or need to move I2C data in a time critical manor? Yea, you
can save some uP time and do the com with hardware. But I think if you
don't really need to, why bother. You still have the DIR overhead for
ACK. So far as I can see, 'having' to do an I2C master in hardware
should be almost non existent.
> Pardon my lack of electronics knowledge but could you explain what you mean by a "hard sink"?
>
I thought I would be clever and turn on the internal resistor for pull
up, but left it on for sink. The scope didn't show a problem other than
a lazy fall time. As it worked with the eeprom but not the temp device,
it threw me. With the code I've posted you only need a pullup on SDA. Or
modify the code to switch REN on for input, if you have one.
Best, Dan.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )