8-bit MicrocontrollersのトピックRe: AW32: I2C Problem

AW32: I2C Problem

BasePointer — Thu, 29 Oct 2020 08:46:01 GMT

Hi,

First of all, Freescale, I hate your datasheets !

But I like the forum, anyway...

I'm living interesting problem with I2C and EEPROM AT24C512BN.

If I debug test routine below, it works, "count" be equal to "okunan".

If I directly run the code, it fails at EE_ReadBuffer function. The function returns 0.

Code:

Test routine:  count = 0x89654321;  // unsigned long

  Init_i2c();  if(EE_WriteBuffer(0, &count, 4, I2C_ADR_EEPROM0))        DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 1);  if(EE_ReadBuffer(0, &okunan, 4, I2C_ADR_EEPROM0))        DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 2);    if(count == okunan)    DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 3);

If I change the i2c_start() function such as below: It start working in debug or not.

Code:

void i2c_start(void){  IIC1S_SRW = 0; // R/W bit = 0;  IIC1C_IICEN = 0;  IIC1C = 0b10011000;    IIC1C_MST = 1; // generate START condition}

I don't understand the problem due to the datasheet doesn't explain I2C module well.
Regards,

BP.

Code:

void Init_i2c(void){  // Bus = 18.432MHz;  // mul=4, ICR=0x0D => SCL Div=48, i2c_ Bus Freq = 96Khz, SDA Hold Time = 600ns  IIC1F = 0b10001101;  IIC1S_SRW = 0; // R/W bit = 0;  // Enable i2c module  // not generate ACK by master after transfer;  // TX mode  // Slave mode actually;  IIC1C = 0b10011000;  }void i2c_start(void){  IIC1C_MST = 1; // generate START condition}void i2c_stop(void){  IIC1C_MST = 0; // generate STOP condition;  }void i2c_restart(void){  IIC1C_RSTA = 1; // generate RESTART condition}void i2c_sendbyte(unsigned char data){  IIC1C_TX = 1; // transmit    IIC1D = data;  while(!IIC1S_IICIF); // wait until Transfer to complete;    IIC1S_IICIF = 1;}char i2c_getack(void){  return(!IIC1S_RXAK); // ACK gelmiş ise 1 döner, gelmemişse 0}unsigned char i2c_getbyte(char send_ack){  unsigned char data;    IIC1C_TX = 0; // set up to receive;    IIC1C_TXAK = send_ack—0:1;    data = IIC1D; // dummy read;  while(!IIC1S_IICIF); // wait until Transfer to complete;    IIC1S_IICIF = 1;    data = IIC1D; // read right data;    return(data);}/////////////////////////////////////////////////////////////////////////////////// EEPROM RUTINLERI Atmel AT24C512BN-SH-B veya ST M24512-RM/////////////////////////////////////////////////////////////////////////////////unsigned char EE_WaitForACK(unsigned char external_adr){  unsigned char counter = 100;    unsigned char ack;  unsigned char ControlByte = 0b10100000; // Yazma modu, A2, A1, A0 = 0    ControlByte |= ((external_adr << 1) & 0b00001110);    do  {    i2c_start();    i2c_sendbyte(ControlByte);    ack = i2c_getack(); // i2cgetack, ack alınmış ise 1 döner!    i2c_stop();      --counter; // her deneme 175uS sürüyor, 29 deneme > 5ms yapar.  } while(!ack && (counter != 0));    return(ack);}unsigned char EE_ReadBuffer(unsigned int Adr, unsigned char* Data, unsigned int size, unsigned char external_adr){  // Control Byte = 1 0 1 0 A2 A1 A0 R/W. unsigned char ControlByte = 0b10100000; // Yazma modu, A2, A1, A0 = 0 unsigned char AddrHigh = (Adr >> 8) & 0xFF; unsigned char AddrLow = (Adr & 0xFF);  ControlByte |= ((external_adr << 1) & 0b00001110);  i2c_start();  // Control Byte = 1 0 1 0 A2 A1 A0 R/W  i2c_sendbyte(ControlByte); if(!i2c_getack()) {  i2c_stop();  return(0); } // Address High Byte i2c_sendbyte(AddrHigh); if(!i2c_getack()) {  i2c_stop();  return(0); } // Address Low Byte i2c_sendbyte(AddrLow); if(!i2c_getack()) {  i2c_stop();  return(0); } // Read i2c_restart();  // Control Byte to read ControlByte |= 0b00000001; // Okuma modu i2c_sendbyte(ControlByte); if(!i2c_getack())  {  i2c_stop();  return(0); } do {  *Data++ = i2c_getbyte(size != 1);   } while(--size);  i2c_stop();  return(1);}char EE_WriteBuffer(unsigned int Adr, unsigned char* Data, unsigned int size, unsigned char external_adr){ unsigned int _PAGE = 0xFFFF; // önceki page  do  {     unsigned int CURRENT_PAGE = Adr & 0b1111111110000000; // page size 128 byte    if(CURRENT_PAGE != _PAGE)  {      // Control Byte = 1 0 1 0 A2 A1 A0 R/W.     unsigned char ControlByte = 0b10100000; // Yazma modu, A2, A1, A0 = 0     unsigned char AddrHigh = (Adr >> 8) & 0xFF;     unsigned char AddrLow = (Adr & 0xFF);          ControlByte |= ((external_adr << 1) & 0b00001110);      if(_PAGE != 0xFFFF)   {    i2c_stop();        if(!EE_WaitForACK(external_adr))       return(0);   }      i2c_start();    // Control Byte = 1 0 1 0 A2 A1 A0 R/W.   i2c_sendbyte(ControlByte);   if(!i2c_getack())   {    i2c_stop();        return(0);   }   // Address High Byte   i2c_sendbyte(AddrHigh);   if(!i2c_getack())   {    i2c_stop();        return(0);   }   // Address Low Byte   i2c_sendbyte(AddrLow);   if(!i2c_getack())   {    i2c_stop();        return(0);   }      _PAGE = CURRENT_PAGE;     } //if(CURRENT_PAGE != _PAGE)    i2c_sendbyte(*Data++);  if(!i2c_getack())  {   i2c_stop();   return(0);  }    Adr++; } while(--size); i2c_stop();  return(EE_WaitForACK(external_adr));}

Message Edited by BasePointer on 2007-09-12 04:50 PM

Re: AW32: I2C Problem

Witztronics — Thu, 13 Sep 2007 08:04:09 GMT

Take a look at AN3291.

It explains everything you need to know to use the I2C on the HC(S)08 and HC(S)12 devices.

http://www.freescale.com/files/microcontrollers/doc/app_note/AN3291.pdf?srch=1

Re: AW32: I2C Problem

PeterHouse — Thu, 13 Sep 2007 20:25:02 GMT

Beware of the I2C module. I worked on a project two years ago using the GB60 and a Dallas DS2482-800 as the only two devices on the bus. While working with the Dallas engineers we came upon an issue where the Dallas state machine and the GB60 were incompatible. The GB60 would hang the SDA line low until a power cycle and there was no way to tell from the firmware what the problem was other than communications had stopped. The I2C module was made for interrupt use only and if an event did not generate an interrup there was no way to poll the state of the I2C module for recovery information.

At the time, I could not get a freescale support engineer on the phone and could only communicate by email about once every day or so which was taking too long. The GB60 is one of the first Freescale CPUs to have I2C and the I2C module was ported over from the S12. The only sample cade was for the S12 which had slightly different naming conventions and slightly different signaling which made the code essentially useless.

I was programming using Bytecraft C and ended up writing an I2C assembler bit bang library to handle the DS2482. This works flawlessly.

I am sure this has been fixed since I reported it in detail with code samples and logic analyzer captures to the Freescale engineer I was in emailing at the time.

Good Luck,

Peter House

Re: AW32: I2C Problem

BasePointer — Sat, 15 Sep 2007 02:02:24 GMT

Hi Peter,

I think I2C Module of AW32 still has some problems. It is not working stabile, it work for first usage but doesn't for second and later... Exactly you mentioned, sometimes SDA line is hanged at low. I don't know why. In spite of setting whole I2C control byte(IICC) at a time, it sometimes doesn't generate start, stop or set IICIF flag.

I implemented my own software I2C routines without using I2C Module. I have 4 device on the bus, two EEPROMs, one RTC and one temperature measurement IC. All works flawlessly now.

PS: Suggested application note also didn't worked for me. I wonder why writter of this application note try to set SRW that was indicated as read only in the datasheet? I also would like to ask that what happens if slave on the bus can't send the ACK, while(RXAK)?

Regards,

BP.

Re: AW32: I2C Problem

JMAC — Tue, 18 Sep 2007 11:51:02 GMT

Hi folks.

I just burned the last week discovering the same thing on an AW60. I attempted to replace a previously working bit-bang routine with an LCD driver and EEPROM on the same IIC bus. However, trying to run the IIC in a polled mode in combination with an RTI interrupt timer results in some very strange problems in the IIC module. Perhaps its me, but the docs on working with this module are really poor. I can get the RTI timer to run fine, and seperately, I can get the IIC to work fine most of the time, but I can never get them to run together with the IIC polled. As much as I would love to hammer out the code details on this, I'm already behind because of this problem.

Re: AW32: I2C Problem

PeterHouse — Tue, 18 Sep 2007 20:04:44 GMT

JMAC,

As I recall the IIC module on the GB60 did not have enough flags to run in polled mode. There are interrupts with no way to tell if they fired without interrupt code. I would never recommend running a module of this complexity in polled mode when a working interrupt mode is available.

Unfortunately, as far as I can tell, there is no working, reliable interrupt mode in the GB60 IIC peripheral and polling is not an option.

I do not know if the AW60 IIC module is the same as the GB60. If you can run it polled then it must have more status flags available and is possibly a different module. If your application is not CPU bound then I would consider a bit-bang approach.

I did not write a general purpose IIC module as I had only a single IIC device to with which to communicate. Otherwise, I would offer my IIC code.

Peter House

Re: AW32: I2C Problem

BasePointer — Sat, 22 Sep 2007 19:36:46 GMT

Hi,

Did freescale release any errata for this?

If not, they should provide us a sample code that works.

I've searched the forum and saw that a lot of developers lived similar problems with I2C module.

Regards,

BP.

Re: AW32: I2C Problem

Fonsi — Wed, 26 Sep 2007 20:50:43 GMT

Hi,

I am not sure if you have resolved your I2C issue but it is somewhat difficult to debug code via emails. I can speculate and make suggestion.

I always advice I2C customers to run the module in Interrupt driven mode but if they must run in polled mode to make sure and place some delays between bytes and start and stop symbols. I have written I2C polled routines in the past and what I noticed is that Start and Stop symbols delays are needed. There is also hardware considerations one must take into account to make sure that you avoid getting LOAs and the Master is forced into slave mode. In and ideal world the code you present should work without a problem, but we never design in that environment.

If you are still having problems, please submit a technical service request and we will help you resolve your issue.

Issues we need to consider:

1. Is your bit rate correctly and compliant with your peripheral device?

2. Is your hardware set up correctly?

Regards,

Edgar Saenz.

TIC 16 bit Team Leader.

Re: AW32: I2C Problem

BasePointer — Thu, 29 Oct 2020 08:46:03 GMT

Hi Edgar,

I added some delay after start and stop. You can see my last implementation below. Unfortunately, it is still not working for the second time. That means EE_WriteBuffer function (1) in test routine returns 1 but the EE_ReadBuffer function (2) never returns and crash at i2c_waitforflag. TCF never sets there.

My hardware (10Kohm pull-up on SCL and SDA) is working with my IIC software implementation.

Related EEPROMs support communication speed up to 400kHz, my hardware is so, too. (there is no caps on the bus) Oscilloscope output of the bus seems clean. I try communication at 100kHz.

Regards,

Code:

  Test routine:  count = 0x89654321;  if(EE_WriteBuffer(0, &count, 4, I2C_ADR_EEPROM0))  ...........1      DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 1);  if(EE_ReadBuffer(0, &okunan, 4, I2C_ADR_EEPROM0))  ...........2        DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 2);    if(count == okunan)    DispMsg(MSG_FILL, 0);  else DispMsg(MSG_ERROR_CODE, 3);

Code:

void Wait_sh(unsigned char time){   unsigned int i, temp_t = time;   for (i=0;i<temp_t;i++)      {      asm nop;      }}void Init_I2C(void){  // Bus = 18.432MHz;  // mul=4, ICR=0x0D => SCL Div=48, i2c_ Bus Freq = 96Khz, SDA Hold Time = 600ns    IIC1C = 0;/*  PTCD_PTCD0 = 0;  PTCD_PTCD0 = 0;    PTCDD_PTCDD0 = 0;  PTCDD_PTCDD0 = 0;  PTADS = 0;  PTASE = 0;*/  Wait_sh(80);    IIC1A = 0;  IIC1F = 0b10001101;  IIC1C = 0b10000000;    Wait_sh(80);}void i2c_start(void){     Init_I2C();    IIC1S = 0b10010010; // clear interrupts     IIC1C = 0b10111000; // Start, TX, NOACK    Wait_sh(80);}void i2c_stop(void){  IIC1S = 0b10010010; // clear interrupts  IIC1C = 0b10000000;  Wait_sh(80);}void i2c_restart(void){  IIC1C = 0b10111100; // Start, TX, NOACK, RESTART  Wait_sh(80);}char i2c_waitforflag(void){  IIC1SSTR status;    Wait_sh(80);    do  {    status.Byte = IIC1S;  } while(!status.Bits.TCF);    IIC1S = 0b10010010; // clear interrupts    return(!status.Bits.RXAK);}char i2c_sendbyte(unsigned char data){  if(IIC1C != 0b10111000) IIC1C = 0b10111000;  IIC1D = data;    return(i2c_waitforflag());}unsigned char i2c_getbyte(char send_ack){  unsigned char data;    if(send_ack) IIC1C = 0b10100000; // RX, SEND_ACK   else IIC1C = 0b10101000; // RX, NO_ACK  IIC1D;  i2c_waitforflag();  data = IIC1D; // read right data;    Wait_sh(80);    return(data);}

Code:

unsigned char EE_WaitForACK(unsigned char control_byte){  unsigned char counter = 200;    unsigned char ack;    unsigned char ControlByte = control_byte;    ControlByte &= 0b11111110;    do  {    i2c_start();    ack = i2c_sendbyte(ControlByte);        i2c_stop();      --counter; // her deneme 175uS sürüyor, 29 deneme > 5ms yapar.  } while(!ack && (counter != 0));    return(ack);}char EE_ReadBuffer(unsigned int Adr, unsigned char* Data, unsigned int size, unsigned char external_adr){  // Control Byte = 1 0 1 0 A2 A1 A0 R/W. unsigned char ControlByte = 0b10100000; // Yazma modu, A2, A1, A0 = 0 unsigned char AddrHigh = (Adr >> 8) & 0xFF; unsigned char AddrLow = (Adr & 0xFF);  ControlByte |= ((external_adr << 1) & 0b00001110);  i2c_start();  // Control Byte = 1 0 1 0 A2 A1 A0 R/W  if(!i2c_sendbyte(ControlByte)) {  i2c_stop();  return(0); } // Address High Byte  if(!i2c_sendbyte(AddrHigh)) {  i2c_stop();  return(0); } // Address Low Byte  if(!i2c_sendbyte(AddrLow)) {  i2c_stop();  return(0); } // Read i2c_restart();   // Control Byte to read ControlByte |= 0b00000001; // Okuma modu   if(!i2c_sendbyte(ControlByte))  {  i2c_stop();  return(0); } do {  *Data++ = i2c_getbyte(size != 1);   } while(--size);  i2c_stop();  return(1);}char EE_WriteBuffer(unsigned int Adr, unsigned char* Data, unsigned int size, unsigned char external_adr){ unsigned int _PAGE = 0xFFFF; // önceki page   // Control Byte = 1 0 1 0 A2 A1 A0 R/W.  unsigned char ControlByte = 0b10100000; // Yazma modu, A2, A1, A0 = 0   do  {     unsigned int CURRENT_PAGE = Adr & 0b1111111110000000; // page size 128 byte    if(CURRENT_PAGE != _PAGE)  {     unsigned char AddrHigh = (Adr >> 8) & 0xFF;     unsigned char AddrLow = (Adr & 0xFF);          ControlByte |= ((external_adr << 1) & 0b00001110);      if(_PAGE != 0xFFFF)   {    i2c_stop();        if(!EE_WaitForACK(external_adr))       return(0);   }      //i2c_start();   i2c_start();    // Control Byte = 1 0 1 0 A2 A1 A0 R/W.      if(!i2c_sendbyte(ControlByte))   {    i2c_stop();        return(0);   }   // Address High Byte      if(!i2c_sendbyte(AddrHigh))   {    i2c_stop();        return(0);   }   // Address Low Byte      if(!i2c_sendbyte(AddrLow))   {    i2c_stop();        return(0);   }      _PAGE = CURRENT_PAGE;     } //if(CURRENT_PAGE != _PAGE)    if(!i2c_sendbyte(*Data++))  {   i2c_stop();   return(0);  }    Adr++; } while(--size); i2c_stop();  return(EE_WaitForACK(ControlByte));}

Re: AW32: I2C Problem

Fonsi — Sat, 29 Sep 2007 04:26:44 GMT

Hello,

In the issue of pull-ups while set at 10k, I have to say this value is too high it may work at 400KHz but I have experienced that as you star running in real environment, you will loose packets. 4.7kOhms is what I have used in the past and achieved 100% success transfer from the Master to the slave and vice versa. If you notice for a 400KHz speed there are only 2 settings to select the proper Setup and Hold settings for your device.

Someone shared with you that they resorted to a bit banged routine to get things to work correctly and that is fine but that was not necessary specially when the final application will use and interrrupt driven firmware and many events have to be handled in the background. When dealing with polled code you have to make sure you have the correct delay and that you monitor the correct condition flags before writing to the I2C data register.

I also agree that the I2C documentation is only sharing where the control and status registers are place and what their functions are. I also agree that we should have a document explaining how the Phillips specified requirements are implement by the module. There are however, 4 I2C appnotes currently published that are supposed illustrate how one can use the module for communications.

Writen code just illustrates your intentions with the module but do very little to really figure out what is really going on in your MCU. Transfering an entire project to allow us to run it in real system, would allow any of our support engineers to debug efficiently and this is the reason why I have suggested that we discuss in more details and find out what the root cause is. .

In summary:

-5k or lower on SDA and SCL, If you need a pullup lower than 4.7K, your system is not properly filtered.

-I2C interrupt driven Driver should be written to allow the I2C state machine schedule I2C protocol events.

Regards,

Edgar Saenz.

Re: AW32: I2C Problem

bigmac — Sat, 29 Sep 2007 12:34:05 GMT

Hello BP,

I agree that 10k pull-up resistors are somewhat on the high side, particularly for a 400kHz clock. However, your posted code indicates that you have a 96kHz clock, and since your capacitive bus loading is likely to be substantially less than the 400pF upper limit for this clock rate, I doubt that this is your current problem.

I did some comparison of your posted code with that shown in AN3291 (for the 9S08GB60 device), and found a difference that might be significant -

While your code seems excessively circuituous, it would appear to resolve to the following sequence for the transmission of each byte by the master -

Write byte value to IIC1D.
Wait for TCF flag to become set.
Attempt to clear TCF, ARBL and IICIF read only flags.
Wait for RXAK flag to become set.

By comparison, the similar code shown within AN3291 (which does not use use IIC interrupt) does the following -

Write byte value to IIC1D.
Wait for IICIF flag to become set.
Clear the IICIF flag only.
Wait for RXAK flag to become set.

   IIC1D = data;
   while (!IIC1S_IICIF);     // wait until interrupt flag
   IIC1S_IICIF = 1;          // clear flag
   while (IIC1S_RXAK);       // Wait for ACK from slave

So the important aspect appears not that it be necessary to implement interrupts, but that the interrupt flag IICIF should be the flag that is tested and cleared, rather than TCF. If this is correct, the issue appears most likely that the IICIF flag becomes set some time after the TCF flag is set, and the attempt to clear the flags does not clear the IICIF flag (which is obviously a mandatory requirement, although not stated in the data sheet).

The importance of testing the IICIF flag (and not TCF) is suggested by the author of AN3291, in the following thread, that also addresses a bug present in the original release of the application note -http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=3785

The application note makes no mention of the need for an extra delay following START or STOP conditions. It might have been more instructive if the reason for the previous suggestion of their inclusion was given, in order to appreciate what the magnitude of the delay might be.

Finally, I notice that your code for the generation of START and STOP seems more complex than the application note would suggest -

IIC1C_TXAK = 0; // RX/TX = 1; MS/SL = 1; TXAK = 0
IIC1C |= 0x30; // generate START

and

IIC1S_IICIF = 1; // clear interrupt flag
IIC1C_MST = 0; // generate STOP

Regards,
Mac

Message Edited by bigmac on 2007-09-29 03:49 PM

Re: AW32: I2C Problem

Fonsi — Sat, 29 Sep 2007 23:35:54 GMT

IICIF flag is the only flag I dealt with in my driver which has polled and interrupts driven utilities. TCF is there as a status flag and is seems to be there to indicate when the Transmission is complete, how that status flag is used in code is still unknow to me but I am sure there is a use for it. The same module is used on the S12s where I did most of my IIC testing, and yes you are correct, the code in polled style works and can be made to run but I found that for any application where the MCUs task is more complicated, Interrupts is the way to go and since everything I get drafted into is not simple, I love Interrupts. You of course do not have to. Sounds to me you have figured it out and thank you for using our devices. It is not that complex to watch the behavior of the device, specially when the using the Debugger under CW, one only needs to set the Memory window in periodic display mode and run the Master to brake and trace on every IICDR statement, or in machine code at STA 0xIICDR. One can see with of the flags are set and clear on each byte transaction. I was hoping you could open an SR so that I can share my un published appnote with you but since you are well on your way. More power to you.

Edgar.

Re: AW32: I2C Problem

BasePointer — Thu, 29 Oct 2020 08:46:05 GMT

Hi to all,

Thank you for your interest.

Here is my last implementation.

Now I'm living problem only with i2c_getbyte() function.

It is returning either 0 or holding on at line: while(!IIC1S_IICIF);

I'm using this function to read sequential bytes.

Do you know how we exactly start reading sequence?

Or what are the conditions that cause reading sequence not to start?

The communication speed is 96Khz with 10Kohm pull-ups and no capacitance. (also tried with 22pF caps without chance)

My scope is in the service now, I will send some images about SCL and SDA in a few days.

Code:

void i2c_clearflags(void){  IIC1S_IICIF = 1;  IIC1S_TCF = 0;  IIC1S_ARBL = 0;}void i2c_start(void){  i2c_clearflags();    IIC1S_SRW = 0; // master will send data    IIC1C = 0b10111000; // Start, TX, NOACK      Wait_sh(80);}void i2c_stop(void){  i2c_clearflags();  IIC1S_SRW = 0; // master will send data    IIC1C = 0b10000000;    Wait_sh(80);}void i2c_restart(void){  i2c_clearflags();    IIC1S_SRW = 0; // master will send data  IIC1C = 0b10111100; // Start, TX, NOACK, RESTART    Wait_sh(80);}char i2c_waitforflag(void){  IIC1SSTR status;    do  {    status.Byte = IIC1S;  } while(!status.Bits.IICIF);    i2c_clearflags();      return(!status.Bits.RXAK);}char i2c_sendbyte(unsigned char data){  if(IIC1C != 0b10111000) IIC1C = 0b10111000;  IIC1D = data;    return(i2c_waitforflag());}unsigned char i2c_getbyte(char send_ack){  unsigned char data;    if(IIC1C_TX)  {    IIC1C_TX = 0;    IIC1C_TXAK = 0;            data = IIC1D; // initiate first reading sequence  }    while(!IIC1S_IICIF);  i2c_clearflags(); if(send_ack) IIC1C_TXAK = 0;  else IIC1C_TXAK = 1;        data = IIC1D; // read right data    return(data);}

Regards,

BP.

Re: AW32: I2C Problem

Fonsi — Tue, 02 Oct 2007 22:18:36 GMT

Just to give you and Idea on what it takes to make this module to roll data out without a problem in Poll mode.

I am using some software semaphores so the code may not be easily portable but I am sharing this code so that you get to see some of what works. This is the same module as the one you are using the bit names have a small modification but it should be simple to make sense of the names. I left most of my comments in the code and I hope they help,. 10K pull up values are going to give you problems. I go for 5Ks if I were you.

I avoid do, while statements as they generate brclr/sets and those instructions tend to get stuck depending on the condition required. I always like the routine to return and error code and exit.

Regards,

//*****************************************************************//
//Inputs: char ID,char Read_Write,char NumberBytes
//Outputs: IIC_Accepted

// Calling format : ack_flag=Send_IIC_Address(Control1,RW1,Total_Bytes)
//*****************************************************************//
char Send_IIC_Address(char ID,char Read_Write,char NumberBytes)
{
char IIC_Accepted;
IIC_Accepted=0;
if(Slave_Flag==0)// if driver intends to be in Master mode
{
IBIF=1;
TX_RX_=1; // from master to slave
MS_SL_=1; // send START on clean slate
}
ID=ID<<1;
if(MS_SL_==1 && TX_RX_==1)
{
IIC_Delay(1000000);//spacing between start and char.
// should not be needed to ensure byte reception

// continuity.
  if(Packet_Status==0)//
  {
  IIC_DATA_ARRAY[0]=NumberBytes;
  IIC_Byte_Counter=0;
  Send(ID | Read_Write);
  }

  //IBDR=ID | Read_Write;// or the SRW bit with Address ID.
  //IIC_Delay(100);// worked polled at 900 at 968usec from end of last to begin of next.
    // worked polled at 500 at 59usec from ID to first byte.
  if(RXAK==0)
  {
  IIC_Accepted=PORTB;
  IIC_Accepted=IIC_Accepted & 0xF7;
  PORTB=IIC_Accepted;// Turn on LED4 to indicate packet is transfer.

   if(Read_Write==1)
    Slave_Flag=0;// master mode
    IIC_Accepted=1;//Everything is cool let's get running
//    Packet_Status=1; // handled in the interrupt when polled here
  }
  else
  MS_SL_=0;// sending stop

}
else
{
IBEN=0;
IBEN=1;// Bus is gone crazy
MS_SL_=1;// sending START
}
return IIC_Accepted;// if char =0 no response from slave node.
}

**************************************************************************************************************

//Description. Send packet will send a series of packets with
//incremental data n to n-1 where n-1=Number_Bytes-1 bytes.
char Send_Packet_Polled(char Number_Bytes)
{// send
char Byte_Counter=0;
char error_flag;
char Return_Val=0;
char Number_Fail=0;
char Number_Pass=0;
char chase_flag=1;
while(chase_flag==1)
{
Return_Val=Send_IIC_Address(0x0E,0,4);//wp0xe
if (Return_Val==1)// good case.
{
Number_Pass++;
chase_flag=false;
}else
{
Number_Fail++;
Byte_Counter=0;
return Byte_Counter;// Returns Number_Bytes-1 as completion flag

}

}// end of while char_flag

for (Byte_Counter=0;Byte_Counter<=Number_Bytes
{
  // working with 7 but no second packet was moved to else.
   if(IBIF==1)
    {
     if(RXAK==0)
     {
     //400 456 uSec works on packet only
     //500 568 uSec works
     //600 because START always given a macth hard to code
      if(MS_SL_==1)
      {
       if(TX_RX_=1)
       {
       IIC_Delay(900000);/// could do a while (IBIF==1)
       IBDR=Byte_Counter; // to generate brclr instruction.
       IIC_Delay(60);//100= 56usec working
           // 60=10usec spacing between bytes. Real
       Byte_Counter++; // 55=8usec and not working real
       // 60 EM does not
       // 70 no
       // 100
       // 200
       }
     }
     else
      {
      Byte_Counter=Number_Bytes+1;
      return Byte_Counter;
      }

     }// end of else RXAK==0;
     if(RXAK==1)
     {
      error_flag=1;// abnormal condition
      Byte_Counter=Number_Bytes+1;
      MS_SL_=0;// send stop
      IBIE=0;
      TX_RX_=1;
      return Byte_Counter;// Returns Number_Bytes-1 as completion flag
     }// end of if no ack from slave

    }// end of if(IBIF==1) case.
    else
    {//
    Byte_Counter = Number_Bytes-1;
    }// end of if(IBIF==0) case.
   // end of good case

   if(Byte_Counter == Number_Bytes-1)
   {
   error_flag=0;//normal condition
   Byte_Counter=Number_Bytes+1;// end this loop
   MS_SL_=0;// send stop
   IBIE=0;
   TX_RX_=1;
   return Byte_Counter;// Returns Number_Bytes-1 as completion flag
   }
}// end of send Number_Bytes polled for loop.

}// end of send Packet Polled.

Re: AW32: I2C Problem

bigmac — Wed, 03 Oct 2007 02:44:06 GMT

Hello BP,

Firstly, there seems to be confusion about some of the flags -

SRW is a read only flag, and is of no interest for master operation. Similarly, the ARBL flag is of no interest with a dedicated master. Anyway, it is cleared by writing 1, not 0. The TCF flag is automatically cleared on the next read or write to IIC1D register. This leaves only the IICIF flag to be concerned about in the flag clearing process.

I don't know why you chose not to use standard bit definitions within the i2c_waitforflag() function. Also, the intention of the line
return(!status.Bits.RXAK);

seems obscure. It certainly doesn't wait until the RXAK flag is set.

You should check the actual requirements in the data sheet for the EEPROM device, but to start the reading sequence, after sending the address bytes, you will probably need to generate a repeated start, and then send the control byte again with the RW bit set for read. Then clear the IIC1C_TX bit for read, set the IIC1C_TXAK bit to disable acknowledge, and do a dummy read of the IIC1D register.

I suggest you examine the left hand part of Fig. 13.1 in the data sheet for the AW60. Even though the flow diagram pertains to an ISR, a similar sequence of events will be required when the flag is polled.

Finally, do not add any capacitors to the bus - the least capacitance the better.

Regards,

Mac

Re: AW32: I2C Problem

JMAC — Sat, 13 Oct 2007 12:09:32 GMT

This is a late "thank you much" to PeterHouse for the feedback around 9/18/2007 on AW60 IIC. I just scanned back through here today, and was a bit surprised at how much activity is still on this thread. The length of this total thread alone should tell you something.

Heres my two cents on the polling use of this IIC module on the AW60. IIC is slick for me simply because of the two-wire use. I often use it for passing info across isolation barriers, and doing this with two optos instead of three for SPI is really nice. I often don't actually "bus" anything on it - just one part like a DAC, an LCD, or an EEPROM. However, as Peter said, it truly is a complex module in the AW60 for the few 2-3 bytes of data I jamb through. In my case, running this in interrupt mode really makes no sense, as its far easier to simply wait for the bytes to clear and just move on in my specific application. As I read through several other posts to the thread, I disagree on using interrupts any time just because they are available - if they don't make sense for the application code, then they don't make sense period. In fact, throwing interrupts in everywhere for no good reason is a great way to build a pretty unreliable product. The bit bang routines work best for these mini transfers (they have for over 10 years now on this actual product), so I went back to them after a week of messing around. I had only tried to convert them because the new AW60 processor supported the IIC module. Honestly, I haven't had any problems for last 20 years working with simple bit-bang IIC implementations like this on
Mot/Freescale/TI/etc processors until I recently started playing with this AW60 module. I'm a big fan of Freescale parts, and I was pretty disappointed this wouldn't work out.

I find it odd sometimes in this forum when something clearly doesn't work in its basic described format, that the Freescale factory support is more of a debate on how a different approach certainly must be taken (ie. "don't run it in polling mode because it doesn't make any sense to do that when the code will be full of interrupts anyway") What? In this case, if the module contains proper flags to support simple monitoring of when data bytes clear (and it does), then it should work that way regardless of whether or not some other interrupt is running. If not, maybe we need a errata to tell us what is going on.

Thanks much to all the actual users out there like Peter that support this forum, and make it invaluable to all of us up in the middle of the night trying to sort these things out.

Re: AW32: I2C Problem

Alban — Mon, 15 Oct 2007 15:09:50 GMT

Hello JMAC,

"Freescale Factory Support" was NOT involved in this thread.
"Factory Support" is a special term used in supporting world which means L4 or 4th line.

Being "Freescaler" means being part of the company and wanting to help. The person could be less specialist than some 'external' members... But I would not refuse help as it gives another light on the matter.

In this case, the Freescaler who replied is knowledgable and see a lot of questions.

For very specific applications, interrupts are forbidden because the exact path of execution is required to be known. This is usually the case in safety critical systems. That is probably why polling is still offered.
With the growing number of features required and the always growing abilities to test better, the number of applications forbidding the use of interruption is falling.

As an example, MAGGALY an automatic subway was only made of logic, because there was a probability of 0.000001 of any microprocessor to crash (I don't know the odds now).

I would still advise you to use the interrupt driven mechanism...

Alban.

Re: AW32: I2C Problem

Fonsi — Mon, 15 Oct 2007 22:38:48 GMT

One of the reasons why I do not particularly prefer forums is that is very hard to follow the trend of thought and I do not know if the person who was having the problem is now okay.

I am one of the IIC experts at the factory, my claim to fame is that I have actually been the only one that has gone inside the IIC module and traced signals through the logic module at the Failure Analysis Lab. A project that thought me a lot about what IIC is and what the strengths and weaknesses are. I also exercised the module, polled and interrupt driven to understands hung ups and LOAs and why they were happening in our development tools and for some big European Customers. I am now working for the TechnicalInformationCenter and support mainly the US market but have not problems helping anyone who is having problems with the module.

IIC is not an easy byte protocol and it is even harder to implement at packet protocol but the task is very attainable. I will encourage anybody who is implementing a true IIC bus to open up a service request at www.freescale.com and request the issue to be assigned to me.

I have since written an IIC appnote which I abandoned due to the fact that they were many others in progress so I thought that duplicating efforts would not be the best thing for me. However, you are correct, TCF is a status bit, I never had to use. I started out with the notion that this control bit would act like a completion flag on an Analog to Digital converter but I was wrong and when I ran simulations the TCF is used but it be may only a test mode feature. Since I was under the gun at the time, I never went back to get the real story on what its functionality really is. Sorry for the inconvenience that caused you.

Hi BP,

Your assumption about load capacitance versus speed is incorrect but the concept is right on. The slower the speed under a heavy capacitance load the more of a slew rate affects the IIC bus performance and the more LOAs I experienced, I know why this happens but it would take me more than 3000 chars to explain it. The solution to bus hang ups is to make the rise and fall times of the clock and data as fast as possible.

Regards,

Edgar Saenz.

TechnicalInformationCenter.

16 bit Team leader.

Re: AW32: I2C Problem

joemanix — Sat, 27 Oct 2007 04:02:42 GMT

Hi,

i'm using the AW32 I2C module, implementing a master only C code with interrupts. I drive a PCF8570 I2C RAM at 89khz with 4,7K pullups, at less than 5 cm distance on the board. For information, i use this RAM only to save data with a backup battery when the power is off. The main reason is that i couldn't get accurate information on the way to backup directly the AW32 RAM (very basic topic, yes...but the support is still working on it). But it's another story.

I started my I2C integration today, and of course, nothing works. At reset, the SDA, SCL lines are high, and after using my write routine for the 1st time, both still at low forever.

I used a step by step execution in the write routine. The lines are high up to arrive at the START condition. At master selection (ie START or IIC1C_MST = 1), both pins goes and still low. No data out, and the interrupt never comes. It occurs also when i remove the PCF8570 .

IIC1C_TX = 1; /* Select Transmit Mode */

IIC1C_MST = 1; /* <<<< problem occurs here Send Start) */

//for(T=0;T<10;T++); /* Small delay */

SCI1D = iicport_1.IICaddr; /* write address to start transmission */

I tried various SW combinations using the HS08 docs (peripheral module quick reference, ...) but no change.

I think, by reading this forum, that there is a HW bug somewhere. I'll send a service request.

Bye

Re: AW32: I2C Problem

DaleUlan — Fri, 11 Apr 2008 11:47:32 GMT

I've been working on a similar problem - AW60, polled I2C. Here's what I found I needed to to to get it to work:

Immediately after setting IIC1C for the transfer, clear the interrupt flag (bset #1,IIC1S) - before writing the address byte to IIC1D

When writing to IIC1D, wait at least 12 clock cycles (jsr to a return) before brclr #1,IIC1S,*

When reading from IIC1D, wait at least 12 clock cycles between clearing the interrupt flag (bset #1,IIC1S) and reading the IIC1D register

After waiting for #0,IIC1S when transitioning from read to write mode, wait 12 cycles between each operation. Same thing when disabling ACK for the last transfer.

Wait for #0,IIC1S

Wait 12 Tcyc

Set IIC1C for write mode

Wait 12 Tcyc

Read IIC1D

Wait 12 Tcyc

Wait for #1,IIC1S

Clear #1,IIC1S

This seems to have worked for me. Hope it helps someone out there. I write in assembly code so perhaps C compilers put in the little delays just because. Anyways, it appears to work properly now.