Re: Struggling with I2C

[Robert Reese]

First, we use these functions all the time to talk to a variety of I2C devices in our ECE 3724 course and senior design course, with a variety of PIC24 CPUs.

A few questions:

a. What is the part number of your sensor?
b. What is the part number of your PIC24? (some PIC24F devices have errata concerning the I2C interface).
c. Why are you using the 'putNoAckCheckI2C1' function? If this is a normal I2C device,  you should just use the 'putI2C1' function which checks to ensure that the device returned the expected ack bit.  The 'putNoAckCheck' is somewhat special purpose for cases where the device uses the ack bit as ready bit, like the Microchip LC515 serial eeprom.    If the 'putI2C1' function times out and a software reset is generated, then this means the device is not returning the expected ACK and either the address byte is wrong (which does not seem the case here), or the physical bus is messed up somehow (no pullups?).

d. You should not need the DELAY_MS(1) function calls unless the sensor data sheet explicitly calls for a delay between reading of the return bytes.

e. Are you absolutely sure that that CO2 sensor returns 7 BYTES of data and not 7-bits of data (i.e., only one byte?)?  If it only returns one byte of data, this would explain why your program is stopping during the read transaction.  It would be an unusual C02 sensor that would require 7-bytes of data to encode a CO2 reading.

Regards,

 Bob R



On Monday, January 14, 2013 10:08:55 AM UTC-6, Andy Zehnder wrote:

Hello,

is there anybody out there having experiences with the I2C functions from the library?

I am using the I2C interface to communicate with a CO2 sensor.

In the datasheed, the following is written about the communication: 

1) I2C Start Condition

2) Write Command(Slave Address + R/W Bit(0) = 0x62) Transmission and Check Acknowledge

3)..Write Command(ASCII ‘R’ : 0x52) Transmission and Check Acknowledge

4) I2C Stop Command

5) I2C Start Command

6) Read Command(Slave Address + R/W Bit(1) = 0x63) Transmission and Check Acknowledge

7) Read 7 Byte Receiving Data from Module and Send Acknowledge

A part of my main function looks like this (only for testing purposes):

int main (void) {

configBasic(HELLO_MSG);

initLGT_SENSOR();

configHeartbeat();

configI2C1(100);

value1 = 0x21;

value2 = 0x22;

value3 = 0x23;

value4 = 0x24;

value5 = 0x25;

value6 = 0x26;

while (1) {

    doHeartbeat();

    startI2C1();

    value1 = putNoAckCheckI2C1(0x62);

    value2 = putNoAckCheckI2C1(0x52);

    rstartI2C1();

    value3 = putNoAckCheckI2C1(0x63);

     value4 = getI2C1(0);

    DELAY_MS(1);

      value5 = getI2C1(0);

    DELAY_MS(1);

    value6 = getI2C1(0);

    DELAY_MS(1);

    value7 = getI2C1(0);

    DELAY_MS(1);

    value8 = getI2C1(0);

    DELAY_MS(1);

    value9 = getI2C1(0);

    DELAY_MS(1);

    value10 = getI2C1(1);

    stopI2C1();

}

I get acknowledges until value 3. If I do the function getI2C to get value 4

the program stops.

I figured out that if stops while waiting for the finish of

  while (!I2C1STATbits.RBF);   in the getI2C.

In the oscilator plot i can see, the sensor is transmitting his data. But at the

end, something goes wrong, I guess. 

Anybody out there with an idea?

thx

Andy

[Andy Zehnder]

Dear Bob,

thx for your fast response.

to 

a) it is a s-100 sensor, as you can see in the datasheet.

b) it is a PIC24FJ64GA002 on the board I do, but it does also not work with the explorer16 board with the pic24FJ128GA010

c) I have used the putNoAckCheckI2C1 function to see in the returned value, if it returns a ACK or not. I changed it to the mentioned function but it still remains a break during the getI2C1 function in the "while (!I2C1STATbits.RBF);" statement. If you see in the second plot, the sensor returns a =0x08, as written in the datasheet. But than, both signals go high, the clock stops, instead of toggling to send out the ACK.

d) the delay of 1 ms is from the sensors datasheet.

e) the sensor returns 7 bytes of data.

the funny thing of all is, It worked about a half a year ago. and now, same setup, same software, no function. I first did on the explorer16 board. than I built my pcb. now, on that an on explorer16, it will not work

as in "c", the sensor starts returning the data, 0x08, as you can see on page 6 of the datasheet.Something goes wrong than. 

Do you have any idea?

Thanks

Regards

Andy

(ps. sorry about my english.... it's not my mother tongue...)

[Robert Reese]

OK -- thanks for the detailed response. 

 I see is that this device has internal pullups on the I2C bus, so you don't need external pullups (not sure if you have these are not).

I don't know what is going on. If the device is correctly returning a '0x08' as the first byte read, and the PIC24F is not sending an ACK back, then it is a fault on the PIC24F side.

I do know that I have had I2C problems with the PIC24F64GA002 in the past - I2C seems hit and miss with this device -- there is some errata  on this in on the Microchip website and also on the Microchip forums.  I had one device (an infrared temp sensor) that would not work with the PIC24F64GA002 with a similar problem, and I finally had the students switch to a PIC24H and then everything worked fine (same code).   You may want to try a PIC24F64GA102 -- this is a later device, pin compatible, and may have fixed this errata.

Do a search on the Microchip forums about the PIC24FGA002 and you will see the posts that I am referring to.

--
You received this message because you are subscribed to the Google Groups "PIC24 Assembly-to-C Book" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pic24-assembly-to-c-book/-/NGYyL1xE_20J.

To post to this group, send email to pic24-assemb...@googlegroups.com.
To unsubscribe from this group, send email to pic24-assembly-to-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pic24-assembly-to-c-book?hl=en.

[Andy Zehnder]

Thank you for the response.

I've had a look at the microchip forums, it seems to be a problem with this processor, the I2C won't receive correctly datas.

I already ordered some of the PIC24FJ64GA102, will test them when I get it. I will let you know about the results.

Thank you very much for your help....

regards

Andy

[Andy Zehnder]

It works now, with the PIC24FJGA102.

I am also using the PWM. What I found out, that there are some other registers to configure, not only the OSCON.
I found the configuration in your led_pwm listing.

65 #if (defined(__dsPIC33E__) || defined(__PIC24E__))

66 //turn on the compare toggle mode using Timer2

67  OC1CON1 = OC_TIMER2_SRC | //Timer2 source

68  OC_PWM_CENTER_ALIGN; //PWM

69  OC1CON2 = 0x000C; //sync source is Timer2.

It is for PIC33E and PIC24E....

To make this work I had to copy the definition of  OC_PWM_CENTER_ALIGN from the commented part.

I guess you know what I mean.