I2C communication for the HC08AP64 Mico

[HSE]

Hi,

I just started working with the HC08 micros, from the HC12. I am trying to set up the I2C communication for the HC08AP64, without any success so far. All Application notes show the I2C communication using 2 general I/O pins.

I am using codewarrier, and coding in C. I have made the I2C routines from scratch and used the device initialization as well, both yielding the same results. I checked the outputs (data and clock) using a scope, and both lines are dead. No output being sent. The module is Enabled.

Does anyone have a code snippet I can use, even for another HC08 micro which I can use to direct me?

I am using the HC08AP64 demo board with a P&E USB MON08 programmer.

Any input is greatly appreciated.

Thank you,

HSE

[DGagnon]

Hi,

I'm also trying to use I2C but with interrupts, not to freeze the the execution of the main program.

Here is what I do:

• Initialization
• 1. Set the vector table correctly,
  2. Enable the MMIIC module (MMCR1_MMEN = 1)
  3. Set the address (MMADR = Address << 1)
  4. Set the speed (MMFDR_MMBR = SpeedSelect)
• Starting a transmission
• 1. Is the transmission in progress flag set? (RAM var) Yes: Return an error.
  2. Set the flag for transmission in progress.
  3. Enable the interrupt (MMCR1_MMIEN = 1)
  4. Set the direction (MMCR2_MMRW = IsRead)
  5. Set the buffer (MMDTR = Data [or 0xFF if reading])
  6. Set to master (MMCR2_MMAST = 1)
• Getting an interrupt (writing mode)
• 1. Clear the interrupt flag (MMSR = 0)
  2. Was there an error? (MMCR2_MMALIF or MMCR2_MMNAKIF = 1?) Yes: Step to
  3. Was the byte sent? (MMSR_MMTXIF = 1?) No: Step to
  4. Was this the last byte to send? Yes: Step to 6
  5. Set the buffer (MMDTR = Data), step to 11
  6. Send a stop by leaving the master mode (MMCR2_MMAST = 0) and
  7. set the buffer to 0x80 (MMDTR = 0x80)
  8. At the next interrupt, clear its flag and disable it.
  9. Wait that the busy flag gets cleared (MMCR2_MMBB = 0?)
  10. Clear the transmission in progress flag.
  11. End of interrupt routine.

But this doesn't work.

What actually happens is that the first transmission is OK but the transmit interrupt flag (MMSR_MMTXIF) keeps getting set even after steps 6 to 10 of the interrupt routine. So the next transmission sees that the "transmission in progress" flag is cleared (OK to transmit) enables the interrupt, the interrupt routine starts and corrupts this transmission.

Also, in the first transmission, there is a glitch (a bitwide pulse) on the data line just before the stop condition due to MSBit set (high) in MMDTR (MMDTR = 0x80). When the MSBit is cleared (low) (MMDTR = 0), the stop condition is not performed (the clock line goes high but the data line stays low). I tried to set MMCR2_MMRW to 1 (read) not to have the glitch but it has the same effect as when the MSBit is cleared.

Then, I tried to disable and re-enable the I2C module (MMCR1_MMEN = 0; MMCR1_MMEN = 1) when the second transmission is initiated but the clock and data lines goes high before the stop condition is even initiated on the bus. I think this is due to the fact that the transmit buffer is free (MMSR_MMTXIF set to high and thus an interrupt is initiated) before the physical transmission is actually finished so it doesn't mean that the I2C module can be disabled at that time. Since I also check that the bus busy flag (MMBB) goes low (stop condition detected) before clearing the "transmission in progress" flag, I thought that, physically, the stop condition has been done but it doesn't seem to be the case.

All my problems seem to revolve around the way I generate the stop condition. Maybe the way I do it isn't the right way to do it. In the documentation, no where is written how to generate a stop condition. The only information given is that when the MMAST bit is cleared by MMNAKIF set (no acknowledge) or by software, the module generates the stop condition to the lines after the current byte is transmitted. And this doesn't really say that setting MMAST to 0 (slave mode) will do a stop condition.

Furthermore, I have to say that my slave device does not know how many bytes is transferred until the transfer finishes (stop condition detected) so it cannot "send" a NAK at the end to tell the master to (automatically) do a stop condition.

Can anyone help me make my communication work properly?

Thanks

DGagnon

[B_Conf]

Hello:

I´m SORRY, I made a mistake in my previous message, the program in AN3291 it´s OK, it works, if you don´t put: MMCR1_MMEN=0; after clearing MMAST bit, like me!. In that case loss data and the module doesn´t generate STOP condition.


I will try to fix it and give to you the results, but, if anyone can help me I will appreciate a lot!.

Thanks, regards and sorry again!
Pablo (Bit_Confused) :smileywink:

[B_Conf]

Hello DGagnon:

I´m also working with I2C and AP32, but without interrupts, I´ve got the same problem that you, at least in the simulation, I´can´t generate the STOP condition, more, I´try to implement the program shown in AN3291, but it doesn´t generate the STOP, it´s mean, clearing MMAST bit do not generate STOP condition. I´m going to write words of 2 bytes in a 24LC512, and I´m probing send 1 byte before continue.
I' hope the AN3291 can serve to you, and if you resolve the problem, please, let me know.

Thanks and Regards
Pablo.

[Petirrojo]

Hi everyone...

First of all I want to beg apologies for my english...  I'm from Colombia and here we don't practice english (actually we never speak english).

Please, please, please, for God love, for humanity love, for Stars and Streaps love...   Help me !!!

I have been trying to get AP32 MMIIC module to work since two weeks ago... And nothing!!

I implement the code showed it in AN3291 application note (How to use IIC module in M68HC08), just trying to write a byte of data...  The moth·%¨*+-*/er problem is the piece of sh¿¨·\¬   MCU does not generate the STOP condition

I put this instruction after I2C_write_byte (); function:

I2C_write_byte (RTC_address, mem_address, 0x00);

if(PTB_PTB0 && PTB_PTB1)

   PTA_PTA5 =0;                         // This turns a LED on

But the MCU never release the SDA (PTB0) and SCL (PTB1) pins , that means the module never generate the STOP condition

I have tried everithing, I've check the signals with oscilloscope, I captured all signals, I have configured other bits for Control Register and Status Register... Even I have changed the Stop condition (MMCR2_MMAST =0, for a Repeat Start condition (MMCR1_REPSEN =1), and whit this the RTC answers...   But never, never in this 14 days, I have could the MCU generate the stup.... (excus me) the STOP condition...

I'm desperate...  It's not possible I could not finish a huge work because that little part...

If someone has any code working since 2007, I really apreciate the help.

Thanks for all.

Vladd

Pd. I beg excuse for bad words.

[JimDon]

Try this:

Spec =>  A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition.
// bit 1 = SCL
// bit 0 = SDA
void SendStop(void)
{
  DDRB  |=  1    // set SDA to ouput.
  PTB   &=  ~1   // drive it low
  DDRB  &= ~2    // Make the clock input, which forces it high.
  Delay();       // set up time for chip
  DDRB  &=  ~1   // set SDA to input driving it high
}

[Petirrojo]

Hi to everyone...

This had been a very long month for me, but at end the work is finished.

Thanks JimDon for your contribution, but the objective of work was to put MMIIC AP32 module to work, without using any additional code (If I should had used your code it would be a chief).

finally, the application note is right but not complete.

For all people who is interesting to configure an d use the module, here is the code I made and works whit two IIC devices (RTC DS1307 & EEPROM 24LC32A)

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
/* This function initializes MMIIC module of MCU                               */
/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
void MMIIC_init (void)
{

  MMCR1_MMEN    =1;  // Enable IIC
  MMCR1_MMCLRBB =1;  // Clear bus busy flag
  MMCR1_MMTXAK  =1;  // MMIIC does not send acknowledge signal at 9th clock bit
 
  MMCR2_MMRW    =0;  // R/W bit = 0
  MMCR2_MMAST   =0;  // Slave mode actually
  MMCR2_MMNAKIF =0;
  MMCR2_MMALIF  =0;  // Clear flags
 
  MMADR =MCU_ADDRESS;  // Set specific slave address for MCU  
                                       
  MMSR  =0;   // Clear all flags (Status register)
  
 // MMFDR: ?? =0; ?? =0; ?? =0; ?? =0; ?? =0; MBR2 =0; MMBR =0; MMBR =1;
 MMFDR =1;   // Set speed to 61,440kHz for Frequency Bus = 2457,6MHz (Divider by 40)
             // SCL clock frequency MAX...   RTC --> 100KHz   EEPROM --> 400KHz
}

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
/* This function writes a 'data' in memory address 'data_addr' on 'device_addr'*/
/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
void IIC_write_data (byte device_addr, byte data_addr, byte data)
{         
 
  MMCR2_MMRW =0;              // Set Write mode
  MMADR      = device_addr;   // set combined address of Slave for write
  MMDTR      = data_addr;
  

  //------- Start of transmit bytes to IIC bus -----
  MMCR2_MMAST = 1;        // Start transfer - Master bit = 1    
  while (!MMSR_MMTXBE);   // Wait till data transferred
  while (MMSR_MMRXAK);    // Wait for ACK from slave; 
  
    
  //------- Slave ACK occurred ------------
  MMDTR = data;           // Write data into device
  while (!MMSR_MMTXBE);   // Wait till data transferred
  MMDTR = 0xFF;           // Generate SCL impulse for slave to send ACK bit;
  while (MMSR_MMRXAK);    // Wait for ACK from slave        
  
 
  MMCR2_MMAST   =0;    // Slave mode actually

  MMCR1_MMCLRBB =1;    // Clear bus busy flag
  MMADR =MCU_ADDRESS;  // Set specific slave address for MCU 
              

    
  delay_ms(25);
}

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
/* This function reads a data in memory address 'data_addr' on 'device_addr',  */
/* output from this function is byte "data"                                    */
/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
byte IIC_read_data (byte device_addr, byte data_addr)
{
  byte data;

  MMCR2_MMRW = 0;         // Set Write mode
  MMADR = device_addr;    // Set combined address of Slave for write
  MMDTR = data_addr;      // Write data address into device
  

  //------- Start of transmit bytes to IIC bus-----
  MMCR2_MMAST = 1;      // Start transfer - Master bit = 1     
  while (!MMSR_MMTXBE); // Wait till data transferred;
  while (MMSR_MMRXAK);  // Wait for ACK from slave; 
 

  //----- Slave ACK occurred------------
  MMCR2_MMRW   =1;  // Set read operation
  MMCR1_REPSEN =1;  // Enable repeat Start bit
  MMCR1_MMTXAK =0;  // Master will generate ACK 

  //------ Start of transmit Repeat Start & "A1" to IIC bus-------
  MMCR2_MMAST  =1;        // Start transfer - Master bit = 1
  MMDTR = 0xFF;           // Send repeated start and combined address
  while (!(MMSR_MMTXBE)); // Wait till data transferred;
  while (MMSR_MMRXAK);    // Wait for ACK from slave;
  

  //------ End of data reception -------
  MMDTR = 0xFF;          // Send SCL clocks for the slave to send data
  MMCR1_MMTXAK = 1;      // Disable master ACK after read byte from Slave
  while (!MMSR_MMRXBF);  // wait till data received;
 
  data = MMDRR;          // Read received data;
 
  MMCR2_MMAST   = 0;  // Generate STOP bit - End of transfer;
  MMCR1_MMCLRBB = 1;  // Clear bus busy flag

  MMADR =MCU_ADDRESS; // Set specific slave address for MCU

  return data;
 
}

The red part was the missed part in application note. If the bus busy flag is not clear, the MCU never can generate STOP condition. The MCU address is a constant defined by programmer. In AP32 datasheet is recommended that after a routine of reading or writing program must update MCU slave own address (MCU_ADDRESS) if there is other master in the bus who wants to call the AP32 MCU.

You can make other functions to make a modular program as I did. You can make and start_function() that receives device address and memory address as input parameters; stop_function() that receives no parameters; IIC_write_data, IIC_write_many_data, IIC_read_data, IIC_read_many_data and so on...

Is an interesting module, so you can do many things... Just imagine.

Thanks,

Vladd, from Colombia (U. de Ant.)

[JimDon]

Did you mean cheat?
Thanks for reposting your code! All too often threads never have an ending good or bad.

[mke_et]

Hmm, may be time for a clarification...

When I saw 'from scratch', I assumed he was writing his own 'bit banger' routines and NOT using anything built into the 08. Especially since he almost immediately refered to 'General I/O pins'.

Also, when he refered to the 12, I assumed that he meant he was new to the 08, and came from the 12 environment.

Was I wrong on both counts?

Mike

[HSE]

Sorry for the confusion.

I am using the HC08AP64 as a master, to communicate with a Matrix Orbital LCD LK204-25. I never used I2C, but the LCD made the choice for me.

I did not start from any other code. I am starting from Scratch. I used the device initialization in codewarrier to generate the init. code, an checked it to the best of my knowledge against the HC08 datasheet, and it looks ok. I tried the LCD, and nothing happened, that's when I decided to debug the code while monitoring signals with a scope. I am monitoring any communication activity with the scope, and have the pull ups on the communication lines.

I am using the internal I2C module of the HC08.

Once this is working, then my next challenge is the communication protocol.

Any code examples or hints are greatly appreciated.

Here is the code which CodeWarrier created:

  /* ### Init_IIC init code */
  /* MMCR2: MMALIF=0,MMNAKIF=0,MMBB=0,MMAST=0,MMRW=0,MMCRCEF=0 */
  MMCR2 = 0x00;                                     
  /* MMADR: MMAD7=1,MMAD6=0,MMAD5=1,MMAD4=1,MMAD3=0,MMAD2=0,MMAD1=0,MMEXTAD=0 */
  MMADR = 0xB0;                                     
  /* MMCR1: MMEN=1,MMIEN=0,MMCLRBB=0,MMTXAK=1,REPSEN=0,MMCRCBYTE=0 */
  MMCR1 = 0x88;                                     
  /* MMFDR: MMBR2=0,MMBR1=1,MMBR0=0 */
  MMFDR = 0x02;                                     
 

and this is what I wil be using:

void LcdSendData(unsigned int data){
  while ((MMSR&0x02)==1){};
  MMCR2|=0x10;
  MMDTR=data;
}   

Thanks again for your time and input.

HSE

[bigmac]

Hello HSE,

After a brief perusal of the IIC section of the data sheet, and the manual for the display, I think I can see a couple of problems -

1. The default IIC address for the display is 0x50, which differs from the code initialisation value.
2. Within the LcdSendData() function, the initial while loop will only exit when MMTXBE bit becomes zero.  However, when any prior data transfer is completed, this bit would become set, so the loop would never exit.

After you have completed sending a number of characters to the display, I believe you may need to clear the MMAST bit.

It would seem the display also provides an RS232 option, with a further option to select TTL levels.  In this mode, it should directly interface with the SCI peripheral - as an alternative approach.

Regards,
Mac

[HSE]

Thank you for your reply. I was able to change the code and get it to work. Now the LCD is locking up after a few commands, but I think it is LCD related not HC08. If anyone needs some code samples for I2C (not the greatest yet, but it works), let me know and I will post it.

Thanks again,

Hassane

[HSE]

Hi again,

This is where I am now,

I was able to get the I2C working with the LCD, I can clear, send data, and shut off the back light, BUT, the last command/data I send, hangs up the bus.

Here are the details of the code with some comments:

// Function Definitions      

This one works. It sends the start and slave address, and waits for the ACK bit.                                     

void StartTXMaster(void){
  MMSR_MMTXBE=0;
  MMCR2_MMRW=0;
  MMCR2_MMAST=1;
}

I believe thisis where my problem is. Not sure if this is the correct sequence of register writes.

void StopTXMaster(void){
  MMCR2_MMNAKIF=0;
  MMCR2_MMAST=0;
}

This also works. I can monitor all data sent on the bus.

void LcdSendData(unsigned int data){
  MMDTR=data;
  while (MMSR_MMTXBE==0){};
  while (MMSR_MMTXIF==0){};
  MMSR_MMTXIF=0;
}   
    
 
// LcdInit                                                         
// Sends initialization data to the LCD.   I am using this to debug my code. It all works, but the problem is I do not get the ASCII 5 on the LCD. So the following code executes, It clears the display, it shuts off the back light, it sends 1 2 3 and 4, but it does not send the 5. It hangs up on the last write and the Stop signal.

I can't find clear information in the HC08AP64 to explain exactly how to proceed with the last data write on the I2C, or how to generate a STOP bit. The STOP bit is defined as the Low to High transition of the SDA while SCL is high. At the end of this code, the SCL is high, but the SDA is tied low. Is my Stop routine correct? Is there another register which should be set/cleared to generate the last Stop?

It is weird because the Stop signal seems to work in the void LcdClrDisp routine described below. It is only the last Data packet I send which causes the problem.

void LcdInitTX(void) {
  LcdClrDisp();  
  LcdBackLight(0x00,0x00);
  StartTXMaster();
  LcdSendData(0x31);
  LcdSendData(0x32);
  LcdSendData(0x33);
  LcdSendData(0x34);
  LcdSendData(0x35);
  StopTXMaster();
}

//Send byte to clear display
void LcdClrDisp(void) {
  StartTXMaster();
  LcdSendData(0xFE); 
  LcdSendData(ClearCmd);
  StopTXMaster();
}

//Send byte to turn off backlight
void LcdBackLight(unsigned int OnOff, unsigned int minutes) {
  StartTXMaster();
  LcdSendData(0xFE);
  if(OnOff==0x01){
    LcdSendData(BackLightOn);
    LcdSendData(minutes);   
  } else{
    LcdSendData(BackLightOff);
  }
  StopTXMaster();    
}

Any help? I also tried not sending the Stop, and I get the same response. Unfortunately, the P&E MON08 USB Multilink uses the same port pin as the I2C module, so there is no way for me to debug the code using codewarrior. I have to flash, disconnect the debugger, and run the code while monitoring signals with a scope.

Any ideas?

HSE

[bigmac]

Hello Hassane,

My interpretation of the data sheet is that, when the  MMCR2_MMAST bit changes from 1 to 0, a STOP sequence is generated at the conclusion of the current byte transmission in progress.  However, when this occurs within your code, the last character may still be waiting in the buffer (because two bytes are actually buffered), and will never get transmitted.

The simplest solution may be to send a dummy byte (that will not be transmitted) before zeroing the MMAST bit. 

void StopTXMaster(void)

{
 LcdSendData(0);  // Dummy byte

 MMCR2_MMNAKIF=0;
 MMCR2_MMAST=0;
}

I am not sure of the cause of the "bus hang up" problem.

Regards,
Mac

[HSE]

Hi Bigmac,

Thanks for your reply.

I did add the dummy byte to the code, and it solved the problem. What confuses me is the SendByte code should take care of this:

void LcdSendByte(int Data){
  MMDTR=Data;
  while (MMSR_MMTXBE==0){};  this should wait until the transmit register is empty
  while (MMSR_MMTXIF==0){}; this should wait until the data transfer is completed
  MMSR_MMTXIF=0; this clears the flag by writing 0 to it.
}

This should have taken care of all bytes be completely sent before exiting the routine. I will look more into the datasheet, maybe there is some register to write before proceeding to the STOP signal...

As for the Bus hanging up, I added this line at the end MMCR1_MMEN=0; to disable the MMIIC module, and it seems to have released the bus. Both signals are high. This tells me the hang up is from the controller.

I hope both issues are related to the non-optimal STOP routine.

Let me know if you have any insights.

Thanks,

Hassane

[bigmac]

Hello Hassane,

I suspect that the status of the MMTXIF flag is changes when the current byte completes transmission, and during the returned ACK, but does not take into account a byte waiting for transmission, within the two byte buffer.  This would certainly explain what you observe.

I also suspect that the MMTXBE flag becomes set whenever there is room to send another byte to the buffer, not necessarily when the buffer fully empties.

My choice would be to test for MMTXBE = 1 prior to loading MMDTR.  The testing of MMTXIF would appear unnecessary, since other measures need to be taken in order to transmit the final byte.

Regards,
Mac

[HSE]

Hello Mac,

Here is the status so far.

I tried the suggestion below, and I ended up in an endless loop. I think the first byte you try to send causes a problem with the MMTXBE = 1 check. I will have to set up 2 different functions to send a byte, one for the first byte, and another for subsequent ones.

I will keep thinking about another way of doing it. This is what i have now, and it seems to work. It will send all bytes and then release the bus. I followed the suggestion to send a dummy byte before ending the communication.

Here is copy of the routines I used:

void StopTXMaster(void){
  MMCR2_MMNAKIF=0;
  MMCR2_MMAST=0;
}
 
void LcdSendByte(int Data){
  MMDTR=Data;
  while (MMSR_MMTXBE==0){};
  while (MMSR_MMTXIF==0){};
  MMSR_MMTXIF=0;
}
    
 
// LcdInit                                                         
// Sends initialization data to the LCD.                      
void LcdInitTX(void) {
  LcdClrDisp();  
  LcdBackLight(0,0);
  StartTXMaster();
  LcdSendByte(0x31);
  LcdSendByte(0x32);
  LcdSendByte(0x33);
  LcdSendByte(0x34);
  LcdSendByte(0x35);
  LcdDispStrg("Hello");
}

And in my main, I have the following function calls:

  LcdInitTX();
  LcdDispStrg(" Hello");
  LcdSendByte(ASCII_NULL);  --> I put this so I am able to send the last byte in the buffer.
  MMCR1_MMEN=0;

This will release the buffer from the master. The last 2 commands, I will put into a function called I2C_Off(), which I will call once I end all slave communications to the LCD. I will create another function will will turn the MMEN byte on for new communication.

Thanks for all your help and input. If I figure out another way of doing it, I will post it for your reference.

Best Regards,

Hassane

[Andrey]

Hassane,

   Were you able to fix the problems?

Regards,
Andrey

[bigmac]

Hello HSE,

---

HSE wrote:

I just started working with the HC08 micros, from the HC12. I am trying to set up the I2C communication for the HC08AP64, without any success so far. All Application notes show the I2C communication using 2 general I/O pins.

I am using codewarrier, and coding in C. I have made the I2C routines from scratch and used the device initialization as well, both yielding the same results. I checked the outputs (data and clock) using a scope, and both lines are dead. No output being sent. The module is Enabled.

---

It is unclear to me whether you are using the I2C periperal module, or you are trying to "bit bang" (with the reference to general I/O). 

If the HC12 device is the master, the failure to see a clock signal might indicate a problem with the HC12, rather than the HC08.  I presume you have appropriate value pull-up resistors installed.

Regards,
Mac

[mke_et]

Well, first thing I would do is make sure you have individual bit control from your program on the board you are using. Once you verify that, then start looking at your code.

How did you do your protocol? Did you start with known good code from say your 12 application and port it over? Are you using a chip that you know you have it right to begin with?

I had to start from scratch with my 12 project and then write to a chip I never interfaced with before and it was a royal pain. I did it all in assembly.

First thing I wrote was my 'bit' instructions, and I used them to verify the hardware, and that I knew what the pins were doing with a scope or a probe. Then I wrote the 'byte' instructions that called the 'bit' instructions, just to make sure I didn't have a serious brainfade issue. Then finally wrote the 'protocol' for the chip I was trying to talk to. And of course there were 'holes' in the chip spec from the manufacturer that I had to figure out and account for! (It was a RTC chip)

Mike