--- In l..., "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

An Engineer's Guide to the LPC2100 Series

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..., "tcirobot" wrote:
>
> --- In l..., "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
>

--- In l..., "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

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..., "tcirobot" wrote:
>
> --- In l..., "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
>

--- In l..., "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

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

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..., "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..., "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..., "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..., "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
> > > >
> > >
>

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..., "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..., "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..., "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
> > >
>

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..., "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..., "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
>

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..., "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
>