2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Hello,

I want to test I2C and since I have no I2C device I used I2C0 and I2C1 of a same LPC2148 board.

I2C0 is master transmitter, I2C1 is slave receiver. But I can't make it work.
Using LEDS to debug, I see that :
- I2C0 send a START condition well
- I2C0 send the SLA+W and receive an ACK (0x18 in I2C0STAT)

- I2C1 receive its SLA+W and return an ACK (0x60 in I2C1STAT)

That makes the I2C0 send the byte of data. But then :
- I2C0 neither interrupts with 0x28 (Data transmitted, ACK received) nor 0x30 (Data transmitted, NOT ACK received)
- I2C1 does not interrupt with 0x80 (Data received, ACK returned)
I
put two pull up resistors on SDA and SCL (without them, nothing
happens, I2C0 does not interrupt even for a START condition sent).

I spent all the day on it and I can't find where is the problem.
Thank you for helping!
Here is my code :

// STATUS LEDs
#define LED_1 (1<<16) //Port 1-Pin 16
#define LED_2 (1<<17) //Port 1-Pin 17
#define LED_3 (1<<18) //Port 1-Pin 18

void initialize_leds(void) {

IO1DIR |= LED_1 | LED_2 | LED_3; // Set LED pins as output
IO1SET |= LED_1 | LED_2 | LED_3; // Turn all LEDs off

}

void led_on(unsigned led)
{
IO1CLR |= led;
}

void led_off(unsigned led)
{
IO1SET |= led;
}
//_____________________________________________________________________
#define I2C_AA (1<<2)
#define I2C_SI (1<<3)
#define I2C_STO (1<<4)
#define I2C_STA (1<<5)
#define I2C_I2EN (1<<6)
unsigned I2C_address;
unsigned I2C_data;

void I2CISR(void) __attribute__((interrupt("IRQ")));
void I2CISR(void) {
switch (I2C0STAT) {
case (0x08): // A START condition has been transmitted (Bus was free)
I2C0DAT = I2C_address; // Send the slave address (SLA) and the write bit (0);
I2C0CONCLR = I2C_STA;// Clear the start bit
break;

case (0x20): // SLA+W has been transmitted; NOT ACK has been received
I2C0CONSET = I2C_STA; // repeat START
break;
case (0x10): // A repetead START condition has been transmitted
I2C0DAT = I2C_address; // Send the slave address (SLA) and the write bit (0);
I2C0CONCLR = I2C_STA;// Clear the start bit
break;

case (0x18): // SLA+W has been transmitted; ACK has been received
I2C0DAT = 0x55; // Send first data byte
led_on(LED_1);
break;

case (0x28): // Data byte in I2DAT has been transmitted; ACK has been received
led_on(LED_2);
I2C0CONSET = I2C_STO; // Send STOP condition
break;

case (0x30): // Data byte in I2DAT has been transmitted; NOT ACK has been received
led_on(LED_2);
I2C0CONSET = I2C_STA; // repeat START
break;

case (0xF8):
break;

case (0x00):
break;

}

I2C0CONCLR = I2C_SI; // Clear the interrupt flag
VICVectAddr = 0x00; // Clear interrupt
}

void I2C1ISR(void) __attribute__((interrupt("IRQ")));
void I2C1ISR(void) {
unsigned char st;
st = I2C1STAT;
I2C1CONCLR = 0x2C;

switch (st) {
case (0x60): // Own SLA+W has been received; ACK has been returned
case (0x68): // Own SLA+W has been received; ACK has been returned (Arbitration lost)
case (0x70): // General call address (0x00) has been received; ACK has been returned
led_on(LED_3);
I2C1CONSET = I2C_AA;
break;

case (0x80): // DATA has been received, ACK has been returned
led_on(LED_2);
I2C1CONSET = I2C_AA;
break;

}
VICVectAddr = 0x00; // Clear interrupt
}

void initialize_I2C(void) {

PINSEL0 |= (1<<4)|(1<<6);
PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);

VICVectCntl1=0x29;
VICVectAddr1=(unsigned long) I2CISR;
VICIntEnable=0x0200;

VICVectCntl2=0x33;
VICVectAddr2=(unsigned long) I2C1ISR;
VICIntEnable=0x80200;
I2C0SCLH = 0x16;
I2C0SCLL = 0x16;
I2C0CONCLR = 0x6C;

I2C1CONCLR = 0x6C;
I2C1ADR = 0x7F; // 0x3F + 1
I2C1CONSET = 0x44;

}

void I2C_transfer_byte(unsigned addr, unsigned data) {

I2C_address = addr;
I2C_data = data;

I2C0CONCLR = 0x6C;
I2C0CONSET = 0x40; // Enter Master mode = I2C_I2EN;
I2C0CONSET = 0x20; // Send the START condition = I2C_STA
}
//_____________________________________________________________________
int main(void)
{
initialize();
initialize_I2C();
initialize_leds();

I2C_transfer_byte(0x7E,0x30);

}

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



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

--- In l...@yahoogroups.com, Jon Trem wrote:
>
> Hello,
>
> I want to test I2C and since I have no I2C device I used I2C0 and
I2C1 of a same LPC2148 board.
>
> I2C0 is master transmitter, I2C1 is slave receiver. But I can't make
it work.
> Using LEDS to debug, I see that :
> - I2C0 send a START condition well
> - I2C0 send the SLA+W and receive an ACK (0x18 in I2C0STAT)
>
> - I2C1 receive its SLA+W and return an ACK (0x60 in I2C1STAT)
>
> That makes the I2C0 send the byte of data. But then :
> - I2C0 neither interrupts with 0x28 (Data transmitted, ACK received)
nor 0x30 (Data transmitted, NOT ACK received)
> - I2C1 does not interrupt with 0x80 (Data received, ACK returned)
> I
> put two pull up resistors on SDA and SCL (without them, nothing
> happens, I2C0 does not interrupt even for a START condition sent).
>
> I spent all the day on it and I can't find where is the problem.
> Thank you for helping!
> Here is my code :
>
> // STATUS LEDs
> #define LED_1 (1<<16) //Port 1-Pin 16
> #define LED_2 (1<<17) //Port 1-Pin 17
> #define LED_3 (1<<18) //Port 1-Pin 18
>
> void initialize_leds(void) {
>
> IO1DIR |= LED_1 | LED_2 | LED_3; // Set LED pins as output
> IO1SET |= LED_1 | LED_2 | LED_3; // Turn all LEDs off
>
> }
>
> void led_on(unsigned led)
> {
> IO1CLR |= led;
> }
>
> void led_off(unsigned led)
> {
> IO1SET |= led;
> }
>
//____________________________________________________________________
_
> #define I2C_AA (1<<2)
> #define I2C_SI (1<<3)
> #define I2C_STO (1<<4)
> #define I2C_STA (1<<5)
> #define I2C_I2EN (1<<6)
> unsigned I2C_address;
> unsigned I2C_data;
>
> void I2CISR(void) __attribute__((interrupt("IRQ")));
> void I2CISR(void) {
> switch (I2C0STAT) {
> case (0x08): // A START condition has been transmitted (Bus was
free)
> I2C0DAT = I2C_address; // Send the slave address (SLA) and the
write bit (0);
> I2C0CONCLR = I2C_STA;// Clear the start bit
> break;
>
> case (0x20): // SLA+W has been transmitted; NOT ACK has been
received
> I2C0CONSET = I2C_STA; // repeat START
> break;
> case (0x10): // A repetead START condition has been transmitted
> I2C0DAT = I2C_address; // Send the slave address (SLA) and the
write bit (0);
> I2C0CONCLR = I2C_STA;// Clear the start bit
> break;
>
> case (0x18): // SLA+W has been transmitted; ACK has been
received
> I2C0DAT = 0x55; // Send first data byte
> led_on(LED_1);
> break;
>
> case (0x28): // Data byte in I2DAT has been transmitted; ACK has
been received
> led_on(LED_2);
> I2C0CONSET = I2C_STO; // Send STOP condition
> break;
>
> case (0x30): // Data byte in I2DAT has been transmitted; NOT ACK
has been received
> led_on(LED_2);
> I2C0CONSET = I2C_STA; // repeat START
> break;
>
> case (0xF8):
> break;
>
> case (0x00):
> break;
>
> }
>
> I2C0CONCLR = I2C_SI; // Clear the interrupt flag
> VICVectAddr = 0x00; // Clear interrupt
> }
>
> void I2C1ISR(void) __attribute__((interrupt("IRQ")));
> void I2C1ISR(void) {
> unsigned char st;
> st = I2C1STAT;
> I2C1CONCLR = 0x2C;
>
> switch (st) {
> case (0x60): // Own SLA+W has been received; ACK has been
returned
> case (0x68): // Own SLA+W has been received; ACK has been
returned (Arbitration lost)
> case (0x70): // General call address (0x00) has been received;
ACK has been returned
> led_on(LED_3);
> I2C1CONSET = I2C_AA;
> break;
>
> case (0x80): // DATA has been received, ACK has been returned
> led_on(LED_2);
> I2C1CONSET = I2C_AA;
> break;
>
> }
> VICVectAddr = 0x00; // Clear interrupt
> }
>
> void initialize_I2C(void) {
>
> PINSEL0 |= (1<<4)|(1<<6);
> PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);
>
> VICVectCntl1=0x29;
> VICVectAddr1=(unsigned long) I2CISR;
> VICIntEnable=0x0200;
>
> VICVectCntl2=0x33;
> VICVectAddr2=(unsigned long) I2C1ISR;
> VICIntEnable=0x80200;
> I2C0SCLH = 0x16;
> I2C0SCLL = 0x16;
> I2C0CONCLR = 0x6C;
>
> I2C1CONCLR = 0x6C;
> I2C1ADR = 0x7F; // 0x3F + 1
> I2C1CONSET = 0x44;
>
> }
>
> void I2C_transfer_byte(unsigned addr, unsigned data) {
>
> I2C_address = addr;
> I2C_data = data;
>
> I2C0CONCLR = 0x6C;
> I2C0CONSET = 0x40; // Enter Master mode = I2C_I2EN;
> I2C0CONSET = 0x20; // Send the START condition = I2C_STA
> }
>
//____________________________________________________________________
_
> int main(void)
> {
> initialize();
> initialize_I2C();
> initialize_leds();
>
> I2C_transfer_byte(0x7E,0x30);
>
> }
>

Make sure you clear the I2C1 interrupt flag (like you do for I2C0).

TC

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



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

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, Jon Trem wrote:
> >
> > Hello,
> >
> > I want to test I2C and since I have no I2C device I used I2C0 and
> I2C1 of a same LPC2148 board.
> >
> > I2C0 is master transmitter, I2C1 is slave receiver. But I can't make
> it work.
> > Using LEDS to debug, I see that :
> > - I2C0 send a START condition well
> > - I2C0 send the SLA+W and receive an ACK (0x18 in I2C0STAT)
> >
> > - I2C1 receive its SLA+W and return an ACK (0x60 in I2C1STAT)
> >
> > That makes the I2C0 send the byte of data. But then :
> > - I2C0 neither interrupts with 0x28 (Data transmitted, ACK received)
> nor 0x30 (Data transmitted, NOT ACK received)
> > - I2C1 does not interrupt with 0x80 (Data received, ACK returned)
> >
> >
> > I
> > put two pull up resistors on SDA and SCL (without them, nothing
> > happens, I2C0 does not interrupt even for a START condition sent).
> >
> >
> >
> > I spent all the day on it and I can't find where is the problem.
> >
> >
> > Thank you for helping!
> >
> >
> > Here is my code :
> >
> > // STATUS LEDs
> > #define LED_1 (1<<16) //Port 1-Pin 16
> > #define LED_2 (1<<17) //Port 1-Pin 17
> > #define LED_3 (1<<18) //Port 1-Pin 18
> >
> > void initialize_leds(void) {
> >
> > IO1DIR |= LED_1 | LED_2 | LED_3; // Set LED pins as output
> > IO1SET |= LED_1 | LED_2 | LED_3; // Turn all LEDs off
> >
> > }
> >
> > void led_on(unsigned led)
> > {
> > IO1CLR |= led;
> > }
> >
> > void led_off(unsigned led)
> > {
> > IO1SET |= led;
> > }
> >
> //____________________________________________________________________
> _
> >
> >
> > #define I2C_AA (1<<2)
> > #define I2C_SI (1<<3)
> > #define I2C_STO (1<<4)
> > #define I2C_STA (1<<5)
> > #define I2C_I2EN (1<<6)
> >
> >
> > unsigned I2C_address;
> > unsigned I2C_data;
> >
> > void I2CISR(void) __attribute__((interrupt("IRQ")));
> > void I2CISR(void) {
> >
> >
> > switch (I2C0STAT) {
> > case (0x08): // A START condition has been transmitted (Bus was
> free)
> > I2C0DAT = I2C_address; // Send the slave address (SLA) and the
> write bit (0);
> > I2C0CONCLR = I2C_STA;// Clear the start bit
> > break;
> >
> > case (0x20): // SLA+W has been transmitted; NOT ACK has been
> received
> > I2C0CONSET = I2C_STA; // repeat START
> > break;
> > case (0x10): // A repetead START condition has been transmitted
> > I2C0DAT = I2C_address; // Send the slave address (SLA) and the
> write bit (0);
> > I2C0CONCLR = I2C_STA;// Clear the start bit
> > break;
> >
> > case (0x18): // SLA+W has been transmitted; ACK has been
> received
> > I2C0DAT = 0x55; // Send first data byte
> > led_on(LED_1);
> > break;
> >
> > case (0x28): // Data byte in I2DAT has been transmitted; ACK has
> been received
> > led_on(LED_2);
> > I2C0CONSET = I2C_STO; // Send STOP condition
> > break;
> >
> > case (0x30): // Data byte in I2DAT has been transmitted; NOT ACK
> has been received
> > led_on(LED_2);
> > I2C0CONSET = I2C_STA; // repeat START
> > break;
> >
> > case (0xF8):
> > break;
> >
> > case (0x00):
> > break;
> >
> > }
> >
> > I2C0CONCLR = I2C_SI; // Clear the interrupt flag
> > VICVectAddr = 0x00; // Clear interrupt
> > }
> >
> > void I2C1ISR(void) __attribute__((interrupt("IRQ")));
> > void I2C1ISR(void) {
> > unsigned char st;
> > st = I2C1STAT;
> > I2C1CONCLR = 0x2C;
> >
> > switch (st) {
> > case (0x60): // Own SLA+W has been received; ACK has been
> returned
> > case (0x68): // Own SLA+W has been received; ACK has been
> returned (Arbitration lost)
> > case (0x70): // General call address (0x00) has been received;
> ACK has been returned
> > led_on(LED_3);
> > I2C1CONSET = I2C_AA;
> > break;
> >
> > case (0x80): // DATA has been received, ACK has been returned
> > led_on(LED_2);
> > I2C1CONSET = I2C_AA;
> > break;
> >
> > }
> >
> >
> > VICVectAddr = 0x00; // Clear interrupt
> > }
> >
> > void initialize_I2C(void) {
> >
> > PINSEL0 |= (1<<4)|(1<<6);
> > PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);
> >
> > VICVectCntl1=0x29;
> > VICVectAddr1=(unsigned long) I2CISR;
> > VICIntEnable=0x0200;
> >
> > VICVectCntl2=0x33;
> > VICVectAddr2=(unsigned long) I2C1ISR;
> > VICIntEnable=0x80200;
> >
> >
> > I2C0SCLH = 0x16;
> > I2C0SCLL = 0x16;
> > I2C0CONCLR = 0x6C;
> >
> > I2C1CONCLR = 0x6C;
> > I2C1ADR = 0x7F; // 0x3F + 1
> > I2C1CONSET = 0x44;
> >
> > }
> >
> > void I2C_transfer_byte(unsigned addr, unsigned data) {
> >
> > I2C_address = addr;
> > I2C_data = data;
> >
> > I2C0CONCLR = 0x6C;
> > I2C0CONSET = 0x40; // Enter Master mode = I2C_I2EN;
> > I2C0CONSET = 0x20; // Send the START condition = I2C_STA
> >
> >
> > }
> >
> >
> >
> //____________________________________________________________________
> _
> >
> >
> > int main(void)
> > {
> > initialize();
> > initialize_I2C();
> > initialize_leds();
> >
> > I2C_transfer_byte(0x7E,0x30);
> >
> > }
> > Make sure you clear the I2C1 interrupt flag (like you do for I2C0).
>
> TC
>

Is I2C1CONCLR = 0x2C; not doing it?
------------------------------------



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> --- In l...@yahoogroups.com, "tcirobot" wrote:
> > ....
> > Make sure you clear the I2C1 interrupt flag (like you do for
I2C0).
> >
> > TC
> > Is I2C1CONCLR = 0x2C; not doing it?
>

You need to do it in the I2C1 ISR (like you do in the I2C0 ISR).

TC
------------------------------------



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

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >
> > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > > ....
> > > Make sure you clear the I2C1 interrupt flag (like you do for
> I2C0).
> > >
> > > TC
> > >
> >
> > Is I2C1CONCLR = 0x2C; not doing it?
> > You need to do it in the I2C1 ISR (like you do in the I2C0 ISR).
>
> TC
>

Thank you for your help

But I2C1CONCLR = 0x2C; is in the I2C1 ISR and clear the interrupt flag.
------------------------------------



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> --- In l...@yahoogroups.com, "tcirobot" wrote:
> >
> > --- In l...@yahoogroups.com, "jon.trem" wrote:
> > >
> > > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > > > ....
> > > > Make sure you clear the I2C1 interrupt flag (like you do for
> > I2C0).
> > > >
> > > > TC
> > > >
> > >
> > > Is I2C1CONCLR = 0x2C; not doing it?
> > >
> >
> > You need to do it in the I2C1 ISR (like you do in the I2C0 ISR).
> >
> > TC
> > Thank you for your help
>
> But I2C1CONCLR = 0x2C; is in the I2C1 ISR and clear the interrupt
flag.
>

I haven't studied your code carefully but in the I2C1 ISR...

- switch on the I2C1 status first (before you clear the interrupt
state)
- you want to clear the I2C1 interrupt state at the end of the ISR

If you look at the differences between your I2C0 and I2C1 ISRs I think
you will see the difference I am talking about.

TC
------------------------------------



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

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >
> > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > >
> > > --- In l...@yahoogroups.com, "jon.trem" wrote:
> > > >
> > > > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > > > > ....
> > > > > Make sure you clear the I2C1 interrupt flag (like you do for
> > > I2C0).
> > > > >
> > > > > TC
> > > > >
> > > >
> > > > Is I2C1CONCLR = 0x2C; not doing it?
> > > >
> > >
> > > You need to do it in the I2C1 ISR (like you do in the I2C0 ISR).
> > >
> > > TC
> > >
> >
> > Thank you for your help
> >
> > But I2C1CONCLR = 0x2C; is in the I2C1 ISR and clear the interrupt
> flag.
> > I haven't studied your code carefully but in the I2C1 ISR...
>
> - switch on the I2C1 status first (before you clear the interrupt
> state)
> - you want to clear the I2C1 interrupt state at the end of the ISR
>
> If you look at the differences between your I2C0 and I2C1 ISRs I think
> you will see the difference I am talking about.
>
> TC
>

Okay I changed it, but it didn't solve the problem.
------------------------------------



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>...
>
> Okay I changed it, but it didn't solve the problem.
>

Post your latest code and I'll look at it again. It is a bit tricky to
get the LPC21xx I2C controller to function at first. I found the
documentation to be inadequate.

Do you have an oscilloscope? It helps a great deal to be able to view
the I2C signals when debugging the code.

TC
------------------------------------



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

Thank you very much for your help. Unfortunately, I don't have any
oscilloscope.

Here is my latest code (without the LED functions that are OK) :
#define I2C_AA (1<<2)
#define I2C_SI (1<<3)
#define I2C_STO (1<<4)
#define I2C_STA (1<<5)
#define I2C_I2EN (1<<6)
unsigned I2C_address;
unsigned I2C_data;

void I2CISR(void) __attribute__((interrupt("IRQ")));
void I2CISR(void) {
switch (I2C0STAT) {
case (0x08): // A START condition has been transmitted (Bus was free)
I2C0DAT = I2C_address; // Send the slave address (SLA) and the
write bit (0);
I2C0CONCLR = I2C_STA;// Clear the start bit
break;

case (0x20): // SLA+W has been transmitted; NOT ACK has been received
I2C0CONSET = I2C_STA; // repeat START
break;
case (0x10): // A repetead START condition has been transmitted
I2C0DAT = I2C_address; // Send the slave address (SLA) and the
write bit (0);
I2C0CONCLR = I2C_STA;// Clear the start bit
break;

case (0x18): // SLA+W has been transmitted; ACK has been received
I2C0DAT = 0x55; // Send first data byte
led_on(LED_1);
break;

case (0x28): // Data byte in I2DAT has been transmitted; ACK has
been received
led_on(LED_2);
I2C0CONSET = I2C_STO; // Send STOP condition
break;

case (0x30): // Data byte in I2DAT has been transmitted; NOT ACK
has been received
led_on(LED_2);
I2C0CONSET = I2C_STA; // repeat START
break;

case (0xF8):
break;

case (0x00):
break;

}

I2C0CONCLR = I2C_SI; // Clear the interrupt flag
VICVectAddr = 0x00; // Clear interrupt
}

void I2C1ISR(void) __attribute__((interrupt("IRQ")));
void I2C1ISR(void) {

switch (I2C1STAT) {
case (0x60): // Own SLA+W has been received; ACK has been returned
case (0x68): // Own SLA+W has been received; ACK has been returned
(Arbitration lost)
case (0x70): // General call address (0x00) has been received; ACK
has been returned
led_on(LED_3);
I2C1CONSET = I2C_AA;
break;

case (0x80): // DATA has been received, ACK has been returned
led_on(LED_2);
I2C1CONSET = I2C_AA;
break;

}
I2C1CONCLR = I2C_SI; // Clear the interrupt flag
VICVectAddr = 0x00; // Clear interrupt
}

void initialize_I2C(void) {

PINSEL0 |= (1<<4)|(1<<6);
PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);

VICVectCntl1=0x29;
VICVectAddr1=(unsigned long) I2CISR;
VICIntEnable=0x0200;

VICVectCntl2=0x33;
VICVectAddr2=(unsigned long) I2C1ISR;
VICIntEnable=0x80200;

I2C0SCLH = 0x16;
I2C0SCLL = 0x16;
I2C0CONCLR = 0x6C;

I2C1CONCLR = 0x6C;
I2C1ADR = 0x7F; // 0x3F + 1
I2C1CONSET = 0x44;

}

void I2C_transfer_byte(unsigned addr, unsigned data) {

I2C_address = addr;
I2C_data = data;

I2C0CONCLR = 0x6C;
I2C0CONSET = 0x40; // Enter Master mode
I2C0CONSET = I2C_STA; // Send the START condition
}
//_____________________________________________________________________
int main(void)
{
initialize();
initialize_I2C();
initialize_leds();

I2C_transfer_byte(0x7E,0x30);

}

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >...
> >
> > Okay I changed it, but it didn't solve the problem.
> > Post your latest code and I'll look at it again. It is a bit tricky to
> get the LPC21xx I2C controller to function at first. I found the
> documentation to be inadequate.
>
> Do you have an oscilloscope? It helps a great deal to be able to view
> the I2C signals when debugging the code.
>
> TC
>

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



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
> ...
> void initialize_I2C(void) {
>
> PINSEL0 |= (1<<4)|(1<<6);
> PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);

I'm not sure what you intended the second write to PINSEL0 above to do,
but it does not configure the I2C1 pins. I didn't see in your code
where you configured the I2C1 SCL and SDA pins. I was looking for the
something like the following (using your coding style)...

PINSEL1 |= (1<<2)|(1<<4);

I still haven't had a chance to walk through the rest of the code
carefully.

TC
------------------------------------



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

No, I2C1 ports are 0.11 and 0.14 which are in PINSEL0 bits 22,23 and
28,29.
I2C1 is well configured because it acknowledges only his address and
general calling (0x7E and 0x01 with the write bit). When I try to
communicate with I2C0 to another address, I have no acknowledge.

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> > ...
> > void initialize_I2C(void) {
> >
> > PINSEL0 |= (1<<4)|(1<<6);
> > PINSEL0 |= (1<<22)|(1<<23)|(1<<28)|(1<<29);
>
> I'm not sure what you intended the second write to PINSEL0 above to do,
> but it does not configure the I2C1 pins. I didn't see in your code
> where you configured the I2C1 SCL and SDA pins. I was looking for the
> something like the following (using your coding style)...
>
> PINSEL1 |= (1<<2)|(1<<4);
>
> I still haven't had a chance to walk through the rest of the code
> carefully.
>
> TC
>

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



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> No, I2C1 ports are 0.11 and 0.14 which are in PINSEL0 bits 22,23 and
> 28,29.
> I2C1 is well configured because it acknowledges only his address and
> general calling (0x7E and 0x01 with the write bit). When I try to
> communicate with I2C0 to another address, I have no acknowledge.
>

Sorry about the confusion. I was looking at the LPC2103 spec which is
NOT the part you are using. OOOPS!

TC
------------------------------------



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

NOTE: these diagrams may look funny inf NOT viewed with FIXED-WIDTH
fonts.

My understanding is that you are trying to write a byte of data using
I2C0 as the master and I2C1 as the slave. If everything worked I would
expect the I2C transaction to look like this...

START ADDR+W [ACK] DATA [ACK] STOP

... where brackets "[ ]" are used to indicate that the slave is
driving SDA (as opposed to the master).

I would expect to see the following I2C0 (master) interrupts and
states.

START ADDR+W [ACK] DATA [ACK] STOP
^ ^ ^
0x08 0x18 0x28

Your code for the I2C0 ISR seems to anticipate this sequence
correctly. One thing I did notice is that in the I2C0 ISR for state
0x18 you do the following...

I2C0DAT = I2C_address; //Send the slave address and the write bit
I2C0CONCLR = I2C_STA; // Clear the start bit

... I have them in my code in reverse order...

I2C0CONCLR = I2C_STA; // Clear the start bit
I2C0DAT = I2C_address; //Send the slave address and the write bit

I don't know that it matters (but you could try it).

I would expect to see the following I2C1 (slave) interrupts and
states.

START ADDR+W [ACK] DATA [ACK] STOP
^ ^ ^
0x60 0x80 0xA0

Your code for the I2C1 ISR seems to anticipate this sequence
correctly. One thing I did notice is that you don't read the received
data in state 0x80 from I2C1DAT. Maybe I2C1 is holding SCL low (I2C
wait state) until you do. I'd suggest adding the read of the received
data.

One other thing... I also read I2C1DAT in state 0x60 as a diagnostic
function to see what address (and write/read bit) I received as a
slave.

TC

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



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

I've tried both but it's still not working.

The address is not a problem because the slave answers (and just when
the address is fine). I also tried to read IC1DAT but LED_2 should
light as soon as I2C1STAT is 0x80 which is not the case. So the
instruction data = I2C1DAT; that I added in case(0x80) is never executed.

I'm really lost! But thanks for your help

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> NOTE: these diagrams may look funny inf NOT viewed with FIXED-WIDTH
> fonts.
>
> My understanding is that you are trying to write a byte of data using
> I2C0 as the master and I2C1 as the slave. If everything worked I would
> expect the I2C transaction to look like this...
>
> START ADDR+W [ACK] DATA [ACK] STOP
>
> ... where brackets "[ ]" are used to indicate that the slave is
> driving SDA (as opposed to the master).
>
> I would expect to see the following I2C0 (master) interrupts and
> states.
>
> START ADDR+W [ACK] DATA [ACK] STOP
> ^ ^ ^
> 0x08 0x18 0x28
>
> Your code for the I2C0 ISR seems to anticipate this sequence
> correctly. One thing I did notice is that in the I2C0 ISR for state
> 0x18 you do the following...
>
> I2C0DAT = I2C_address; //Send the slave address and the write bit
> I2C0CONCLR = I2C_STA; // Clear the start bit
>
> ... I have them in my code in reverse order...
>
> I2C0CONCLR = I2C_STA; // Clear the start bit
> I2C0DAT = I2C_address; //Send the slave address and the write bit
>
> I don't know that it matters (but you could try it).
>
> I would expect to see the following I2C1 (slave) interrupts and
> states.
>
> START ADDR+W [ACK] DATA [ACK] STOP
> ^ ^ ^
> 0x60 0x80 0xA0
>
> Your code for the I2C1 ISR seems to anticipate this sequence
> correctly. One thing I did notice is that you don't read the received
> data in state 0x80 from I2C1DAT. Maybe I2C1 is holding SCL low (I2C
> wait state) until you do. I'd suggest adding the read of the received
> data.
>
> One other thing... I also read I2C1DAT in state 0x60 as a diagnostic
> function to see what address (and write/read bit) I received as a
> slave.
>
> TC
>

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



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

If you are really interested in I2C, go get you a I2C debugger. Total
Phase makes one for a couple hundred bucks. It has saved me
tremendous time getting my I2C peripherals working correctly. It
shows you all the packets and makes short work of any problems.

Sutton

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> I've tried both but it's still not working.
>
> The address is not a problem because the slave answers (and just when
> the address is fine). I also tried to read IC1DAT but LED_2 should
> light as soon as I2C1STAT is 0x80 which is not the case. So the
> instruction data = I2C1DAT; that I added in case(0x80) is never
executed.
>
> I'm really lost! But thanks for your help
>
> --- In l...@yahoogroups.com, "tcirobot" wrote:
> >
> > NOTE: these diagrams may look funny inf NOT viewed with FIXED-WIDTH
> > fonts.
> >
> > My understanding is that you are trying to write a byte of data using
> > I2C0 as the master and I2C1 as the slave. If everything worked I
would
> > expect the I2C transaction to look like this...
> >
> > START ADDR+W [ACK] DATA [ACK] STOP
> >
> > ... where brackets "[ ]" are used to indicate that the slave is
> > driving SDA (as opposed to the master).
> >
> > I would expect to see the following I2C0 (master) interrupts and
> > states.
> >
> > START ADDR+W [ACK] DATA [ACK] STOP
> > ^ ^ ^
> > 0x08 0x18 0x28
> >
> > Your code for the I2C0 ISR seems to anticipate this sequence
> > correctly. One thing I did notice is that in the I2C0 ISR for state
> > 0x18 you do the following...
> >
> > I2C0DAT = I2C_address; //Send the slave address and the write bit
> > I2C0CONCLR = I2C_STA; // Clear the start bit
> >
> > ... I have them in my code in reverse order...
> >
> > I2C0CONCLR = I2C_STA; // Clear the start bit
> > I2C0DAT = I2C_address; //Send the slave address and the write bit
> >
> > I don't know that it matters (but you could try it).
> >
> > I would expect to see the following I2C1 (slave) interrupts and
> > states.
> >
> > START ADDR+W [ACK] DATA [ACK] STOP
> > ^ ^ ^
> > 0x60 0x80 0xA0
> >
> > Your code for the I2C1 ISR seems to anticipate this sequence
> > correctly. One thing I did notice is that you don't read the received
> > data in state 0x80 from I2C1DAT. Maybe I2C1 is holding SCL low (I2C
> > wait state) until you do. I'd suggest adding the read of the received
> > data.
> >
> > One other thing... I also read I2C1DAT in state 0x60 as a diagnostic
> > function to see what address (and write/read bit) I received as a
> > slave.
> >
> > TC
>
------------------------------------



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

Yes, I'm convinced of this, but I'm a student and I don't really have
the money to invest in a I2C debugger.
--- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
>
> If you are really interested in I2C, go get you a I2C debugger. Total
> Phase makes one for a couple hundred bucks. It has saved me
> tremendous time getting my I2C peripherals working correctly. It
> shows you all the packets and makes short work of any problems.
>
> Sutton
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >
> > I've tried both but it's still not working.
> >
> > The address is not a problem because the slave answers (and just when
> > the address is fine). I also tried to read IC1DAT but LED_2 should
> > light as soon as I2C1STAT is 0x80 which is not the case. So the
> > instruction data = I2C1DAT; that I added in case(0x80) is never
> executed.
> >
> > I'm really lost! But thanks for your help
> >
> > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > >
> > > NOTE: these diagrams may look funny inf NOT viewed with FIXED-WIDTH
> > > fonts.
> > >
> > > My understanding is that you are trying to write a byte of data
using
> > > I2C0 as the master and I2C1 as the slave. If everything worked I
> would
> > > expect the I2C transaction to look like this...
> > >
> > > START ADDR+W [ACK] DATA [ACK] STOP
> > >
> > > ... where brackets "[ ]" are used to indicate that the slave is
> > > driving SDA (as opposed to the master).
> > >
> > > I would expect to see the following I2C0 (master) interrupts and
> > > states.
> > >
> > > START ADDR+W [ACK] DATA [ACK] STOP
> > > ^ ^ ^
> > > 0x08 0x18 0x28
> > >
> > > Your code for the I2C0 ISR seems to anticipate this sequence
> > > correctly. One thing I did notice is that in the I2C0 ISR for state
> > > 0x18 you do the following...
> > >
> > > I2C0DAT = I2C_address; //Send the slave address and the write bit
> > > I2C0CONCLR = I2C_STA; // Clear the start bit
> > >
> > > ... I have them in my code in reverse order...
> > >
> > > I2C0CONCLR = I2C_STA; // Clear the start bit
> > > I2C0DAT = I2C_address; //Send the slave address and the write bit
> > >
> > > I don't know that it matters (but you could try it).
> > >
> > > I would expect to see the following I2C1 (slave) interrupts and
> > > states.
> > >
> > > START ADDR+W [ACK] DATA [ACK] STOP
> > > ^ ^ ^
> > > 0x60 0x80 0xA0
> > >
> > > Your code for the I2C1 ISR seems to anticipate this sequence
> > > correctly. One thing I did notice is that you don't read the
received
> > > data in state 0x80 from I2C1DAT. Maybe I2C1 is holding SCL low (I2C
> > > wait state) until you do. I'd suggest adding the read of the
received
> > > data.
> > >
> > > One other thing... I also read I2C1DAT in state 0x60 as a
diagnostic
> > > function to see what address (and write/read bit) I received as a
> > > slave.
> > >
> > > TC
> > >
>
------------------------------------



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

Understood. Maybe your department has debugging tools. They should.

I've spent many an hour looking at I2C problems, before I finally
broke down and got a debugger. Problem solved within an hour. I
still have issues occasionally and the debugger is an invaluable tool
to solve problems quickly.

Until then, unfortunately it's questioning yourself on whether your
code is correct or not until you find the problem. You'll find it
eventually.

Sutton

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> Yes, I'm convinced of this, but I'm a student and I don't really have
> the money to invest in a I2C debugger.
> --- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
> >
> > If you are really interested in I2C, go get you a I2C debugger. Total
> > Phase makes one for a couple hundred bucks. It has saved me
> > tremendous time getting my I2C peripherals working correctly. It
> > shows you all the packets and makes short work of any problems.
> >
> > Sutton
> >
> >
> >
> > --- In l...@yahoogroups.com, "jon.trem" wrote:
> > >
> > > I've tried both but it's still not working.
> > >
> > > The address is not a problem because the slave answers (and just
when
> > > the address is fine). I also tried to read IC1DAT but LED_2 should
> > > light as soon as I2C1STAT is 0x80 which is not the case. So the
> > > instruction data = I2C1DAT; that I added in case(0x80) is never
> > executed.
> > >
> > > I'm really lost! But thanks for your help
> > >
> > > --- In l...@yahoogroups.com, "tcirobot" wrote:
> > > >
> > > > NOTE: these diagrams may look funny inf NOT viewed with
FIXED-WIDTH
> > > > fonts.
> > > >
> > > > My understanding is that you are trying to write a byte of data
> using
> > > > I2C0 as the master and I2C1 as the slave. If everything worked I
> > would
> > > > expect the I2C transaction to look like this...
> > > >
> > > > START ADDR+W [ACK] DATA [ACK] STOP
> > > >
> > > > ... where brackets "[ ]" are used to indicate that the slave is
> > > > driving SDA (as opposed to the master).
> > > >
> > > > I would expect to see the following I2C0 (master) interrupts and
> > > > states.
> > > >
> > > > START ADDR+W [ACK] DATA [ACK] STOP
> > > > ^ ^ ^
> > > > 0x08 0x18 0x28
> > > >
> > > > Your code for the I2C0 ISR seems to anticipate this sequence
> > > > correctly. One thing I did notice is that in the I2C0 ISR for
state
> > > > 0x18 you do the following...
> > > >
> > > > I2C0DAT = I2C_address; //Send the slave address and the write bit
> > > > I2C0CONCLR = I2C_STA; // Clear the start bit
> > > >
> > > > ... I have them in my code in reverse order...
> > > >
> > > > I2C0CONCLR = I2C_STA; // Clear the start bit
> > > > I2C0DAT = I2C_address; //Send the slave address and the write bit
> > > >
> > > > I don't know that it matters (but you could try it).
> > > >
> > > > I would expect to see the following I2C1 (slave) interrupts and
> > > > states.
> > > >
> > > > START ADDR+W [ACK] DATA [ACK] STOP
> > > > ^ ^ ^
> > > > 0x60 0x80 0xA0
> > > >
> > > > Your code for the I2C1 ISR seems to anticipate this sequence
> > > > correctly. One thing I did notice is that you don't read the
> received
> > > > data in state 0x80 from I2C1DAT. Maybe I2C1 is holding SCL low
(I2C
> > > > wait state) until you do. I'd suggest adding the read of the
> received
> > > > data.
> > > >
> > > > One other thing... I also read I2C1DAT in state 0x60 as a
> diagnostic
> > > > function to see what address (and write/read bit) I received as a
> > > > slave.
> > > >
> > > > TC
> > > >
> > >
>
------------------------------------



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

Hi,

I am a student on a tight budget as you are but I found a good
solution to analyse bitstreams. It is called 'PoScope' by Po.laps.
It is really cheap (99Euro for the basic version) and handles SPI,
I2C, UART, 1Wire and is a poor mans osciloskop (2Ch, 200kHz), 16Ch
Logic-Probe/Generator (8MHz), Spectrum analyzer, etc. as well.

Check it out. http://po.labs.googlepages.com/usbosciloskop

Without debugging equipment you really can waste a lot of time.
Till
------------------------------------



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> I've tried both but it's still not working.
>

Have you looked at your main routine. The last thing it does is to
call I2C_transfer_byte( ). The last line of code in I2C_transfer_byte(
) starts the I2C transaction. At that point execution returns to main
and then what?

Try adding a while(1); as the last line in main, or a delay loop.

TC
------------------------------------



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

It's very strange. When i add while(1); after
I2C_transfer_byte(0x7E,0x30); Nothing happens! No LEDs is on which
means that no START condition has been sent, or whatever. When I have
not while(1) LED1 and LED3 are on.
--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >
> > I've tried both but it's still not working.
> > Have you looked at your main routine. The last thing it does is to
> call I2C_transfer_byte( ). The last line of code in I2C_transfer_byte(
> ) starts the I2C transaction. At that point execution returns to main
> and then what?
>
> Try adding a while(1); as the last line in main, or a delay loop.
>
> TC
>

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



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> It's very strange. When i add while(1); after
> I2C_transfer_byte(0x7E,0x30); Nothing happens! No LEDs is on which
> means that no START condition has been sent, or whatever. When I
have
> not while(1) LED1 and LED3 are on.
>

Be careful not to overlook the speed at which I2C is running and your
LEDs are blinking. How fast are your I2C clocks. Say it is 100 KHz. An
I2C write byte transaction is 20 bits on the wire at 10 uSec per bit
that is 200 uSec (plus a little more for overhead, ISR latency, etc.).
However, your LEDs are probably on for only a fraction of this total
time. If I remember correctly your eye has a hard time seeing stuff
below 10ms.

However, without looking at your code again how you are using the
LEDs. Would you expect both LEDs to be off if the transaciton
completed?

Since you have no test equipment you could try this approach with the
LEDS:

- Set one LED just prior to your call to I2C_transefer_byte( ).
- Set a second LED when the byte has been received in the I2C1 ISR.

That way, you won't miss it visually because of speed.

TC
------------------------------------



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

In fact, the LEDs are not blinking. I just light them in some
interrupt cases and one they are on, I never put them off.
LED1 is on when I2C0STAT is 0x18 (SLA+W has been transmitted; ACK has
been received).

LED2 should be on when :
I2C0STAT is 0x28 (Data byte in I2DAT has been transmitted; ACK has
been received)
or
I2C0STAT is 0x30 (Data byte in I2DAT has been transmitted; NOT ACK has
been received)
or
I2C1STAT is 0x80 (DATA has been received, ACK has been returned)

LED3 is on when I2C1STAT is 0x60 (Own SLA+W has been received; ACK has
been returned)

Just LED1 and 3 are lighten up for the moment.
--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "jon.trem" wrote:
> >
> > It's very strange. When i add while(1); after
> > I2C_transfer_byte(0x7E,0x30); Nothing happens! No LEDs is on which
> > means that no START condition has been sent, or whatever. When I
> have
> > not while(1) LED1 and LED3 are on.
> > Be careful not to overlook the speed at which I2C is running and your
> LEDs are blinking. How fast are your I2C clocks. Say it is 100 KHz. An
> I2C write byte transaction is 20 bits on the wire at 10 uSec per bit
> that is 200 uSec (plus a little more for overhead, ISR latency, etc.).
> However, your LEDs are probably on for only a fraction of this total
> time. If I remember correctly your eye has a hard time seeing stuff
> below 10ms.
>
> However, without looking at your code again how you are using the
> LEDs. Would you expect both LEDs to be off if the transaciton
> completed?
>
> Since you have no test equipment you could try this approach with the
> LEDS:
>
> - Set one LED just prior to your call to I2C_transefer_byte( ).
> - Set a second LED when the byte has been received in the I2C1 ISR.
>
> That way, you won't miss it visually because of speed.
>
> TC
>

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



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

--- In l...@yahoogroups.com, "jon.trem" wrote:
>
> In fact, the LEDs are not blinking. I just light them in some
> interrupt cases and one they are on, I never put them off.
> LED1 is on when I2C0STAT is 0x18 (SLA+W has been transmitted; ACK
has
> been received).
>
> LED2 should be on when :
> I2C0STAT is 0x28 (Data byte in I2DAT has been transmitted; ACK has
> been received)
> or
> I2C0STAT is 0x30 (Data byte in I2DAT has been transmitted; NOT ACK
has
> been received)
> or
> I2C1STAT is 0x80 (DATA has been received, ACK has been returned)
>
> LED3 is on when I2C1STAT is 0x60 (Own SLA+W has been received; ACK
has
> been returned)
>
> Just LED1 and 3 are lighten up for the moment.

Thanks for the explanation of your LED usage. I'm not sure how else to
help you at this point without observing the I2C signals. Without test
equipment and the ability to observe the I2C signals you simply have
to walk through your code methodically. I can assure you that the
problem is with your code since I have successfully done what your are
trying to do (use I2C0 as a master and I2C1 as a slave) with interrupt
driven code.

TC
------------------------------------



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