Problem with I2C

Hi,
I'm trying to interface a Toshiba 16bit MCU with another IC(call this
IC2), with the MCU being a slave transmitter.  The IC2 expects a slave
EEPROM at a certain address, and I've setup the MCU to be at this
address. The problem is that the MCU isn't interrupting or
acknowledging the signals all the time. I've looked at the SDA/SCL
waveforms and while IC2 is sending the first device address(with wr
direction), the MCU doesn't ACK the address, even though it does
interrupt at the end of the address. IC2 hence immediately sends the
device address again, and only this time does the MCU ACK it. This is
followed by a dummy word address(0x00) then another device address(with
rd direction), and the actual 16 byte data.

At the end of each of the addresses, the MCU is interrupting, as well
as the end of the 1st data byte, but after that the MCU stops going
into the ISR, so IC2 is getting all 0xff which is wrong. In fact, even
the 1st data byte is wrong even though I write the data into the serial
buffer in the ISR.

Does anyone know what could be wrong? This is the first time I'm
working with I2C and isn't as straightfoward as I thought.

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), 

More commonly known as the "master".

>with the MCU being a slave transmitter.  The IC2 expects a slave
>EEPROM at a certain address, and I've setup the MCU to be at this
>address. The problem is that the MCU isn't interrupting or
>acknowledging the signals all the time. I've looked at the SDA/SCL
>waveforms and while IC2 is sending the first device address(with wr
>direction), the MCU doesn't ACK the address, even though it does
>interrupt at the end of the address.

Perhaps the slave is not initializing to the proper state.  Consider
having the master generate a signal sequence to 'reset' the I2C bus.
Is the master generating a proper start condition? 

>IC2 hence immediately sends the
>device address again, and only this time does the MCU ACK it. 

More evidence that one or the other end is not initializing properly.

>This is
>followed by a dummy word address(0x00) then another device address(with
>rd direction), and the actual 16 byte data.

The master does not send "the actual 16 byte data" during a read.  It
only supplies the clock (which the slave is allowed to stretch).  The
slave (the device read from) supplies the data during the read.

>At the end of each of the addresses, the MCU is interrupting, as well
>as the end of the 1st data byte, but after that the MCU stops going
>into the ISR, so IC2 is getting all 0xff which is wrong. In fact, even
>the 1st data byte is wrong even though I write the data into the serial
>buffer in the ISR.

It's hard to provide meaningful feedback regarding these low level
details without knowing what MCU you are using and seeing your code.

-- 
Dan Henry

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),
>
> More commonly known as the "master".
Yup, IC2 is the master receiver in the data transaction

> >with the MCU being a slave transmitter.  The IC2 expects a slave
> >EEPROM at a certain address, and I've setup the MCU to be at this
> >address. The problem is that the MCU isn't interrupting or
> >acknowledging the signals all the time. I've looked at the SDA/SCL
> >waveforms and while IC2 is sending the first device address(with wr
> >direction), the MCU doesn't ACK the address, even though it does
> >interrupt at the end of the address.
>
> Perhaps the slave is not initializing to the proper state.  Consider
> having the master generate a signal sequence to 'reset' the I2C bus.
> Is the master generating a proper start condition?

Perhaps.I'm following the MCU's datasheet as best I can but it isn't
very comprehensive. I can't have the master generate anything since
it's fixed function ASIC that sends the I2C signals once it receives
its reset signal. I have however verified that the signals do
correspond correctly to the intended behavior, i.e. it matches the
waveform on the datasheet exactly except for the resent device address.

> >IC2 hence immediately sends the
> >device address again, and only this time does the MCU ACK it.
>
> More evidence that one or the other end is not initializing properly.
>
> >This is
> >followed by a dummy word address(0x00) then another device address(with
> >rd direction), and the actual 16 byte data.
>
> The master does not send "the actual 16 byte data" during a read.  It
> only supplies the clock (which the slave is allowed to stretch).  The
> slave (the device read from) supplies the data during the read.

Yes I know that. The slave isn't sending the actual data though.

> >At the end of each of the addresses, the MCU is interrupting, as well
> >as the end of the 1st data byte, but after that the MCU stops going
> >into the ISR, so IC2 is getting all 0xff which is wrong. In fact, even
> >the 1st data byte is wrong even though I write the data into the serial
> >buffer in the ISR.
>
> It's hard to provide meaningful feedback regarding these low level
> details without knowing what MCU you are using and seeing your code.

The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
16bit TLCS-900/L1 series.

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),
>>
>> More commonly known as the "master".
>Yup, IC2 is the master receiver in the data transaction
>
>> >with the MCU being a slave transmitter.  The IC2 expects a slave
>> >EEPROM at a certain address, and I've setup the MCU to be at this
>> >address. The problem is that the MCU isn't interrupting or
>> >acknowledging the signals all the time. I've looked at the SDA/SCL
>> >waveforms and while IC2 is sending the first device address(with wr
>> >direction), the MCU doesn't ACK the address, even though it does
>> >interrupt at the end of the address.
>>
>> Perhaps the slave is not initializing to the proper state.  Consider
>> having the master generate a signal sequence to 'reset' the I2C bus.
>> Is the master generating a proper start condition?
>
>Perhaps.I'm following the MCU's datasheet as best I can but it isn't
>very comprehensive. I can't have the master generate anything since
>it's fixed function ASIC that sends the I2C signals once it receives
>its reset signal. I have however verified that the signals do
>correspond correctly to the intended behavior, i.e. it matches the
>waveform on the datasheet exactly except for the resent device address.

No the RESENT device address is correct you are NOT decoding it correctly
and examining the EEPROM datasheet on how it is accessed. The vast majority
of I2C EEPROM devices MUST be addressed in this way to perform a random read
of any location in the I2C EEPROM. Basic structure of random read to EEPROM

        Send I2C device address as WRITE
        Send INTERNAL EEPROM address
        Stop or send start condition
        Send I2C device address as READ
        Read one or more bytes of data.

This done as every byte read from an EEPROM increments its INTERNAL
address pointer.

>> >IC2 hence immediately sends the
>> >device address again, and only this time does the MCU ACK it.
>>
>> More evidence that one or the other end is not initializing properly.

The slave MCU is not handling I2C correctly, for many reasons. You have
not said how the I2C is handled in this MCU is it by a special controller
bit banging software or other software?

>> >This is
>> >followed by a dummy word address(0x00) then another device address(with
>> >rd direction), and the actual 16 byte data.

See above as they obviously only want to read location 00 and 01. Basically
as the EEPROM's internal address pointer would read out address 02 at the
next read, so to read address 00 again requires setting the internal counter
back to 0 or reading enough bytes for the internal counter to wraparound.

>> The master does not send "the actual 16 byte data" during a read.  It
>> only supplies the clock (which the slave is allowed to stretch).  The
>> slave (the device read from) supplies the data during the read.
>
>Yes I know that. The slave isn't sending the actual data though.

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.

I have seen some ASICs that access I2C EEPROMs, and the timing leaves a lot
to be desired for meeting the I2C or I2C EEPROM specs. Even saw one where
analysis shows that the timing of I2C clock (SCL) changed during an EEPROM
write data cycle where the 8 clock cycles for the byte written had a clock
speed twice as fast as any other transaction. Things like that can screw up
some badly designed I2C controllers. I have seen some ASICs not send correct
ACKs or even ignore ALL ACKs, so carry on regardless even if no EEPROM
present.
   
>> >At the end of each of the addresses, the MCU is interrupting, as well
>> >as the end of the 1st data byte, but after that the MCU stops going
>> >into the ISR, so IC2 is getting all 0xff which is wrong. In fact, even
>> >the 1st data byte is wrong even though I write the data into the serial
>> >buffer in the ISR.

This suggests your software is not processing I2C transactions correctly
and reenabling interupts or doing two reads BEFORE the data has arrived.

Altenatively the hardware controller cannot handle the I2C transactions
from the ASIC correctly.

>> It's hard to provide meaningful feedback regarding these low level
>> details without knowing what MCU you are using and seeing your code.
>
>The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
>16bit TLCS-900/L1 series.

Does it have a built in I2C controller?

Is the data sheet easily available on the web?

What is your code for handling the I2C functions?

I strongly suspect your code for this.

-- 
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 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),
> >>
> >> More commonly known as the "master".
> >Yup, IC2 is the master receiver in the data transaction
> >
> >> >with the MCU being a slave transmitter.  The IC2 expects a slave
> >> >EEPROM at a certain address, and I've setup the MCU to be at this
> >> >address. The problem is that the MCU isn't interrupting or
> >> >acknowledging the signals all the time. I've looked at the SDA/SCL
> >> >waveforms and while IC2 is sending the first device address(with wr
> >> >direction), the MCU doesn't ACK the address, even though it does
> >> >interrupt at the end of the address.
> >>
> >> Perhaps the slave is not initializing to the proper state.  Consider
> >> having the master generate a signal sequence to 'reset' the I2C bus.
> >> Is the master generating a proper start condition?
> >
> >Perhaps.I'm following the MCU's datasheet as best I can but it isn't
> >very comprehensive. I can't have the master generate anything since
> >it's fixed function ASIC that sends the I2C signals once it receives
> >its reset signal. I have however verified that the signals do
> >correspond correctly to the intended behavior, i.e. it matches the
> >waveform on the datasheet exactly except for the resent device address.
>
> No the RESENT device address is correct you are NOT decoding it correctly
> and examining the EEPROM datasheet on how it is accessed. The vast majority
> of I2C EEPROM devices MUST be addressed in this way to perform a random read
> of any location in the I2C EEPROM. Basic structure of random read to EEPROM
>
>         Send I2C device address as WRITE
>         Send INTERNAL EEPROM address
>         Stop or send start condition
>         Send I2C device address as READ
>         Read one or more bytes of data.
>
> This done as every byte read from an EEPROM increments its INTERNAL
> address pointer.

Yes, this is exactly what the master IC is doing, so the master's doing
it correctly. The internal EEPROM word address is a dummy address of
0x00

> >> >IC2 hence immediately sends the
> >> >device address again, and only this time does the MCU ACK it.
> >>
> >> More evidence that one or the other end is not initializing properly.
>
> The slave MCU is not handling I2C correctly, for many reasons. You have
> not said how the I2C is handled in this MCU is it by a special controller
> bit banging software or other software?

The MCU has an I2C controller, so I'm not bit banging it.

> >> >This is
> >> >followed by a dummy word address(0x00) then another device address(with
> >> >rd direction), and the actual 16 byte data.
>
> See above as they obviously only want to read location 00 and 01. Basically
> as the EEPROM's internal address pointer would read out address 02 at the
> next read, so to read address 00 again requires setting the internal counter
> back to 0 or reading enough bytes for the internal counter to wraparound.
>
> >> The master does not send "the actual 16 byte data" during a read.  It
> >> only supplies the clock (which the slave is allowed to stretch).  The
> >> slave (the device read from) supplies the data during the read.
> >
> >Yes I know that. The slave isn't sending the actual data though.
>
> 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.
>
> I have seen some ASICs that access I2C EEPROMs, and the timing leaves a lot
> to be desired for meeting the I2C or I2C EEPROM specs. Even saw one where
> analysis shows that the timing of I2C clock (SCL) changed during an EEPROM
> write data cycle where the 8 clock cycles for the byte written had a clock
> speed twice as fast as any other transaction. Things like that can screw up
> some badly designed I2C controllers. I have seen some ASICs not send correct
> ACKs or even ignore ALL ACKs, so carry on regardless even if no EEPROM
> present.
>
> >> >At the end of each of the addresses, the MCU is interrupting, as well
> >> >as the end of the 1st data byte, but after that the MCU stops going
> >> >into the ISR, so IC2 is getting all 0xff which is wrong. In fact, even
> >> >the 1st data byte is wrong even though I write the data into the serial
> >> >buffer in the ISR.
>
> This suggests your software is not processing I2C transactions correctly
> and reenabling interupts or doing two reads BEFORE the data has arrived.
>
> Altenatively the hardware controller cannot handle the I2C transactions
> from the ASIC correctly.

Yup, I'm pretty sure it's the software but I'm just not sure how to fix
it.

> >> It's hard to provide meaningful feedback regarding these low level
> >> details without knowing what MCU you are using and seeing your code.
> >
> >The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
> >16bit TLCS-900/L1 series.
>
> Does it have a built in I2C controller?

Yes

> Is the data sheet easily available on the web?

Yes, it is available at
http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TMP91CP27UG+%232

The exact datasheet isn't available on that page, but datasheets for
identical MCUs can be obtained at
http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TMP91FY27U+**
and
http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TMP91CP27U

> What is your code for handling the I2C functions?
>
> I strongly suspect your code for this.

Yup I'm pretty sure it's my code too since this is the first time I'm
writing I2C code. I'm just not sure what's wrong, or even what I need
to do. Basically what I'm doing is I have an initI2C function that
initializes the SFRs to the desired values(8bit word, ACK generation,
slave transmitter operation mode, setting of the slave address, etc),
and then I have a serial interrupt service routine that checks the
various status bits and decides what to do in each case.

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),
.....
>> >> having the master generate a signal sequence to 'reset' the I2C bus.
>> >> Is the master generating a proper start condition?
>> >
>> >Perhaps.I'm following the MCU's datasheet as best I can but it isn't
>> >very comprehensive. I can't have the master generate anything since
>> >it's fixed function ASIC that sends the I2C signals once it receives
>> >its reset signal. I have however verified that the signals do
>> >correspond correctly to the intended behavior, i.e. it matches the
>> >waveform on the datasheet exactly except for the resent device address.
>>
>> No the RESENT device address is correct you are NOT decoding it correctly
>> and examining the EEPROM datasheet on how it is accessed. The vast majority
>> of I2C EEPROM devices MUST be addressed in this way to perform a random read
>> of any location in the I2C EEPROM. Basic structure of random read to EEPROM
>>
>>         Send I2C device address as WRITE
>>         Send INTERNAL EEPROM address
>>         Stop or send start condition
>>         Send I2C device address as READ
>>         Read one or more bytes of data.
>>
>> This done as every byte read from an EEPROM increments its INTERNAL
>> address pointer.
>
>Yes, this is exactly what the master IC is doing, so the master's doing
>it correctly. The internal EEPROM word address is a dummy address of
>0x00

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.

...
>> 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 have seen some ASICs that access I2C EEPROMs, and the timing leaves a lot
>> to be desired for meeting the I2C or I2C EEPROM specs. Even saw one where
>> analysis shows that the timing of I2C clock (SCL) changed during an EEPROM
>> write data cycle where the 8 clock cycles for the byte written had a clock
>> speed twice as fast as any other transaction. Things like that can screw up
>> some badly designed I2C controllers. I have seen some ASICs not send correct
>> ACKs or even ignore ALL ACKs, so carry on regardless even if no EEPROM
>> present.

...
>> This suggests your software is not processing I2C transactions correctly
>> and reenabling interupts or doing two reads BEFORE the data has arrived.
>>
>> Altenatively the hardware controller cannot handle the I2C transactions
>> from the ASIC correctly.
>
>Yup, I'm pretty sure it's the software but I'm just not sure how to fix
>it.
>
>> >> It's hard to provide meaningful feedback regarding these low level
>> >> details without knowing what MCU you are using and seeing your code.
>> >
>> >The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
>> >16bit TLCS-900/L1 series.
>>
>> Does it have a built in I2C controller?
>
>Yes
>
>> Is the data sheet easily available on the web?
>
>Yes, it is available at
>http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
>P91CP27UG+%232

Will see if I can get it later.

>The exact datasheet isn't available on that page, but datasheets for
>identical MCUs can be obtained at
>http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
>P91FY27U+**
>and
>http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
>P91CP27U

There may be slight differences between the I2C controller implementations
between MCU's or they could be the same. This is an unknown.

>> What is your code for handling the I2C functions?
>>
>> I strongly suspect your code for this.
>
>Yup I'm pretty sure it's my code too since this is the first time I'm
>writing I2C code. I'm just not sure what's wrong, or even what I need
>to do. Basically what I'm doing is I have an initI2C function that
>initializes the SFRs to the desired values(8bit word, ACK generation,
>slave transmitter operation mode, setting of the slave address, etc),
>and then I have a serial interrupt service routine that checks the
>various status bits and decides what to do in each case.

You have an understanding problem here, hence the data corruption.

Sequence in ROUGH OUTLINE

   Init controller (slave address, ACk generation
                         SLAVE RECEIVER mode)

   Interupt routine
        Address decode WRITE (ASIC writes to EEPROM)
           Leave in RECEIVER mode and receive all bytes and
           action first 'n' bytes as address to 'write' to
           (EEPROM internal address) you will need a volatile
           to store the pseudo address pointer.
           Any further bytes you will have to store in you EEPROM
           emulation (if the ASIC does writes).
        Stop
           End transaction
        READ no ack
           END transaction
        Start/Repeated start
           Stay in slave Receiver

        Address decode READ (ASIC reads from EEPROM)
           Set mode SLAVE TRANSMITTER
           For subsequent data bytes
              Send byte pointed to by pseudo address pointer
              Increment psudo address transmitter

        Error conditions
           END transaction and set some error flag in your software

How you determine end of I2C transaction and signal to your software
depends on many other attributes.

You are reading 0xFF mainly because you are transmitting when you should
be receiving!

-- 
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 3 Dec 2006 01:46:16 -0800, "galapogos" <goister@gmail.com> 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),
>>
>> More commonly known as the "master".
>Yup, IC2 is the master receiver in the data transaction
>
>> >with the MCU being a slave transmitter.

===SNIP===

>> >IC2 hence immediately sends the
>> >device address again, and only this time does the MCU ACK it.
>>
>> More evidence that one or the other end is not initializing properly.

===SNIP===

>> It's hard to provide meaningful feedback regarding these low level
>> details without knowing what MCU you are using and seeing your code.
>
>The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
>16bit TLCS-900/L1 series.

Although I've now taken a glance at the datashtte, It's hard to
provide meaningful feedback regarding these low level details without
seeing your code.

You did say above that you are initializing to slave transmitter mode.
I assume that to mean that SBIOCR2<TRX>=1.  I would think you'd want
to initialize the slave to be a receiver first (SBIOCR2<TRX>=0), then
let the hardware control TRX like it says in 3.11.5(6).

-- 
Dan Henry

galapogos wrote:

> Yes, this is exactly what the master IC is doing, so the master's doing
> it correctly. The internal EEPROM word address is a dummy address of
> 0x00

Does the slave EEPROM require 8bit or 16 bit addresses?


-- 
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

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),
> .....
> >> >> having the master generate a signal sequence to 'reset' the I2C bus.
> >> >> Is the master generating a proper start condition?
> >> >
> >> >Perhaps.I'm following the MCU's datasheet as best I can but it isn't
> >> >very comprehensive. I can't have the master generate anything since
> >> >it's fixed function ASIC that sends the I2C signals once it receives
> >> >its reset signal. I have however verified that the signals do
> >> >correspond correctly to the intended behavior, i.e. it matches the
> >> >waveform on the datasheet exactly except for the resent device address.
> >>
> >> No the RESENT device address is correct you are NOT decoding it correctly
> >> and examining the EEPROM datasheet on how it is accessed. The vast majority
> >> of I2C EEPROM devices MUST be addressed in this way to perform a random read
> >> of any location in the I2C EEPROM. Basic structure of random read to EEPROM
> >>
> >>         Send I2C device address as WRITE
> >>         Send INTERNAL EEPROM address
> >>         Stop or send start condition
> >>         Send I2C device address as READ
> >>         Read one or more bytes of data.
> >>
> >> This done as every byte read from an EEPROM increments its INTERNAL
> >> address pointer.
> >
> >Yes, this is exactly what the master IC is doing, so the master's doing
> >it correctly. The internal EEPROM word address is a dummy address of
> >0x00
>
> 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.

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

> >> I have seen some ASICs that access I2C EEPROMs, and the timing leaves a lot
> >> to be desired for meeting the I2C or I2C EEPROM specs. Even saw one where
> >> analysis shows that the timing of I2C clock (SCL) changed during an EEPROM
> >> write data cycle where the 8 clock cycles for the byte written had a clock
> >> speed twice as fast as any other transaction. Things like that can screw up
> >> some badly designed I2C controllers. I have seen some ASICs not send correct
> >> ACKs or even ignore ALL ACKs, so carry on regardless even if no EEPROM
> >> present.
>
> ...
> >> This suggests your software is not processing I2C transactions correctly
> >> and reenabling interupts or doing two reads BEFORE the data has arrived.
> >>
> >> Altenatively the hardware controller cannot handle the I2C transactions
> >> from the ASIC correctly.
> >
> >Yup, I'm pretty sure it's the software but I'm just not sure how to fix
> >it.
> >
> >> >> It's hard to provide meaningful feedback regarding these low level
> >> >> details without knowing what MCU you are using and seeing your code.
> >> >
> >> >The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
> >> >16bit TLCS-900/L1 series.
> >>
> >> Does it have a built in I2C controller?
> >
> >Yes
> >
> >> Is the data sheet easily available on the web?
> >
> >Yes, it is available at
> >http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
> >P91CP27UG+%232
>
> Will see if I can get it later.

Thanks!

> >The exact datasheet isn't available on that page, but datasheets for
> >identical MCUs can be obtained at
> >http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
> >P91FY27U+**
> >and
> >http://www.semicon.toshiba.co.jp/openb2b/websearch/productDetails.jsp?partKey=TM
> >P91CP27U
>
> There may be slight differences between the I2C controller implementations
> between MCU's or they could be the same. This is an unknown.

I'm pretty sure they are the same. The only differences is that one is
a mask version and the other is a flash version as well as differences
in memory size, but I will check my datasheets again.

> >> What is your code for handling the I2C functions?
> >>
> >> I strongly suspect your code for this.
> >
> >Yup I'm pretty sure it's my code too since this is the first time I'm
> >writing I2C code. I'm just not sure what's wrong, or even what I need
> >to do. Basically what I'm doing is I have an initI2C function that
> >initializes the SFRs to the desired values(8bit word, ACK generation,
> >slave transmitter operation mode, setting of the slave address, etc),
> >and then I have a serial interrupt service routine that checks the
> >various status bits and decides what to do in each case.
>
> You have an understanding problem here, hence the data corruption.
>
> Sequence in ROUGH OUTLINE
>
>    Init controller (slave address, ACk generation
>                          SLAVE RECEIVER mode)
>
>    Interupt routine
>         Address decode WRITE (ASIC writes to EEPROM)
>            Leave in RECEIVER mode and receive all bytes and
>            action first 'n' bytes as address to 'write' to
>            (EEPROM internal address) you will need a volatile
>            to store the pseudo address pointer.
>            Any further bytes you will have to store in you EEPROM
>            emulation (if the ASIC does writes).
>         Stop
>            End transaction
>         READ no ack
>            END transaction
>         Start/Repeated start
>            Stay in slave Receiver
>
>         Address decode READ (ASIC reads from EEPROM)
>            Set mode SLAVE TRANSMITTER
>            For subsequent data bytes
>               Send byte pointed to by pseudo address pointer
>               Increment psudo address transmitter
>
>         Error conditions
>            END transaction and set some error flag in your software
>
> How you determine end of I2C transaction and signal to your software
> depends on many other attributes.
>
> You are reading 0xFF mainly because you are transmitting when you should
> be receiving!

You mean the master IC is transmitting rather than the MCU? I don't
think that's possible since it's a fixed function ASIC. My MCU is
supposed to be the one transmitting, but I'm not getting any interrupts
for me to put any data into the serial buffer for sending.

Dan Henry wrote:
> On 3 Dec 2006 01:46:16 -0800, "galapogos" <goister@gmail.com> 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),
> >>
> >> More commonly known as the "master".
> >Yup, IC2 is the master receiver in the data transaction
> >
> >> >with the MCU being a slave transmitter.
>
> ===SNIP===
>
> >> >IC2 hence immediately sends the
> >> >device address again, and only this time does the MCU ACK it.
> >>
> >> More evidence that one or the other end is not initializing properly.
>
> ===SNIP===
>
> >> It's hard to provide meaningful feedback regarding these low level
> >> details without knowing what MCU you are using and seeing your code.
> >
> >The MCU that I'm using is a Toshiba tmp91cp27ug. It's part of Toshiba's
> >16bit TLCS-900/L1 series.
>
> Although I've now taken a glance at the datashtte, It's hard to
> provide meaningful feedback regarding these low level details without
> seeing your code.
>
> You did say above that you are initializing to slave transmitter mode.
> I assume that to mean that SBIOCR2<TRX>=1.  I would think you'd want
> to initialize the slave to be a receiver first (SBIOCR2<TRX>=0), then
> let the hardware control TRX like it says in 3.11.5(6).

My ISR is basically implementing that table in the datasheet. Based on
the status register bits I'm following what the table says, but as you
can probably tell the english isn't very good and I'm having trouble
understanding some of the details. Also, either SBIOCR1 or CR2 also
doubles as SBIOSR, so it's both read and write. So you're saying I
should treat SBIOCR2<TRX> as a status bit rather than a control bit?