I2C reading problem - PCF85063A

[danvica]

I'm stuck trying to interfacing a RTC (PCF85063A)

It seems bit 7 of every byte that it's been read is set to 1.

To debug I'm trying to write/read a value into device's RAM cell (reg 0x3)

In the below example it writes 0x05 and it reads 0x85.

Here are the oscilloscope views of write and read cycles:





and here is the test code:

Code: Select all

#include "esp_log.h"
#include "driver/i2c.h"

#define ONBOARD_LEDRED              32
#define ONBOARD_LEDBLUE             33


static esp_err_t i2c_master_init(void)
{
    i2c_config_t conf;
    
    conf.mode = I2C_MODE_MASTER;
    conf.sda_io_num = (gpio_num_t)21;
    conf.scl_io_num = (gpio_num_t)22;
    conf.sda_pullup_en = GPIO_PULLUP_DISABLE;
    conf.scl_pullup_en = GPIO_PULLUP_DISABLE;
    conf.master.clk_speed = 100000L;
    
    i2c_param_config(I2C_NUM_0, &conf);


    i2c_driver_install(I2C_NUM_0, I2C_MODE_MASTER, 0, 0, 0);
}

void writei2c(uint8_t reg,uint8_t value)
{
    i2c_cmd_handle_t cmd = i2c_cmd_link_create();
    i2c_master_start(cmd);
    i2c_master_write_byte(cmd, (0x51 << 1) | I2C_MASTER_WRITE, true);

    i2c_master_write_byte(cmd, reg, I2C_MASTER_ACK);
    i2c_master_write_byte(cmd, value, I2C_MASTER_ACK);
      
    i2c_master_stop(cmd);
      
    i2c_master_cmd_begin(I2C_NUM_0, cmd, 1000 / portTICK_RATE_MS);
      
    i2c_cmd_link_delete(cmd);
}

uint8_t readi2c(uint8_t reg)
{
  uint8_t rbyte;

    i2c_cmd_handle_t cmd = i2c_cmd_link_create();
      
    i2c_master_start(cmd);
    i2c_master_write_byte(cmd, (0x51 << 1) | I2C_MASTER_WRITE, 1);
    i2c_master_write_byte(cmd, reg, 0);
      
    i2c_master_start(cmd);
      
    i2c_master_write_byte(cmd, (0x51 << 1) | I2C_MASTER_READ, 1);
    i2c_master_read_byte(cmd, &rbyte,  (i2c_ack_type_t)1);
      
    i2c_master_stop(cmd);
      
    i2c_master_cmd_begin(I2C_NUM_0, cmd, 1000 / portTICK_RATE_MS);
      
    i2c_cmd_link_delete(cmd);

    return rbyte;
}

void setup() {
    Serial.begin(115200);
        
    i2c_master_init();
        
    delay(500);
        
    writei2c(REG_CTRL1,0b00000011);

    delay(100);
      
    pinMode(ONBOARD_LEDRED,OUTPUT);
    pinMode(ONBOARD_LEDBLUE,OUTPUT);
}

void loop() 
{
    uint8_t datr=0;
      
    writei2c(REG_RAM,5);
      
    delay(2);
      
    datr=readi2c(REG_RAM);
      
    Serial.printf("Reg 0x3: %3u %3u",datw,datr);

    delay(100);
}

Any help is really appreciated, thanks...

[Jamawa]

Hi,

On first glance, I see nothing wrong, so let’s see. Just to be sure; the waveforms suggest that external pull-up resistors are present on both lines as they should, is that correct?

Then, I see that there is currently no error checking in the subroutines. I would like to suggest to have them during initialisation, writing and reading, that way you can be sure that the calls were successful. Especially the i2c_master_cmd_begin calls are of interest, they should give a ESP_OK result.
If they indicate no errors, then maybe try to write to a register and see if that good as expected. A good candidate could be programming register Control 2, especially the COF bits: they will set the CLKOUT frequency which you can verify using the scope. If that gives the correct frequencies, you’ll know that the writing part goes as desired.
If not, check the I2C protocol diagrams in the datasheet and compare them to the scope results (I’d like to suggest to separate SCLK and SDA graphs and not overlay them, it will make reviewing easier).

Once that is successful, try the test again and see what happens. If it still fails, compare the I2C protocol diagram for reading in the datasheet with the scope result. It should match, including the ACK/NAK bits, even if the last NAK should have no effect for the byte read. If that gives no result, try reading the value from register Control 2 back, you can alternate bit 7 to test that especially.

The above should give some result or at least suggestions as to what is wrong.

Cheers,
Jan Martin

[danvica]

Thanks for the reply.

Yes, 12K resistors are present on both SDA and SCL lines. I however tried enabling/disabling internal pull-ups resistors without any visible effect.

I've removed the error checking lines in the sample test I've enclosed, both i2c_master_cmd_begin calls return OK (0).

I'll try your suggestion about enabling COF bits, thanks.

I'll also try to further debug the low-level protocol, however, the decoding routine of my oscilloscope already recognizes the signal in the right way (see lower graph in the previous pictures)

I'd also like to try my own low-level version routine of the I2C protocol but I think I'll just reproduce what you already can see on the oscilloscope and I don't see anything wrong with it.

Thanks.

[Vader_Mester]

Thanks for the reply.

Yes, 12K resistors are present on both SDA and SCL lines. I however tried enabling/disabling internal pull-ups resistors without any visible effect.

I've removed the error checking lines in the sample test I've enclosed, both i2c_master_cmd_begin calls return OK (0).

I'll try your suggestion about enabling COF bits, thanks.

I'll also try to further debug the low-level protocol, however, the decoding routine of my oscilloscope already recognizes the signal in the right way (see lower graph in the previous pictures)

I'd also like to try my own low-level version routine of the I2C protocol but I think I'll just reproduce what you already can see on the oscilloscope and I don't see anything wrong with it.

Thanks.

I have the feeling that either the SCL or the SDA line is offset by half a period.

Lately I had a lot of issues just declaring a

Code: Select all

i2c_config_t conf;

struct, or any such struct.
Nowadays I always declare stuff with

Code: Select all

i2c_config_t conf = {0};

to make sure that memembers are created as NULL.
It has fixed for me a lot of problems.

Also, you should try to use a lower SCL frequency, say 10kHz, and see if you have the same issue there, and work your way up.

[danvica]

Thanks for the hint about i2c_config_t declaration ! I'll try that too.

About the clock frequency, actually the graphs enclosed in the first message have been made using 10KHz (just because the shapes of the rising fronts are obviously better). I found no difference compare to 100KHz, though.