Let's talk about HCS08 I2C

[wu_jin_liang]

Hi everybody,

    These days I use MC9S08DZ60 to do my project and It need I2C to do communication.

I find this forum discuss this topic before,and the conclusion is that the I2C of hcs08 has bugs.

    Today I debug the i2c, but find it is OK in polled mode.

    here are my simple test code , read and write data with AT24C02.

   sorry , my English is rather bad, I hope you can  understand what I said.

[bigmac]

Hello,

I notice that the code the OP has posted actually concerns the SCI module, rather than the IIC (or I2C) module.

My personal preference is for my external EEPROM devices to have a SPI interface - this can be significantly faster than IIC communication, and the code is usually much simpler.

Regards,

Mac

[wu_jin_liang]

i sorry mac, the I2C code

[wu_jin_liang]

this is my first message in this forum,

I expect to communicate more with Embedded Engineers all over the world

[JimDon]

Not sure what you mean by "bugs" could you poin to the specific thread?

[wu_jin_liang]

nice to  meet you Jim,

    they said that the I2C of HCS08 is only can work in the interrupt mode, then in the polled mode, it can't work well,

it will take mistakes while read or write more then one byte continuous.

   but I just get it works in polled mode, and find it works well.

everyone who handle this I2C and find some strange mistake ,happy to discuss with you

[rocco]

Hi Wu Jin Liang,

Welcome to the forum.

I wouldn't necessarily say that the I2c has 'bugs' so much as to say that it is very poorly documented. If you write your code based on the data-sheet, it typically won't work. If you read the application notes, all of the pertinent forum threads and study the different code that has been posted here, then you might get something working.

So I now have three sets of routines that are now in production: an eeprom read system that operates in polled mode (used to load the boot-up configuration), an interrupt-driven multi-page write routine, and an interrupt-driven multi-page read routine. I could not have gotten it working without the tips and code from people on this forum. But at this point the I2C eeprom is working reliably, so i wouldn't call the problems 'bugs'. They're undocumented features.

[JimDon]

Like I said, or should have said, I have used Processor Expert to generate I2C code for several MCU families more than once and never has it failed to work, with the exception of the issue I mentioned above, which is not the fault of the MCU or the driver code.

I will agree it could be hard to figure it out from the spec sheet, but that is why Freescale provide Processor Expert for this cases.

[wu_jin_liang]

hi rocco,

    you are right,  I read the application notes before coding.

I think that get I2C in polled mode,and add the" unhung code" which brother Jim offered will be fine.

  thank you so much ,you are all very nice .  

[JimDon · Accepted solution]

I would never use it in polled mode. What's the point?

If you do polled can never do a transaction on an interrupt thread (like a timer tick).

I have not seen an issue with it myself, however there is this issue, which not the fault of the I2C  module.

If you reset the MCU in the middle of a send by the I2C device, it can appear hung up because it is waiting for the master to finish clocking it. The solution is to manually clock it until it lets goif the SDA line,.

Where is what I recommend you try - use Processor Expert to get the code working - interrupt driven.

Here is a hint for the unhang code, which is done befor initalizing the I2C unit:

void i2cdelay(int n);byte UnhangI2C(void);void i2cdelay(int n){  int i;  for( i = 0 ; i < n ; ++i)    asm {      nop ; nop ; nop ;nop    };}byte UnhangI2C(void){  int i = 0;  // This will clear out a "hung" I2C device  // by clocking away the low it may be asserting  // on SDA  PTCDD |= 3;  PTCPE |= 3;  PTCD  |= 1;  for( i = 0 ; i < 30 ; ++i )    {      i2cdelay(5000);      PTCD ^= 1;      // if the clock is hi, raise SDA      // to send a stop.      i2cdelay(2500);      if(PTCD & 1)        PTCD |= 2;      else        PTCD &= ~2;        }  // Now make them inputs, should both be high.    PTCDD &= ~3;  i2cdelay(1);  return PTCD & 3;  }