I have an EEPROM chipset (AT24C1024B) interfaced with MSP430F248 through I2C UCB1 module.

I'm able to write data to EEPROM but I'm not able to read back from it.

First, I write the offset address to EEPROM before reading from it. After transmitting the last byte, I disable the TX UCB1TXIE, clear UCB1TXIFG flag, change to I2C receiver ~UCTR, enable RX UCB1RXIE, then I issue a repeated start UCTXSTT.

Surprisingly, what I observe is that, UCA1TXIFG flag gets set although UCA1TXIE is disabled and it keeps looping inside the TX routine USCIAB1TX_VECTOR. I tried clearing the UCA1TXIFG again and again but in vain.

Importantly, I see the data available in the UCB1RXBUF and the flag UCB1RXIFG also set. But the USCIAB1RX_VECTOR is not getting executed.
So the read is not complete.

I think, only looping in TX is preventing the entry into RX routine.

Code snippet from TX routine:
******************************************************
******************************************************
UCB1CTL1 &= ~UCTR;

// Clear USCI_B1 TX interrupt flag
UC1IFG &= ~UCB1TXIFG;

// Disable Tx interrupt
UC1IE &= ~UCB1TXIE;

// Enable Rx Interrupt
UC1IE |= UCB1RXIE;

// Issue repeated start
UCB1CTL1 |= UCTXSTT;
*******************************************************
*******************************************************

IS THERE ANYTHING I'M MISSING OR I SHOULD DO?
PLEASE LET ME KNOW YOUR THOUGHTS. THANKS.
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

A couple of quick remarks, I have to go in a few minutes:

--- In m...@yahoogroups.com, "embedded2k" wrote:
>
> I have an EEPROM chipset (AT24C1024B) interfaced with MSP430F248 through I2C UCB1 module.
>
> I'm able to write data to EEPROM but I'm not able to read back from
> it.
* how do you know this? have you read the EEPROM with another device to verify it contains the data you wrote? The fact that your writing routine executes doesn't mean you were able to write data to EEPROM. Unless you meant you can send but not receive data instead of write but not read.

> First, I write the offset address to EEPROM before reading from it.
> After transmitting the last byte, I disable the TX UCB1TXIE, clear
> UCB1TXIFG flag, change to I2C receiver ~UCTR, enable RX UCB1RXIE,
> then I issue a repeated start UCTXSTT.
> Surprisingly, what I observe is that, UCA1TXIFG flag gets set
> although UCA1TXIE is disabled and it keeps looping inside the TX
> routine USCIAB1TX_VECTOR. I tried clearing the UCA1TXIFG again and
> again but in vain.
*Start by reading THE ENTIRE USCI I2C chapter of the user guide. You don't know how the TXIFG behavies. It sets whenever the TX Buffer is EMPTY! For that matter you don't know how IFG flags behavie in general: they get set by hardware no matter the state of the IE bit. The IE only controls wether or not the IFG triggers an interrupt, not wether or not the IFG gets set.

> Importantly, I see the data available in the UCB1RXBUF and the flag
> UCB1RXIFG also set. But the USCIAB1RX_VECTOR is not getting
> executed.
> So the read is not complete.
>
> I think, only looping in TX is preventing the entry into RX
> routine.
* I think you're right on this one. Check interrupt priorities on the datasheet to find out for sure.

I didn't mean to sound harsh, but you should have learned this by googling things and by searching through previous posts. Did you search the forum prior to posting?

Regards,
Michael K.

>
> Code snippet from TX routine:
> ******************************************************
> ******************************************************
> UCB1CTL1 &= ~UCTR;
>
> // Clear USCI_B1 TX interrupt flag
> UC1IFG &= ~UCB1TXIFG;
>
> // Disable Tx interrupt
> UC1IE &= ~UCB1TXIE;
>
> // Enable Rx Interrupt
> UC1IE |= UCB1RXIE;
>
> // Issue repeated start
> UCB1CTL1 |= UCTXSTT;
> *******************************************************
> *******************************************************
>
> IS THERE ANYTHING I'M MISSING OR I SHOULD DO?
> PLEASE LET ME KNOW YOUR THOUGHTS. THANKS.
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> A couple of quick remarks, I have to go in a few minutes:
>
> --- In m...@yahoogroups.com, "embedded2k" wrote:
> >
> > I have an EEPROM chipset (AT24C1024B) interfaced with MSP430F248 through I2C UCB1 module.
> >
> > I'm able to write data to EEPROM but I'm not able to read back from
> > it.
> * how do you know this? have you read the EEPROM with another device to verify it contains the data you wrote? The fact that your writing routine executes doesn't mean you were able to write data to EEPROM. Unless you meant you can send but not receive data instead of write but not read.
>
> > First, I write the offset address to EEPROM before reading from it.
> > After transmitting the last byte, I disable the TX UCB1TXIE, clear
> > UCB1TXIFG flag, change to I2C receiver ~UCTR, enable RX UCB1RXIE,
> > then I issue a repeated start UCTXSTT.
> > Surprisingly, what I observe is that, UCA1TXIFG flag gets set
> > although UCA1TXIE is disabled and it keeps looping inside the TX
> > routine USCIAB1TX_VECTOR. I tried clearing the UCA1TXIFG again and
> > again but in vain.
> *Start by reading THE ENTIRE USCI I2C chapter of the user guide. You don't know how the TXIFG behavies. It sets whenever the TX Buffer is EMPTY! For that matter you don't know how IFG flags behavie in general: they get set by hardware no matter the state of the IE bit. The IE only controls wether or not the IFG triggers an interrupt, not wether or not the IFG gets set.
>
> > Importantly, I see the data available in the UCB1RXBUF and the flag
> > UCB1RXIFG also set. But the USCIAB1RX_VECTOR is not getting
> > executed.
> > So the read is not complete.
> >
> > I think, only looping in TX is preventing the entry into RX
> > routine.
> * I think you're right on this one. Check interrupt priorities on the datasheet to find out for sure.
>
> I didn't mean to sound harsh, but you should have learned this by googling things and by searching through previous posts. Did you search the forum prior to posting?
>
> Regards,
> Michael K.
>
> >
> > Code snippet from TX routine:
> > ******************************************************
> > ******************************************************
> > UCB1CTL1 &= ~UCTR;
> >
> > // Clear USCI_B1 TX interrupt flag
> > UC1IFG &= ~UCB1TXIFG;
> >
> > // Disable Tx interrupt
> > UC1IE &= ~UCB1TXIE;
> >
> > // Enable Rx Interrupt
> > UC1IE |= UCB1RXIE;
> >
> > // Issue repeated start
> > UCB1CTL1 |= UCTXSTT;
> > *******************************************************
> > *******************************************************
> >
> > IS THERE ANYTHING I'M MISSING OR I SHOULD DO?
> > PLEASE LET ME KNOW YOUR THOUGHTS. THANKS.
>
Micheal, first of all, thanks for the response. And I concur with your comment that one should first google and search the forum before posting. I tried it but in vain. Infact, to my surprise, I don't find any information on repeated start in this forum.

Whatever I write to EEPROM, I'm able to see the data in the read register when I read it back. But, the problem is the RX routine is not getting triggered.

Also, I don't find any such issue in the error document for this controller type. I'll spend sometime with the user guide again to see if I'm missing something.

Thanks again, any other suggestions?
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

hello dear I give you the working code for 24LC16 interfaced with MSP430F24=
17 and MSP430F2430 please try this its working and tested by me

=A0

#define DBG=A0=A00

//#include =A0=20
#include
#include =A0=A0//Processor specific definitions
#include
#include "hardware.h"
#include "parallel.h"
#include "anticollision.h"
#include "globals.h"
#include "tiris.h"
#include "14443.h"
#include "host.h"
#include "epc.h"
#include "automatic.h"
//



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

embedded2k wrote:
> Thanks again, any other suggestions?
>

Give up trying to implement a master with a device. It usually saves you
little or nothing, IMHO. /Synchronous /busses can be put on hold, so
there is no reason, in real time, to do them with a device in most
applications. With a device, you are obligated to handle events through
interrupts, not with bitbang.

Hope this helps, I can talk to many devices without concern.



Best, Dan.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

can you please tell me how to get characters from hyperterminal using uart =
and echo them
________________________________
From: Dan Bloomquist
To: m...@yahoogroups.com
Sent: Wednesday, 12 August, 2009 8:00:29 AM
Subject: Re: [msp430] Re: I2C - EEPROM repeated start problem

=A0=20
embedded2k wrote:
> Thanks again, any other suggestions?
>=20

Give up trying to implement a master with a device. It usually saves you=20
little or nothing, IMHO. /Synchronous /busses can be put on hold, so=20
there is no reason, in real time, to do them with a device in most=20
applications. With a device, you are obligated to handle events through=20
interrupts, not with bitbang.

Hope this helps, I can talk to many devices without concern.



Best, Dan.

Looking for local information? Find it on Yahoo! Local http://in.loca=
l.yahoo.com/

[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 )

How does this code handle open collectors, or does it even try to? The other bitbang code I've seen uses input/output swaps to simulate it, but I don't see that with this.

Mark Higgins

----- Original Message -----
From: Dan Bloomquist
To: m...@yahoogroups.com
Sent: Wednesday, August 12, 2009 2:00 AM
Subject: Re: [msp430] Re: I2C - EEPROM repeated start problem
embedded2k wrote:
> Thanks again, any other suggestions?
>

Give up trying to implement a master with a device. It usually saves you
little or nothing, IMHO. /Synchronous /busses can be put on hold, so
there is no reason, in real time, to do them with a device in most
applications. With a device, you are obligated to handle events through
interrupts, not with bitbang.

Hope this helps, I can talk to many devices without concern.



Best, Dan.

[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 )

Mark Higgins wrote:
> How does this code handle open collectors, or does it even try to? The other bitbang code I've seen uses input/output swaps to simulate it, but I don't see that with this.
>

Hi Mark,
I've done that on a USB device because of the level difference. But I
don't see why it is necessary for master applications where there are a
few simple devices out there on the same Vcc. The EEPROMs and other
devices I've worked with can't sink SCL so I don't even use a resistor
on that line, just SDA. There I switch to input when the device is
expected to sink SDA. I might be looking for low power trouble in the
event I pull up while the device is sinking but that means something is
wrong and needs fixing. As long as the device follows its own published
rules, it should not happen.

It would be easy enough to modify the code if it is a concern.

I have a job coming for msp430s!


Best, Dan.

>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

rupesh vishwakarma wrote:
> can you please tell me how to get characters from hyperterminal using uart and echo them
>

I've only bitbanged a uart and have no experience, (yet), with the USCI.
But from what I see the USCI is not hard to deal with as a uart.

Best, Dan.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hello Dan,
> I've done that on a USB device because of the level difference. But
> I don't see why it is necessary for master applications where there
> are a few simple devices out there on the same Vcc. The EEPROMs and
> other devices I've worked with can't sink SCL so I don't even use a
> resistor on that line, just SDA.

As far as I know, according to the I2C standard, if a slave device cannot handle incoming data until it has performed some other function, it can hold SCL low to force the master into a wait-state. That's why it also has to be implemented as an open collector.
Which EEPROMs are you using that you claim can't sink SCL?

And anyway, changing a bit from the PxOUT register is as easy/complicated has changing the same bit of the PxDIR register, so there is no extra effort involved in changing the pins direction instead of the pins output state.

Regards,
Michael K.

--- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
> Mark Higgins wrote:
> > How does this code handle open collectors, or does it even try to? The other bitbang code I've seen uses input/output swaps to simulate it, but I don't see that with this.
> >
>
> Hi Mark,
> I've done that on a USB device because of the level difference. But I
> don't see why it is necessary for master applications where there are a
> few simple devices out there on the same Vcc. The EEPROMs and other
> devices I've worked with can't sink SCL so I don't even use a resistor
> on that line, just SDA. There I switch to input when the device is
> expected to sink SDA. I might be looking for low power trouble in the
> event I pull up while the device is sinking but that means something is
> wrong and needs fixing. As long as the device follows its own published
> rules, it should not happen.
>
> It would be easy enough to modify the code if it is a concern.
>
> I have a job coming for msp430s!
> Best, Dan.
>
> >
> >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

tintronic wrote:
> Hello Dan,
>
>> I've done that on a USB device because of the level difference. But
>> I don't see why it is necessary for master applications where there
>> are a few simple devices out there on the same Vcc. The EEPROMs and
>> other devices I've worked with can't sink SCL so I don't even use a
>> resistor on that line, just SDA.
>>
>
> As far as I know, according to the I2C standard, if a slave device cannot handle incoming data until it has performed some other function, it can hold SCL low to force the master into a wait-state. That's why it also has to be implemented as an open collector.
>

Hi Michael,
Thanks. Yes, I know. I've read a lot about I2C in the last year.

> Which EEPROMs are you using that you claim can't sink SCL?
>

The 24LC64. Also true for the ds1631:
PIN SYMBOL DESCRIPTION
1 SDA Data Input/Output Pin for 2-Wire Serial Communication Port.
Open-Drain.
2 SCL Clock Input Pin for 2-Wire Serial Communication Port.

The same for the PCF8574A.

So far, every data sheet I've seen for an I2C slave SCL/SDA uses a
timing parameter rather than hold SCL. If the 24lc64 can't respond, like
when it is writing internally, you just don't get an ack, but it doesn't
hold SCL.
> And anyway, changing a bit from the PxOUT register is as easy/complicated has changing the same bit of the PxDIR register, so there is no extra effort involved in changing the pins direction instead of the pins output state.
>
Yes, I know. Like I said, I did it that way for a USB interface. The day
may come when I run into a device that will actively sink SCL and I will
have to deal with it. I'd guess it won't be a 'simple slave'.

And than again, if I fix it sooner I won't run into 'this'. :)
But I won't be rigging up something that does an I2C master soon, I have
other irons in the fire right now. And I know better than to publish
untested code. At the least, what is on lakeweb has been tested.

Best, Dan.

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "embedded2k" wrote:
>
> --- In m...@yahoogroups.com, "tintronic" wrote:
> >
> > A couple of quick remarks, I have to go in a few minutes:
> >
> > --- In m...@yahoogroups.com, "embedded2k" wrote:
> > >
> > > I have an EEPROM chipset (AT24C1024B) interfaced with MSP430F248 through I2C UCB1 module.
> > >
> > > I'm able to write data to EEPROM but I'm not able to read back from
> > > it.
> > * how do you know this? have you read the EEPROM with another device to verify it contains the data you wrote? The fact that your writing routine executes doesn't mean you were able to write data to EEPROM. Unless you meant you can send but not receive data instead of write but not read.
> >
> > > First, I write the offset address to EEPROM before reading from it.
> > > After transmitting the last byte, I disable the TX UCB1TXIE, clear
> > > UCB1TXIFG flag, change to I2C receiver ~UCTR, enable RX UCB1RXIE,
> > > then I issue a repeated start UCTXSTT.
> > > Surprisingly, what I observe is that, UCA1TXIFG flag gets set
> > > although UCA1TXIE is disabled and it keeps looping inside the TX
> > > routine USCIAB1TX_VECTOR. I tried clearing the UCA1TXIFG again and
> > > again but in vain.
> > *Start by reading THE ENTIRE USCI I2C chapter of the user guide. You don't know how the TXIFG behavies. It sets whenever the TX Buffer is EMPTY! For that matter you don't know how IFG flags behavie in general: they get set by hardware no matter the state of the IE bit. The IE only controls wether or not the IFG triggers an interrupt, not wether or not the IFG gets set.
> >
> > > Importantly, I see the data available in the UCB1RXBUF and the flag
> > > UCB1RXIFG also set. But the USCIAB1RX_VECTOR is not getting
> > > executed.
> > > So the read is not complete.
> > >
> > > I think, only looping in TX is preventing the entry into RX
> > > routine.
> > * I think you're right on this one. Check interrupt priorities on the datasheet to find out for sure.
> >
> > I didn't mean to sound harsh, but you should have learned this by googling things and by searching through previous posts. Did you search the forum prior to posting?
> >
> > Regards,
> > Michael K.
> >
> > >
> > > Code snippet from TX routine:
> > > ******************************************************
> > > ******************************************************
> > > UCB1CTL1 &= ~UCTR;
> > >
> > > // Clear USCI_B1 TX interrupt flag
> > > UC1IFG &= ~UCB1TXIFG;
> > >
> > > // Disable Tx interrupt
> > > UC1IE &= ~UCB1TXIE;
> > >
> > > // Enable Rx Interrupt
> > > UC1IE |= UCB1RXIE;
> > >
> > > // Issue repeated start
> > > UCB1CTL1 |= UCTXSTT;
> > > *******************************************************
> > > *******************************************************
> > >
> > > IS THERE ANYTHING I'M MISSING OR I SHOULD DO?
> > > PLEASE LET ME KNOW YOUR THOUGHTS. THANKS.
> > >
> > Micheal, first of all, thanks for the response. And I concur with your comment that one should first google and search the forum before posting. I tried it but in vain. Infact, to my surprise, I don't find any information on repeated start in this forum.
>
> Whatever I write to EEPROM, I'm able to see the data in the read register when I read it back. But, the problem is the RX routine is not getting triggered.
>
> Also, I don't find any such issue in the error document for this controller type. I'll spend sometime with the user guide again to see if I'm missing something.
>
> Thanks again, any other suggestions?
>

The problem was misnomer. In my MSP430 model - F248, the USCI B1 share the same interrupt vector for both RX and TX. The header of F248 contains comment mentioning USCIAB1TX_VECTOR for TX and USCIAB1RX_VECTOR for RX. But actually, USCIAB1TX_VECTOR handles both Tx and RX for I2C and this is mentioned in the user guide. I was surprised and releived to note this misnomer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Dan,
> So far, every data sheet I've seen for an I2C slave SCL/SDA uses a
> timing parameter rather than hold SCL. If the 24lc64 can't respond,
> like when it is writing internally, you just don't get an ack, but
> it doesn't hold SCL.

I'd seen this too in the I2C EEPROM I once used, but didn't know it was true for so many others. Thanks for sharing this information, I'm sure it will prove usefull in the future.

Regards,
Michael K.

--- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
> tintronic wrote:
> > Hello Dan,
> >
> >> I've done that on a USB device because of the level difference. But
> >> I don't see why it is necessary for master applications where there
> >> are a few simple devices out there on the same Vcc. The EEPROMs and
> >> other devices I've worked with can't sink SCL so I don't even use a
> >> resistor on that line, just SDA.
> >>
> >
> > As far as I know, according to the I2C standard, if a slave device cannot handle incoming data until it has performed some other function, it can hold SCL low to force the master into a wait-state. That's why it also has to be implemented as an open collector.
> >
>
> Hi Michael,
> Thanks. Yes, I know. I've read a lot about I2C in the last year.
>
> > Which EEPROMs are you using that you claim can't sink SCL?
> >
>
> The 24LC64. Also true for the ds1631:
> PIN SYMBOL DESCRIPTION
> 1 SDA Data Input/Output Pin for 2-Wire Serial Communication Port.
> Open-Drain.
> 2 SCL Clock Input Pin for 2-Wire Serial Communication Port.
>
> The same for the PCF8574A.
>
> So far, every data sheet I've seen for an I2C slave SCL/SDA uses a
> timing parameter rather than hold SCL. If the 24lc64 can't respond, like
> when it is writing internally, you just don't get an ack, but it doesn't
> hold SCL.
> > And anyway, changing a bit from the PxOUT register is as easy/complicated has changing the same bit of the PxDIR register, so there is no extra effort involved in changing the pins direction instead of the pins output state.
> >
> Yes, I know. Like I said, I did it that way for a USB interface. The day
> may come when I run into a device that will actively sink SCL and I will
> have to deal with it. I'd guess it won't be a 'simple slave'.
>
> And than again, if I fix it sooner I won't run into 'this'. :)
> But I won't be rigging up something that does an I2C master soon, I have
> other irons in the fire right now. And I know better than to publish
> untested code. At the least, what is on lakeweb has been tested.
>
> Best, Dan.
>
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )