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.
I2C - EEPROM repeated start problem
Started by ●August 11, 2009
Reply by ●August 11, 20092009-08-11
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.
>
--- 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.
>
Reply by ●August 12, 20092009-08-12
--- 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?
>
> 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?
Reply by ●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
#define DBG0
//#include
#include
#include //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"
//
#define DBG0
//#include
#include
#include //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"
//
Reply by ●August 12, 20092009-08-12
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.
> 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 ●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.
Best, Dan.
Looking for local information? Find it on Yahoo! Local http://in.local.yahoo.com/
________________________________
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.
Best, Dan.
Looking for local information? Find it on Yahoo! Local http://in.local.yahoo.com/
Reply by ●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.
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 ●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.
>
> 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 ●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.
> 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 ●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.
>
> >
> >
>
> 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.
>
> >
> >
>
