I2C Slave device on 9S08EL16

[quevedo]

Hello,

I am trying to use a 9S08EL16 as an I2C slave device. This device will control 6 PWM channels, and pulse widths are determined by I2C commands. However, my device is not recognizing the I2C address sent by the master.

I am using a TWR-MECH board with its original firmware as a master to send I2C commands, so It should probably be working OK. The onboard accelerometer works on I2C interface, and it is being correctly read by the main board.

I am running my EL16 device through CodeWarrior Debugger and BDM. I had set up a breakpoint at the point of the program where I2C address has been matched. When I command the TWR-MECH to send an I2C command to my device, it stays in the address match loop, without leaving it and breaking execution. Thus, address is not being recognized.

Here is the part of my code where I initialize the I2C and then I try to get a command issued to my device:

IICC2 = 0x00; //No general calls, 7-bit address

IICA = 0xC0; // defines IIC address 60 hexa for the module. 0xC0 = 0x60 << 1

IICC1 = 0x80; // Enables IIC in slave mode, receive mode, with ACK signal, without repeated START  

/* Main loop */

for(; ; ) {

    while(!(IICS & 0x40)); // waits until address match (bit 6)

    rw = IICS & 0x04; // isolates R/W bit. BREAKPOINT IS HERE!!!!!!

    while(!(IICS & 0x80)); // waits until data received (bit 7)

    cmd = IICD; // reading IICD clears IICS bit 7. Here is the command

    if(rw) {

        parser_read(); // slave read routine

     } else {

        while(IICS & 0x80); // waits until data received

        iicdata = IICD; // Now gets data byte, clearing IICS bit 7

        parser_write(); // command parser for slave write routine

    }

    IICC1 = 0x80; // clears IICS bit 6 by writing to register IICC

    // end of main loop

}

There is a periodic interrupt of 25ms period. Could it be the reason of address matching failure?

Thanks in advance

[JimDon]

You code looks correct.

Any chance:

You are using PTB6/7 and did not set IICPS in SOPT1?

The master is running too fast.

The correct pins are not connected.

[quevedo]

Hello JimDon,

I had the wrong setting for SOPT1. I changed that and now I have an address match. However, when the TWR-MECH sends the 2 other bytes (command and data), both arrive with C0 hexa value, regardless the transmitted value. Using an osciloscope I noticed that the TWR-MECH firmware uses a SCL  on 178kHz. Is it too high? The accelerometer module, which also uses I2C, is working correctly.

If I have to slow down SCL, that will be a lot of work, because I will have to make changes on the TWR-MECH firmware for the FSLBOT, which is written in MQX.

Thanks for your help.

[JimDon]

How long are the wires? Do the rise times look ok?

I doubt that 178K is a problem.

I will have to look back at the spec to see what else might be wrong.

[quevedo]

Wires are not very long. Actually I have placed the EL16 in a small PCB that is the same size as the accelerometer board used in the TWR-MECH board. My intention is to add extra PWM channels, and this module fits into the second module space within the main board.

I will have to check on rise times. I will compare them with and without the module connected.

By the way, I have added some variables to check on the IICS status after each step of IIC slave receive. After address matching, I make a dummy read on IICD to clear IICS:TCF bit. Right after that, IICS value is 0x60. After first byte sent (command), I have 0x62 on IICS. And after second byte (data), IICS is also 0x62. Thus, TCF bit is being clear after each received byte, and the interrupt pending flag is set after the command byte. As I do not use I2C interrupts, I suppose this is not an issue.

I am thinking about loading a new program inside the TWR-MECH to send I2C commands at  a lower bit rate, but that would demand to run 2 debug sessions simultaneously (one for the module, other for the TWR-MECH). I can erase the original TWR-MECH firmware also, and load the test program into its FLASH.

Thanks for the help

[JimDon]

Doubt it is the clock rate.

 Did you see what was happening on the buss? Do you see a data transfer?

[quevedo]

I don't believe in clock rate problems either. After all, my device recognizes its address being sent by the main board.

The tests I did for SCL frequency were based on an old analog scope I have in my research lab. It is weekend now, so it is time to rest a while from my duties. Next week, I will pick up a better scope in our lab complex to check up what the main board is sending out, and if the module is sending back ACK signals.

Once again, thanks for your help. I will post my findings as soon as I have them.

[quevedo]

Hello again,

After my last post I had had some thoughts about my problem. First of all, the wrong bytes I receive are always C0, which is the 60 hexa from the address, shifted one bit to the left. It means that my module is receiving the address byte with R/W = 0 for 3 times in a row. If I remember what I saw in the analog scope, in SDA I had one burst of bits followed by a longer time of high level.

I did the same test with the accelerometer board that is already installed in the TWR-MECH board (writing to one of its internal registers), and in the scope I could see 3 bursts of bits with a small time interval between them, and then a longer time interval between the groups of 3 bursts.

It seems that the slave module is not sending ACK on SDA after the address match. Thus, the cycle is aborted by the master, but the module waits for the command byte. In the loop of the TWR-MECH program, it tries to send the full frame again, and starts with the address again. The module receives this address as if it was the command. Without the slave ACK, the same thing happens to the slave data.

I believe the problem is the absence of the ACK signal that should be generated by my module, after address matching and after every supposed data receive by the slave. I have not confirmed that yet with a digital scope, but i am quite sure that this is the problem.

I thought that the I2C interface within S08 controllers would generate ACK automatically.  Should I add something in my software to do so? Or maybe the hardware should do that by itself, but I have configured something wrong.

Any hints about it?

Thanks

[quevedo]

Hello,

Things are worse than I thought.

The signals I had mentioned in my previous post were collected while my EL16 module was disconnected. I was reading the signals of the TWR-MECH board without any extra module connected, only the original accelerometer module. Thus, when I tried to write on IIC address 0x60, there was nobody to ACK, and the cycle was aborted.

When I connect my module and try to write something on address 0x60, the SCL and SDA lines are pulled low, and stay low until I remove power from the board. I tried to write on IIC while my module was on BDM, with a breakpoint right after address match, and the result was the same. It means that as soon as an address match happens, my module pulls SDA and SCL low, and keeps them that way. The TWR-MECH board stops responding serial commands, probably because it is stuck on IIC routine, trying to regain bus control.

Thus, for some reason, my module pulls both lines low when there is an address match. Any ideas on what is causing this?

Thanks