Hi all,
I've been trying to use the MSP430F5438 on a TI devkit to communicate with
a couple I2C devices (only one on the bus at a time). One device is a Microchip
EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the
transactions are never ACKd. I do get a NAK though. I'm using port 2 but
have tried port 1 as well - i.e. am using the I2C internal functions of the
MSP430.
There are pullups on the bus, it's point-to-point, voltages are good, logic
analyzer interprets the I2C protocol and everything looks fine (address sent
correctly, etc.), I've tried various speeds from very slow to a little over
100kbps. The device just won't ACK the transaction. Is the TI
implementation not quite standard?
Any suggestions that would help figure this out would be much appreciated.
James.
I2C troubles
Started by ●December 3, 2009
Reply by ●December 4, 20092009-12-04
Ok, I'll ask the question another way - for those of you that have used I2C
on the MSP430, would you be willing to share the relevant bits of code and
perhaps describe the schematic you used?
Thanks.
James.
On 2009-12-02, at 9:20 AM, James Watt wrote:
> Hi all,
>
> I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
>
> There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
>
> Any suggestions that would help figure this out would be much appreciated.
> James.
>
Thanks.
James.
On 2009-12-02, at 9:20 AM, James Watt wrote:
> Hi all,
>
> I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
>
> There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
>
> Any suggestions that would help figure this out would be much appreciated.
> James.
>
Reply by ●December 4, 20092009-12-04
Look closely at the address. It is skewed one bit when you load it into the
MSP430 register.
--- In m..., James Watt wrote:
>
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
> Thanks.
> James.
> On 2009-12-02, at 9:20 AM, James Watt wrote:
>
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
>
--- In m..., James Watt wrote:
>
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
> Thanks.
> James.
> On 2009-12-02, at 9:20 AM, James Watt wrote:
>
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
>
Reply by ●December 4, 20092009-12-04
James,
Not sure about your specific problem, but I have a bitbang I2C implementation that
I use on the 5438 chip to talk to a Phillips RTC. Let me know if you need it...
Good Luck,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Larry W
Sent: Friday, December 04, 2009 10:28 AM
To: m...
Subject: [SPAM] [msp430] Re: I2C troubles
Importance: Low
Look closely at the address. It is skewed one bit when you load it into the MSP430 register.
--- In m..., James Watt wrote:
>
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
> Thanks.
> James.
> On 2009-12-02, at 9:20 AM, James Watt wrote:
>
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
>
Not sure about your specific problem, but I have a bitbang I2C implementation that
I use on the 5438 chip to talk to a Phillips RTC. Let me know if you need it...
Good Luck,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Larry W
Sent: Friday, December 04, 2009 10:28 AM
To: m...
Subject: [SPAM] [msp430] Re: I2C troubles
Importance: Low
Look closely at the address. It is skewed one bit when you load it into the MSP430 register.
--- In m..., James Watt wrote:
>
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
> Thanks.
> James.
> On 2009-12-02, at 9:20 AM, James Watt wrote:
>
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
>
Reply by ●December 4, 20092009-12-04
James Watt wrote:
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
I like I2C, but I've never used the USCI for it, so I didn't respond.
After my first device it was pretty easy, but...
Do you have a scope? Almost a must for trouble shooting. And it doesn't
have to be fancy. The one I use at my desk is an HP1740A. ~$100 on ebay.
There was a list of digital box scopes that went by here for < $250. The
eeprom should ack after a proper start and 8 bits, something very easy
to see on a scope. If you have a digital scope, you shouldn't even need
a test loop. So, I'm guessing you have not looked at the bus with a
scope at this point...
My I2C stuff here...
Best, Dan.
> Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
>
I like I2C, but I've never used the USCI for it, so I didn't respond.
After my first device it was pretty easy, but...
Do you have a scope? Almost a must for trouble shooting. And it doesn't
have to be fancy. The one I use at my desk is an HP1740A. ~$100 on ebay.
There was a list of digital box scopes that went by here for < $250. The
eeprom should ack after a proper start and 8 bits, something very easy
to see on a scope. If you have a digital scope, you shouldn't even need
a test loop. So, I'm guessing you have not looked at the bus with a
scope at this point...
My I2C stuff here...
Best, Dan.
Reply by ●December 4, 20092009-12-04
Maybe you're using a two address byte code with a one address byte
device.
The meaning of the bytes after the first one depends on the I2C slave you're using. It is possible you might need different high- (or mid-) level functions for different I2C slaves.
I guess by 'internal functions' you mean the I2C hardware and not an application included software I2C, right?
I don't know what you mean by transactions not being ACKed, but in the case of the 24LC01 each byte sent by the master has to be ACKed by the slave. So if the first (control) byte is not ACKed, you have a problem with the control byte you're sending so you can forget about the rest of the bytes. If I'm not mistaken, on the 1xx USART this first byte is kind of hardwired to the I2C hardware, in that you have to disable it (put into reset state) if you want to change the bits (chip-address, not memory address) on the control byte. I don't know how this works on USCI module.
But are you sure you're interpreting the logic analyser data correctly (not in reversed bit order)? Given you have a logic analyser, post the data you see on it.
Other than that, just make sure you don't have the SDA and SCL lines reversed XD
Regards,
Michael K.
--- In m..., James Watt wrote:
>
> Hi all,
>
> I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
>
> There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
>
> Any suggestions that would help figure this out would be much appreciated.
> James.
>
The meaning of the bytes after the first one depends on the I2C slave you're using. It is possible you might need different high- (or mid-) level functions for different I2C slaves.
I guess by 'internal functions' you mean the I2C hardware and not an application included software I2C, right?
I don't know what you mean by transactions not being ACKed, but in the case of the 24LC01 each byte sent by the master has to be ACKed by the slave. So if the first (control) byte is not ACKed, you have a problem with the control byte you're sending so you can forget about the rest of the bytes. If I'm not mistaken, on the 1xx USART this first byte is kind of hardwired to the I2C hardware, in that you have to disable it (put into reset state) if you want to change the bits (chip-address, not memory address) on the control byte. I don't know how this works on USCI module.
But are you sure you're interpreting the logic analyser data correctly (not in reversed bit order)? Given you have a logic analyser, post the data you see on it.
Other than that, just make sure you don't have the SDA and SCL lines reversed XD
Regards,
Michael K.
--- In m..., James Watt wrote:
>
> Hi all,
>
> I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
>
> There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
>
> Any suggestions that would help figure this out would be much appreciated.
> James.
>
Reply by ●December 5, 20092009-12-05
I have a scope (old 100MHz Tek) but it's not a sampling scope so a bit
annoying to use on non-periodic signals. I do have a logic analyzer though and
have been using it. I'll give the scope a try and compare to the LA
though.
A bit more info...a friend is looking into this as well and noticed that if he ignored the ACK/NAK signal he was able to write and then read an EEPROM.
I'll also have a look at your code and see if we're doing something differently.
Thanks for the reply and ideas.
James.
On 2009-12-04, at 10:46 AM, Dan Bloomquist wrote:
> James Watt wrote:
> > Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
> > I like I2C, but I've never used the USCI for it, so I didn't respond.
> After my first device it was pretty easy, but...
>
> Do you have a scope? Almost a must for trouble shooting. And it doesn't
> have to be fancy. The one I use at my desk is an HP1740A. ~$100 on ebay.
> There was a list of digital box scopes that went by here for < $250. The
> eeprom should ack after a proper start and 8 bits, something very easy
> to see on a scope. If you have a digital scope, you shouldn't even need
> a test loop. So, I'm guessing you have not looked at the bus with a
> scope at this point...
>
> My I2C stuff here...
> Best, Dan.
A bit more info...a friend is looking into this as well and noticed that if he ignored the ACK/NAK signal he was able to write and then read an EEPROM.
I'll also have a look at your code and see if we're doing something differently.
Thanks for the reply and ideas.
James.
On 2009-12-04, at 10:46 AM, Dan Bloomquist wrote:
> James Watt wrote:
> > Ok, I'll ask the question another way - for those of you that have used I2C on the MSP430, would you be willing to share the relevant bits of code and perhaps describe the schematic you used?
> > I like I2C, but I've never used the USCI for it, so I didn't respond.
> After my first device it was pretty easy, but...
>
> Do you have a scope? Almost a must for trouble shooting. And it doesn't
> have to be fancy. The one I use at my desk is an HP1740A. ~$100 on ebay.
> There was a list of digital box scopes that went by here for < $250. The
> eeprom should ack after a proper start and 8 bits, something very easy
> to see on a scope. If you have a digital scope, you shouldn't even need
> a test loop. So, I'm guessing you have not looked at the bus with a
> scope at this point...
>
> My I2C stuff here...
> Best, Dan.
Reply by ●December 5, 20092009-12-05
I can't get past the control byte (device address and R/W control bit).
That's the thing that NAKs. I and a friend have gone over the data from
the LA and compared it with the datasheet (in agonizing detail) and it looks
right.
Correct, I meant using the MSP430 internal I2C functions not a higher level software app.
The signals are correct (SDA and SCL) and I'm using the provided interpreter in the LA (it's an Intronix Logicport from pctestinstruments.com). The LA hardware samples the signals and the LA Windows software is the display. I'll try to provide a screen capture...can an attachment be sent on this list?
Thanks for the help.
James.
On 2009-12-04, at 1:45 PM, Michael wrote:
> Maybe you're using a two address byte code with a one address byte device.
> The meaning of the bytes after the first one depends on the I2C slave you're using. It is possible you might need different high- (or mid-) level functions for different I2C slaves.
>
> I guess by 'internal functions' you mean the I2C hardware and not an application included software I2C, right?
>
> I don't know what you mean by transactions not being ACKed, but in the case of the 24LC01 each byte sent by the master has to be ACKed by the slave. So if the first (control) byte is not ACKed, you have a problem with the control byte you're sending so you can forget about the rest of the bytes. If I'm not mistaken, on the 1xx USART this first byte is kind of hardwired to the I2C hardware, in that you have to disable it (put into reset state) if you want to change the bits (chip-address, not memory address) on the control byte. I don't know how this works on USCI module.
>
> But are you sure you're interpreting the logic analyser data correctly (not in reversed bit order)? Given you have a logic analyser, post the data you see on it.
>
> Other than that, just make sure you don't have the SDA and SCL lines reversed XD
>
> Regards,
> Michael K.
>
> --- In m..., James Watt wrote:
> >
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
Correct, I meant using the MSP430 internal I2C functions not a higher level software app.
The signals are correct (SDA and SCL) and I'm using the provided interpreter in the LA (it's an Intronix Logicport from pctestinstruments.com). The LA hardware samples the signals and the LA Windows software is the display. I'll try to provide a screen capture...can an attachment be sent on this list?
Thanks for the help.
James.
On 2009-12-04, at 1:45 PM, Michael wrote:
> Maybe you're using a two address byte code with a one address byte device.
> The meaning of the bytes after the first one depends on the I2C slave you're using. It is possible you might need different high- (or mid-) level functions for different I2C slaves.
>
> I guess by 'internal functions' you mean the I2C hardware and not an application included software I2C, right?
>
> I don't know what you mean by transactions not being ACKed, but in the case of the 24LC01 each byte sent by the master has to be ACKed by the slave. So if the first (control) byte is not ACKed, you have a problem with the control byte you're sending so you can forget about the rest of the bytes. If I'm not mistaken, on the 1xx USART this first byte is kind of hardwired to the I2C hardware, in that you have to disable it (put into reset state) if you want to change the bits (chip-address, not memory address) on the control byte. I don't know how this works on USCI module.
>
> But are you sure you're interpreting the logic analyser data correctly (not in reversed bit order)? Given you have a logic analyser, post the data you see on it.
>
> Other than that, just make sure you don't have the SDA and SCL lines reversed XD
>
> Regards,
> Michael K.
>
> --- In m..., James Watt wrote:
> >
> > Hi all,
> >
> > I've been trying to use the MSP430F5438 on a TI devkit to communicate with a couple I2C devices (only one on the bus at a time). One device is a Microchip EEPROM, 24LC01B and the other is a fuel gauge. The problem is that the transactions are never ACKd. I do get a NAK though. I'm using port 2 but have tried port 1 as well - i.e. am using the I2C internal functions of the MSP430.
> >
> > There are pullups on the bus, it's point-to-point, voltages are good, logic analyzer interprets the I2C protocol and everything looks fine (address sent correctly, etc.), I've tried various speeds from very slow to a little over 100kbps. The device just won't ACK the transaction. Is the TI implementation not quite standard?
> >
> > Any suggestions that would help figure this out would be much appreciated.
> > James.
> >
Reply by ●December 5, 20092009-12-05
James Watt wrote:
> I have a scope (old 100MHz Tek) but it's not a sampling scope so a bit annoying to use on non-periodic signals. I do have a logic analyzer though and have been using it. I'll give the scope a try and compare to the LA though.
>
> A bit more info...a friend is looking into this as well and noticed that if he ignored the ACK/NAK signal he was able to write and then read an EEPROM.
>
> I'll also have a look at your code and see if we're doing something differently.
>
Hi James,
This says a lot. It says you will see the ack on the buss and I'm taking
it you did see the ack with the logic analyzer. I would not worry about
looking at the buss with the scope from here unless to check voltage
levels. So, is this about getting a UCNACKIFG after sending the device
address? I haven't poured over the datasheet, just taking a look. The
only thing I can think of is that the MSP430 doesn't see the ack because
the sink of the eeprom can't overcome the pullup. Are they 10k or so?
Does that LA show levels or just state? If not, set the level down to
like .5-.4v and see if the ack disappears. Just thinking out loud in
case it could help.
Best, Dan.
> I have a scope (old 100MHz Tek) but it's not a sampling scope so a bit annoying to use on non-periodic signals. I do have a logic analyzer though and have been using it. I'll give the scope a try and compare to the LA though.
>
> A bit more info...a friend is looking into this as well and noticed that if he ignored the ACK/NAK signal he was able to write and then read an EEPROM.
>
> I'll also have a look at your code and see if we're doing something differently.
>
Hi James,
This says a lot. It says you will see the ack on the buss and I'm taking
it you did see the ack with the logic analyzer. I would not worry about
looking at the buss with the scope from here unless to check voltage
levels. So, is this about getting a UCNACKIFG after sending the device
address? I haven't poured over the datasheet, just taking a look. The
only thing I can think of is that the MSP430 doesn't see the ack because
the sink of the eeprom can't overcome the pullup. Are they 10k or so?
Does that LA show levels or just state? If not, set the level down to
like .5-.4v and see if the ack disappears. Just thinking out loud in
case it could help.
Best, Dan.
