I have found over the years that except in speed-critical or multi-master applications, it's actually easier to bit-bang an I2C master than to try to use the I2C facilities built into many chips.
Note that if a device uses clock stretching, any time you release SCK, you must wait for it to actually go high. For simplicity, such delays are omitted from the following descriptions, but should be included if appropriate in your "release_SCK()" routine.
To start an I2C transaction, release SCK (if it isn't already) and, if the data line is low, assert SCK (drive it low), release SDA (if it isn't already), and release the SCK. Repeat this process up to nine times until SDA is high. If SDA is still low after nine repetitions, the bus is unusable.
To output each byte (including the address byte), assert SDA, and then for each bit repeat the sequence (assert SCK; set SDA high or low to match next bit of data; release SCK) eight times. After the last bit, assert SCK, release SDA, and release SCK. If SDA is low, a slave is acknowledging; if SDA is high, no slave is acknowledging and the transaction should be aborted.
When all output is complete, assert SCK, then SDA, and then release SCK, then SDA.
To input each byte, assert SDA, then release SCK if it isn't already (it will be for the first byte, but not others). Then reassert SCK, release SDA, and repeat the sequence (release SCK, read data bit, assert SCK) eight times. Note that at the end of this sequence, unlike when outputting a byte, SCK will be left asserted.
When all input is complete, release SDA (it should already already be released) and SCK.
Note that because the clock is left asserted after inputting each byte, it's not necessary to specify whether the byte should be ack'ed or nak'ed. If you read another byte, the last byte read will be nak'ed. If you terminate the read, it will be nak'ed.
Start; send address; write one byte, finish
SCK - -__-__-__-__-__-__-__-__-__-- -__-__-__-__-__-__-__-__-__--- -__--
SDA(M) - __777666555444333222111___--- --777666555444333222111000---- --__-
SDA(S) - -------------------------??AA A------------------------??AAA A----
Start; send address; read two bytes; finish
SCK - -__-__-__-__-__-__-__-__-__--- -__--_--_--_--_--_--_--_--__ -__--_--_--_--_--_--_--_--__ _-
SDA(M) - __777666555444333222111------- __-------------------------- __-------------------------- --
SDA(S) - -------------------------??AAA A??77?66?55?44?33?22?11?00?? -??77?66?55?44?33?22?11?00?? ?-
This is easily done using only 2 bytes of RAM if you implement a 256 times over-sampling filter.
You allocate 2 bytes of RAM to form a 16-bit counter. If you look carefully, you will observe that the upper byte contains the full value of the 16-bit counter / 256.
It is this property that makes this filter so easy.
I'm not at my computer, so I'll try to describe what I mean in pseudo code. Let's call the two bytes that form the counter CntrH & CntrL. As described above, the 8-bit value for the final output is contained in CntrH.
First, subtract the old filter value from the counter.
CntrH : CntrL - CntrH
Now add the 8-bit value from the a/d converter to the 16-bit counter.
A2D + CntrH : CntrL
The filtered output is contained in CntrH.
This is a very slow filter. Therefore, you want to seed the filter upon initialization by taking one a/d sample and loading it into CntrH.
This slow filter means that you want to add new samples fairly quickly. A rough approximation is that your desired filter period takes 256 samples.
In other words, add new samples to the filter at the rate of 10 minutes / 256.
This is extensible by going to a 24-bit accumulator if you want to acquire the samples at a faster rate. This would give you a 2^16 (65536) times over-sampling filter.
Same technique as above but using 3 bytes: CntrH : CntrM : CntrL . As before, the 8-bit filtered output is contained in CntrH.
Given that you want the period to be about 10 minutes (600 seconds), you would accumulate your samples at 600 / (2^16) =~ 9.1ms
Since you haven't posted the code or the circuit, we're reduced to making guesses or using our psychic powers. In this case, my guess is that you've wired it up wrongly, and the usual way to do this is to fail to connect something you're not using such as a reset pin.
In the datasheet I see "If a backup supply is not required, VBAT must be grounded" and also "When a backup supply is connected to the device and VCC is below VTP, reads and writes are inhibited. However, the timekeeping function continues unaffected by the lower input voltage".
My guess is that the device is in that state: the timekeeping continues to work, and the data is retained, but the device will not allow you to read it.