Problem with I2C

On 4 Dec, in article
     <1165304918.361673.137080@16g2000cwy.googlegroups.com>
     goister@gmail.com "galapogos" wrote:
>galapogos wrote:
>> Paul Carpenter wrote:
>> > On 4 Dec, in article
>> >      <1165253652.590662.58080@79g2000cws.googlegroups.com>
>> >      goister@gmail.com "galapogos" wrote:
>> >
>> > >Paul Carpenter wrote:
.....
>> > >> Slave devices (like EEPROMs) spend the majority of their time in RECEIVE
>> > >> mode, listening for addresses and data to be written TO the slave device
>> > >> they ONLY chnage to transmitters when READING data OUT of the slave
> device.
>> > >>
>> > >> For your MCU it MUST be in receiver mode to receive the I2C SDA line
>> > >> INTO its shift register for listening to addresses or for data WRITTEN
>> > >> to the device. Then change to transmit mode to connect the shift register
>> > >> OUTPUT to the I2C SDA line (and enable arbitration circuitry).
>> > >
>> > >OK, this means that like what Dan said previously I should initialize
>> > >my MCU as a slave receiver initially rather than a slave transmitter.
>> > >That might explain why the first device address is not acknowledged?
>> >
>> > Yes. you only switch to transmit mode at the point in time when you
>> > need to send a byte (actually READING out) data. Then you switch back
>> > again to receive mode. Just like the bits above, when it says
>> > (SLAVE RECEIVES) the slave is in receive mode.
>> >
>> > Ack bits should be handled by your software setting ack bit generation
>> > for address acknowledge so the hardware does it for you. As to whether
>> > your ASIC does anything with ACK bits, depends on the ASIC, having seen
>> > some that ignore incoming ACKs and always set ACK bit sending to '1'
>> > regardless of what it should be.
>> >
>> > That is why Dan and me are saying you are transmitting when you should
>> > be receiving.
>>
>> Cool. I initialized my MCU to a slave receiver and now it acknowledges
>> the first device address, so there's no resending. I also managed to
>> get the MCU to interrupt on all subsequent data bytes, but I'm still
>> not able to send the correct data over. The data is either 0x80 of 0xfd
>
>OK scratch that. The data that is sent is actually always 0x80, and I'm
>not sure why that's the case. I'm sending 16 bytes of data over to the
>master, and the initial handshaking is all fine until I actually send
>data over by writing my data to my serial buffer SBI0DBR, but when I
>immediately copy this data over to another junk variable, it reads
>0x80, and according to my logic analyzer waveform, it is also 0x80, so
>it looks like the MCU is indeed sending whatever is in the buffer, but
>the buffer isn't being updated with what I actually want to send...

First *ASSUMPTION* the first data byte of the 16 data bytes to send
should be 0x80 ?

Second assumption you are coding in C.

This suggests that you have not coded properly for interupt routines and
all the variables used.

        Are the variables used by other functions and interupt routine
          defined as volatile?

        Are you sure that the index(pointer) starts at beginning of buffer?
        Are you sure that the index/pointer is reset correctly
          at end of buffer to beginning of buffer?

        Are you sure nothing else changes the index/pointer?

        Are you sure the data is correct in the table?

        Are you sure the index/pointer is incrementing correctly and not
        been optimised away. You need a way to get this value every time
        used and be sure it is a real value.

There are so many things this could be that the actual code needs to be
checked including variables and function declarations as interupt function.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Paul Carpenter wrote:
> On 4 Dec, in article
>      <1165304918.361673.137080@16g2000cwy.googlegroups.com>
>      goister@gmail.com "galapogos" wrote:
> >galapogos wrote:
> >> Paul Carpenter wrote:
> >> > On 4 Dec, in article
> >> >      <1165253652.590662.58080@79g2000cws.googlegroups.com>
> >> >      goister@gmail.com "galapogos" wrote:
> >> >
> >> > >Paul Carpenter wrote:
> .....
> >> > >> Slave devices (like EEPROMs) spend the majority of their time in RECEIVE
> >> > >> mode, listening for addresses and data to be written TO the slave device
> >> > >> they ONLY chnage to transmitters when READING data OUT of the slave
> > device.
> >> > >>
> >> > >> For your MCU it MUST be in receiver mode to receive the I2C SDA line
> >> > >> INTO its shift register for listening to addresses or for data WRITTEN
> >> > >> to the device. Then change to transmit mode to connect the shift register
> >> > >> OUTPUT to the I2C SDA line (and enable arbitration circuitry).
> >> > >
> >> > >OK, this means that like what Dan said previously I should initialize
> >> > >my MCU as a slave receiver initially rather than a slave transmitter.
> >> > >That might explain why the first device address is not acknowledged?
> >> >
> >> > Yes. you only switch to transmit mode at the point in time when you
> >> > need to send a byte (actually READING out) data. Then you switch back
> >> > again to receive mode. Just like the bits above, when it says
> >> > (SLAVE RECEIVES) the slave is in receive mode.
> >> >
> >> > Ack bits should be handled by your software setting ack bit generation
> >> > for address acknowledge so the hardware does it for you. As to whether
> >> > your ASIC does anything with ACK bits, depends on the ASIC, having seen
> >> > some that ignore incoming ACKs and always set ACK bit sending to '1'
> >> > regardless of what it should be.
> >> >
> >> > That is why Dan and me are saying you are transmitting when you should
> >> > be receiving.
> >>
> >> Cool. I initialized my MCU to a slave receiver and now it acknowledges
> >> the first device address, so there's no resending. I also managed to
> >> get the MCU to interrupt on all subsequent data bytes, but I'm still
> >> not able to send the correct data over. The data is either 0x80 of 0xfd
> >
> >OK scratch that. The data that is sent is actually always 0x80, and I'm
> >not sure why that's the case. I'm sending 16 bytes of data over to the
> >master, and the initial handshaking is all fine until I actually send
> >data over by writing my data to my serial buffer SBI0DBR, but when I
> >immediately copy this data over to another junk variable, it reads
> >0x80, and according to my logic analyzer waveform, it is also 0x80, so
> >it looks like the MCU is indeed sending whatever is in the buffer, but
> >the buffer isn't being updated with what I actually want to send...
>
> First *ASSUMPTION* the first data byte of the 16 data bytes to send
> should be 0x80 ?

No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
at all. In fact, I tried sending dummy constants but I always get 0x80
instead.

> Second assumption you are coding in C.

Yes

> This suggests that you have not coded properly for interupt routines and
> all the variables used.
>
>         Are the variables used by other functions and interupt routine
>           defined as volatile?

Variables modified by the ISR are declared volatile. Should those that
are simply read but not written to by the ISR also be declared
volatile?

>         Are you sure that the index(pointer) starts at beginning of buffer?

Yes it is initialized to 0 in the init function

>         Are you sure that the index/pointer is reset correctly
>           at end of buffer to beginning of buffer?

What do you mean? The index never goes beyond the end of the buffer

>         Are you sure nothing else changes the index/pointer?

Pretty sure but I'll check

>         Are you sure the data is correct in the table?

Yes most definitely.

>         Are you sure the index/pointer is incrementing correctly and not
>         been optimised away. You need a way to get this value every time
>         used and be sure it is a real value.

You mean optimized by the compiler? How do I prevent this? By declaring
it as volatile?

> There are so many things this could be that the actual code needs to be
> checked including variables and function declarations as interupt function.

On 5 Dec, in article
     <1165369825.395623.117700@n67g2000cwd.googlegroups.com>
     goister@gmail.com "galapogos" wrote:

>Paul Carpenter wrote:
>> On 4 Dec, in article
>>      <1165304918.361673.137080@16g2000cwy.googlegroups.com>
>>      goister@gmail.com "galapogos" wrote:
>> >galapogos wrote:
>> >> Paul Carpenter wrote:
>> >> > On 4 Dec, in article
>> >> >      <1165253652.590662.58080@79g2000cws.googlegroups.com>
>> >> >      goister@gmail.com "galapogos" wrote:

.....
>> >> Cool. I initialized my MCU to a slave receiver and now it acknowledges
>> >> the first device address, so there's no resending. I also managed to
>> >> get the MCU to interrupt on all subsequent data bytes, but I'm still
>> >> not able to send the correct data over. The data is either 0x80 of 0xfd
>> >
>> >OK scratch that. The data that is sent is actually always 0x80, and I'm
>> >not sure why that's the case. I'm sending 16 bytes of data over to the
>> >master, and the initial handshaking is all fine until I actually send
>> >data over by writing my data to my serial buffer SBI0DBR, but when I
>> >immediately copy this data over to another junk variable, it reads
>> >0x80, and according to my logic analyzer waveform, it is also 0x80, so
>> >it looks like the MCU is indeed sending whatever is in the buffer, but
>> >the buffer isn't being updated with what I actually want to send...
>>
>> First *ASSUMPTION* the first data byte of the 16 data bytes to send
>> should be 0x80 ?
>
>No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
>at all. In fact, I tried sending dummy constants but I always get 0x80
>instead.

Are you sending a block of 16 bytes or 16 single byte read equences?

Check when changing to send first byte you change to transmit and have
set up everything and be sure it is in transmit mode before writing data
to controller.

....
>> This suggests that you have not coded properly for interupt routines and
>> all the variables used.
>>
>>         Are the variables used by other functions and interupt routine
>>           defined as volatile?
>
>Variables modified by the ISR are declared volatile. Should those that
>are simply read but not written to by the ISR also be declared
>volatile?

YES if they are defined elsewhere (e.g. base pointer)

>>         Are you sure that the index(pointer) starts at beginning of buffer?
>
>Yes it is initialized to 0 in the init function
>
>>         Are you sure that the index/pointer is reset correctly
>>           at end of buffer to beginning of buffer?
>
>What do you mean? The index never goes beyond the end of the buffer

Well anything could be happening.

>>         Are you sure nothing else changes the index/pointer?
>
>Pretty sure but I'll check
>
>>         Are you sure the data is correct in the table?
>
>Yes most definitely.
>
>>         Are you sure the index/pointer is incrementing correctly and not
>>         been optimised away. You need a way to get this value every time
>>         used and be sure it is a real value.
>
>You mean optimized by the compiler? How do I prevent this? By declaring
>it as volatile?

If the index is incremented once EACH interupt call it is possible the
compiler optimises the increment away, for interupt routines and values
used there and elsewhere I would always make those variables volatile to
be on the safe side as a start point.

>> There are so many things this could be that the actual code needs to be
>> checked including variables and function declarations as interupt function.


-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Paul Carpenter wrote:
> On 4 Dec, in article
>      <1165241872.242041.197340@73g2000cwn.googlegroups.com>
>      goister@gmail.com "galapogos" wrote:
> >Paul Carpenter wrote:
> >> On 3 Dec, in article
> >>      <1165156279.424918.206910@j72g2000cwa.googlegroups.com>
> >>      goister@gmail.com "galapogos" wrote:
> >> >Paul Carpenter wrote:
> >> >> On 3 Dec, in article
> >> >>      <1165139176.102811.13110@16g2000cwy.googlegroups.com>
> >> >>      goister@gmail.com "galapogos" wrote:
> >> >> >Dan Henry wrote:
> >> >> >> On 1 Dec 2006 21:32:30 -0800, "galapogos" <goister@gmail.com> wrote:
> >> >> >>
> >> >> >> >Hi,
> >> >> >> >I'm trying to interface a Toshiba 16bit MCU with another IC(call this
> >> >> >> >IC2),
> .....
> >> Can you forget the word 'dummy' it is NOT a dummy address. The EEPROM has
> >> lots of locations so which location to read is sent as an address from your
> >> ASIC to say WHICH location to READ (or write). So the address is an actual
> >> real address INSIDE the EEPROM. I have seen 256byte to 64kbyte EEPROMs used.
> >>
> >> The resent address is how the ASIC talks to the EEPROM and is determined
> >> by the EEPROM specification, read that datasheet, as that is what you
> >> are trying to emulate in your MCU and software.
> >>
> >> IT is *important* you understand how the EEPROM works. Then you can
> >> understand what the I2C transactions are, so you can get your
> >> software to emulate the EEPROM.
> >
> >Well, I'm simply following what the datasheet calls it. The master IC's
> >datasheet refers to the word address as a dummy word address, hence I
> >call it as such. I do understand that you have to address any memory(in
> >this case an EEPROM) with an actual physical address. In this case that
> >address is 0x00 if I'm understanding the datasheet properly.
>
> If you do not always read the correct address, then your EEPROM may as well
> just be a register with one value, or a full EEPROM with just one value.
>
> >> ...
> >> >> Put an actual EEPROM on the ASIC and do a detailed analysis of the timing
> >> >> of the I2C transactions that occur, and you may well find the ASIC is
> >> >> getting away with working. Note what rise and fall times you have, all
> > timing
> >> >> of ALL high and low states. Until you have done this the rest is
> > meaningless.
> >>
> >> Have you or are you going to do this it is important to realise what is
> >> actually happening, so you can then check it against what your software
> >> results are. Then you can confirm your software is working correctly.
> >
> >I haven't dont this yet since I have no access to the setup over the
> >weekend. I'm not sure if I can get an I2C compatible EEPROM either, but
> >I'll try. Meanwhile I'll have to keep working with what I have.
>
> I2C EEPROMs are easily available and not difficult to add. Without double
> checking the real situation you will not be sure when things are working.

I interfaced a microchip I2C EEPROM to the master ASIC, and then
triggered the master to request the 16byte data from the EEPROM. I'm
not sure what's in the EEPROM but it appears to be all 0xFFs. Anyway,
the timing diagram is exactly like the ASIC's datasheet says. Here's
the sequence:

1) Master(ASIC) sends start bit and device address and WRITE direction
bit(0xa0)
2) Slave(EEPROM) ACKs
3) Master sends word address(0x00)
4) Slave ACKs
5) Master sends another start bit and device address and READ direction
bit(0xa1)
6) Slave ACKs
7) Slave sends 1 byte of data(0xFF)
8) Master ACKs
9) Repeat 7-8 until all 16 bytes have been received
10) Master(?) sends NOACK and stop bit

This also corresponds with the EEPROM's datasheet timing diagram so I
assume this is the correct handshaking protocol to follow.

I refered to the I2C bus specification 2.1(Jan 2000) trying to find
this handshaking protocol, and this seems to be a "combined format" for
serial EEPROMs.

I then tried to access the EEPROM with my MCU set as a master. I was
able to get all the way to step 6, but after that, my MCU was still in
master transmitter mode rather than master receiver mode. I have to set
the master to transmit mode for it to send the 2nd device address in
step 5. I thought that the direction bit sent in step 5 would reset the
MCU to be in receiver mode but it didn't. Therefore I'm unable to
continue on to step 7. In fact, I had to hack things up quite a bit to
even get it working till step 6. For example, I didn't know how to
correctly detect when to restart in step 5, so I detected this by
having a global interrupt counter and restarting when the counter is a
certain value.

I'm sure there must be a proper way of detecting when to restart but I
can't figure out how. As far as my MCU goes, it still thinks it's in
master transmitter mode after sending the device/word address, so I
don't know how to tell it to restart at that point.

Is it so hard to handle the handshaking for every MCU or am I just
unlucky to be working with a Toshiba?

Paul Carpenter wrote:
> On 5 Dec, in article
>      <1165369825.395623.117700@n67g2000cwd.googlegroups.com>
>      goister@gmail.com "galapogos" wrote:
>
> >Paul Carpenter wrote:
> >> On 4 Dec, in article
> >>      <1165304918.361673.137080@16g2000cwy.googlegroups.com>
> >>      goister@gmail.com "galapogos" wrote:
> >> >galapogos wrote:
> >> >> Paul Carpenter wrote:
> >> >> > On 4 Dec, in article
> >> >> >      <1165253652.590662.58080@79g2000cws.googlegroups.com>
> >> >> >      goister@gmail.com "galapogos" wrote:
>
> .....
> >> >> Cool. I initialized my MCU to a slave receiver and now it acknowledges
> >> >> the first device address, so there's no resending. I also managed to
> >> >> get the MCU to interrupt on all subsequent data bytes, but I'm still
> >> >> not able to send the correct data over. The data is either 0x80 of 0xfd
> >> >
> >> >OK scratch that. The data that is sent is actually always 0x80, and I'm
> >> >not sure why that's the case. I'm sending 16 bytes of data over to the
> >> >master, and the initial handshaking is all fine until I actually send
> >> >data over by writing my data to my serial buffer SBI0DBR, but when I
> >> >immediately copy this data over to another junk variable, it reads
> >> >0x80, and according to my logic analyzer waveform, it is also 0x80, so
> >> >it looks like the MCU is indeed sending whatever is in the buffer, but
> >> >the buffer isn't being updated with what I actually want to send...
> >>
> >> First *ASSUMPTION* the first data byte of the 16 data bytes to send
> >> should be 0x80 ?
> >
> >No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
> >at all. In fact, I tried sending dummy constants but I always get 0x80
> >instead.
>
> Are you sending a block of 16 bytes or 16 single byte read equences?

I enter the MCU's ISR after each ACK sent/received. Each time I enter
the ISR I send or receive 1 byte, so I guess I'm sending 16 single byte
sequences?

> Check when changing to send first byte you change to transmit and have
> set up everything and be sure it is in transmit mode before writing data
> to controller.

Actually I'm not even sure if I can even change the transmit direction
on the fly. The control register that the transmit direction is at is
shared with the status register, so within my ISR, I check to see if
it's in transmit mode. If it is, then I'll send data, if not I'll
receive. It's really up to the hardware to tell me if it's in transmit
or receive mode AFAIK.

> ....
> >> This suggests that you have not coded properly for interupt routines and
> >> all the variables used.
> >>
> >>         Are the variables used by other functions and interupt routine
> >>           defined as volatile?
> >
> >Variables modified by the ISR are declared volatile. Should those that
> >are simply read but not written to by the ISR also be declared
> >volatile?
>
> YES if they are defined elsewhere (e.g. base pointer)
>
> >>         Are you sure that the index(pointer) starts at beginning of buffer?
> >
> >Yes it is initialized to 0 in the init function
> >
> >>         Are you sure that the index/pointer is reset correctly
> >>           at end of buffer to beginning of buffer?
> >
> >What do you mean? The index never goes beyond the end of the buffer
>
> Well anything could be happening.
>
> >>         Are you sure nothing else changes the index/pointer?
> >
> >Pretty sure but I'll check
> >
> >>         Are you sure the data is correct in the table?
> >
> >Yes most definitely.
> >
> >>         Are you sure the index/pointer is incrementing correctly and not
> >>         been optimised away. You need a way to get this value every time
> >>         used and be sure it is a real value.
> >
> >You mean optimized by the compiler? How do I prevent this? By declaring
> >it as volatile?
>
> If the index is incremented once EACH interupt call it is possible the
> compiler optimises the increment away, for interupt routines and values
> used there and elsewhere I would always make those variables volatile to
> be on the safe side as a start point.

I understand. Better be safe than sorry. I've modified all the isr
variable declarations to be volatile, but it didn't change the program
behavior.

galapogos wrote:

> As far as my MCU goes, it still thinks it's in
> master transmitter mode after sending the device/word address,

I'm confused. I thought you said that your MCU was a slave.

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Michael N. Moran wrote:
> galapogos wrote:
>
> > As far as my MCU goes, it still thinks it's in
> > master transmitter mode after sending the device/word address,
>
> I'm confused. I thought you said that your MCU was a slave.

Yes it is, when I interface it with the master ASIC. The previous post
that you replied to was a case where I was trying to interface with an
external I2C EEPROM just to test things out and hopefully get a better
understanding of how I2C works. In this particular setup the MCU was
setup as a master and the EEPROM a slave.

On 6 Dec, in article
     <1165400403.987854.72700@16g2000cwy.googlegroups.com>
     goister@gmail.com "galapogos" wrote:

>Paul Carpenter wrote:
>> On 4 Dec, in article
>>      <1165241872.242041.197340@73g2000cwn.googlegroups.com>
>>      goister@gmail.com "galapogos" wrote:
>> >Paul Carpenter wrote:
>> >> On 3 Dec, in article
>> >>      <1165156279.424918.206910@j72g2000cwa.googlegroups.com>
>> >>      goister@gmail.com "galapogos" wrote:
>> >> >Paul Carpenter wrote:
>> >> >> On 3 Dec, in article
>> >> >>      <1165139176.102811.13110@16g2000cwy.googlegroups.com>
>> >> >>      goister@gmail.com "galapogos" wrote:
>> >> >> >Dan Henry wrote:
>> >> >> >> On 1 Dec 2006 21:32:30 -0800, "galapogos" <goister@gmail.com> wrote:
>> >> >> >>
>> >> >> >> >Hi,
>> >> >> >> >I'm trying to interface a Toshiba 16bit MCU with another IC(call
> this
>> >> >> >> >IC2),
 .....
>> >> >> Put an actual EEPROM on the ASIC and do a detailed analysis of the
> timing
>> >> >> of the I2C transactions that occur, and you may well find the ASIC is
>> >> >> getting away with working. Note what rise and fall times you have, all
>> > timing
>> >> >> of ALL high and low states. Until you have done this the rest is
>> > meaningless.
>> >>
>> >> Have you or are you going to do this it is important to realise what is
>> >> actually happening, so you can then check it against what your software
>> >> results are. Then you can confirm your software is working correctly.
>> >
>> >I haven't dont this yet since I have no access to the setup over the
>> >weekend. I'm not sure if I can get an I2C compatible EEPROM either, but
>> >I'll try. Meanwhile I'll have to keep working with what I have.
>>
>> I2C EEPROMs are easily available and not difficult to add. Without double
>> checking the real situation you will not be sure when things are working.
>
>I interfaced a microchip I2C EEPROM to the master ASIC, and then
>triggered the master to request the 16byte data from the EEPROM. I'm
>not sure what's in the EEPROM but it appears to be all 0xFFs. Anyway,
>the timing diagram is exactly like the ASIC's datasheet says. Here's
>the sequence:

You are getting 0xFF which shows

        a) The EEPROM is erased
        b) The hardware and wiring works
        c) You can see that the transactions can be done.
        d) You have a reference for REAL that matches what should happen.

>1) Master(ASIC) sends start bit and device address and WRITE direction
>bit(0xa0)
>2) Slave(EEPROM) ACKs
>3) Master sends word address(0x00)
>4) Slave ACKs
>5) Master sends another start bit and device address and READ direction
>bit(0xa1)
>6) Slave ACKs
>7) Slave sends 1 byte of data(0xFF)
>8) Master ACKs
>9) Repeat 7-8 until all 16 bytes have been received
>10) Master(?) sends NOACK and stop bit
>
>This also corresponds with the EEPROM's datasheet timing diagram so I
>assume this is the correct handshaking protocol to follow.

Yes that is correct.

>I refered to the I2C bus specification 2.1(Jan 2000) trying to find
>this handshaking protocol, and this seems to be a "combined format" for
>serial EEPROMs.
>
>I then tried to access the EEPROM with my MCU set as a master. I was
>able to get all the way to step 6, but after that, my MCU was still in
>master transmitter mode rather than master receiver mode. I have to set
>the master to transmit mode for it to send the 2nd device address in
>step 5. I thought that the direction bit sent in step 5 would reset the
>MCU to be in receiver mode but it didn't. Therefore I'm unable to
>continue on to step 7. In fact, I had to hack things up quite a bit to

NO direction changes YOU must code, I would suggest when you are sending
a READ address (last bit of address = 1), after the ACK then YOU must change
the direction.

>even get it working till step 6. For example, I didn't know how to
>correctly detect when to restart in step 5, so I detected this by
>having a global interrupt counter and restarting when the counter is a
>certain value.

You send the start condition using the controller to send a start then
the Read address. When your MCU is master you do not detect it you
generate it.

>I'm sure there must be a proper way of detecting when to restart but I
>can't figure out how. As far as my MCU goes, it still thinks it's in
>master transmitter mode after sending the device/word address, so I
>don't know how to tell it to restart at that point.

You do the following steps

        generate a start coindition
        transmit the read address,
        get ACK
        Change mode to receive
        Receive bytes
        last byte Set NOACK
        Send Stop

>Is it so hard to handle the handshaking for every MCU or am I just
>unlucky to be working with a Toshiba?

I think it is more to do with understanding of I2C and which end is
transmitting at what stage.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On 6 Dec, in article
     <1165401830.130900.269240@80g2000cwy.googlegroups.com>
     goister@gmail.com "galapogos" wrote:
>Paul Carpenter wrote:
>> On 5 Dec, in article
>>      <1165369825.395623.117700@n67g2000cwd.googlegroups.com>
>>      goister@gmail.com "galapogos" wrote:
>> >Paul Carpenter wrote:
>> >> On 4 Dec, in article
>> >>      <1165304918.361673.137080@16g2000cwy.googlegroups.com>
>> >>      goister@gmail.com "galapogos" wrote:
>> >> >galapogos wrote:
.....
>> >> First *ASSUMPTION* the first data byte of the 16 data bytes to send
>> >> should be 0x80 ?
>> >
>> >No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
>> >at all. In fact, I tried sending dummy constants but I always get 0x80
>> >instead.
>>
>> Are you sending a block of 16 bytes or 16 single byte read equences?
>
>I enter the MCU's ISR after each ACK sent/received. Each time I enter
>the ISR I send or receive 1 byte, so I guess I'm sending 16 single byte
>sequences?

No you are sending a block of 16 bytes. Just that I2C is slower than
the MCU. 

16 single byte reads would have an address sequence for each byte read
of one byte.

>> Check when changing to send first byte you change to transmit and have
>> set up everything and be sure it is in transmit mode before writing data
>> to controller.
>
>Actually I'm not even sure if I can even change the transmit direction
>on the fly. The control register that the transmit direction is at is
>shared with the status register, so within my ISR, I check to see if
>it's in transmit mode. If it is, then I'll send data, if not I'll
>receive. It's really up to the hardware to tell me if it's in transmit
>or receive mode AFAIK.

No it is up to you to change direction once you have acked the read address
being received.

....

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Paul Carpenter wrote:
> On 6 Dec, in article
>      <1165401830.130900.269240@80g2000cwy.googlegroups.com>
>      goister@gmail.com "galapogos" wrote:
> >Paul Carpenter wrote:
> >> On 5 Dec, in article
> >>      <1165369825.395623.117700@n67g2000cwd.googlegroups.com>
> >>      goister@gmail.com "galapogos" wrote:
> >> >Paul Carpenter wrote:
> >> >> On 4 Dec, in article
> >> >>      <1165304918.361673.137080@16g2000cwy.googlegroups.com>
> >> >>      goister@gmail.com "galapogos" wrote:
> >> >> >galapogos wrote:
> .....
> >> >> First *ASSUMPTION* the first data byte of the 16 data bytes to send
> >> >> should be 0x80 ?
> >> >
> >> >No, it is 0x00 to 0x10 in sequence. 0x80 isn't part of the data array
> >> >at all. In fact, I tried sending dummy constants but I always get 0x80
> >> >instead.
> >>
> >> Are you sending a block of 16 bytes or 16 single byte read equences?
> >
> >I enter the MCU's ISR after each ACK sent/received. Each time I enter
> >the ISR I send or receive 1 byte, so I guess I'm sending 16 single byte
> >sequences?
>
> No you are sending a block of 16 bytes. Just that I2C is slower than
> the MCU.
>
> 16 single byte reads would have an address sequence for each byte read
> of one byte.

OK

> >> Check when changing to send first byte you change to transmit and have
> >> set up everything and be sure it is in transmit mode before writing data
> >> to controller.
> >
> >Actually I'm not even sure if I can even change the transmit direction
> >on the fly. The control register that the transmit direction is at is
> >shared with the status register, so within my ISR, I check to see if
> >it's in transmit mode. If it is, then I'll send data, if not I'll
> >receive. It's really up to the hardware to tell me if it's in transmit
> >or receive mode AFAIK.
>
> No it is up to you to change direction once you have acked the read address
> being received.

So at the interrupt after the read address when i have something like
junk = buffer, i should do a if (junk = address) { change direction } ?