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..., 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.
>
--- In m..., "embedded2k" wrote: >
> --- In m..., "tintronic" wrote:
> >
> > A couple of quick remarks, I have to go in a few minutes:
> >
> > --- In m..., "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.
Reply by Dan Bloomquist●August 12, 20092009-08-12
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.
Reply by tintronic●August 12, 20092009-08-12
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..., 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.
>
> >
> >
>
Reply by Dan Bloomquist●August 12, 20092009-08-12
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.
Reply by Dan Bloomquist●August 12, 20092009-08-12
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.
>
Reply by Mark Higgins●August 12, 20092009-08-12
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...
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.
Reply by rupesh vishwakarma●August 12, 20092009-08-12
can you please tell me how to get characters from hyperterminal using uart and
echo them
________________________________
From: Dan Bloomquist
To: m...
Sent: Wednesday, 12 August, 2009 8:00:29 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.
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.
Reply by rupesh vishwakarma●August 12, 20092009-08-12
hello dear I give you the working code for 24LC16 interfaced with MSP430F2417
and MSP430F2430 please try this its working and tested by me
