4
\$\begingroup\$

I'm having trouble with getting the DS1307 RTC to work. I'm talking to it via an Arduino, and I'm just trying to get an example sketch to work. I've tried two different libraries - one from Ladyada, and one from Seeedstudios. Electrically, I have both the Arduino and the RTC powered by 5V, and the RTC's VBAT input grounded (per the datasheet, since I'm not using a battery during testing). I'm building using the Arduino-0022 IDE. I've got 10k pullups on the SDA and SCL lines. I've traditionally used smaller pullups on the I2C bus (e.g. 3.3k or 4.7k), but I don't think that's my issue.

Both libraries basically indicate that the data being returned by the device is all zeroes for the date and time. So I went and captured the I2C traffic using an oscilloscope (using the Seeedstudios library) and here's what it looks like:

enter image description here

That exact transaction repeats at a regular interval. The yellow trace is SCL, the blue trace is SDA. How do you interpret that I2C exchange? I have my own theories, but I'm looking for an independent assessment. Given that trace, do you think the DS1307 is cooked? Do you think it's a software problem? Other ideas?

\$\endgroup\$
2
  • \$\begingroup\$ The DS1307 will only work in the I2C 100KHZ mode, although it looks like your sweeping @ 40µs/cm. Is the 32KHZ oscillator oscillating? \$\endgroup\$
    – SteveR
    Commented Dec 19, 2011 at 22:31
  • \$\begingroup\$ The only things I can think of right now are: 1. The master pins are not being set to high impedance for high level. 2. The DS1307 SDA/SCL/Vdd/Vss/Xtal is not connected properly. 3. If no battery present, the battery pin is not connected to ground. 4. The DS1307 is faulty. \$\endgroup\$
    – Oli Glaser
    Commented Dec 19, 2011 at 23:43

2 Answers 2

Reset to default
2
\$\begingroup\$

You probably have the target chip address wrong. You are sending 68h. Either that is not the address of the chip or it is not wired right. The two sequences you show are first a write then a read to that address. In both cases, no ACK was received so the sequence was terminated. Check the datasheet for the chip address.

Added:

I just looked in the datasheet, and the address of that chip really is 68h (page 12), so that's not the issue. That leaves something not wired right at the chip. Your scope traces look good in that a correctly wired and working chip should have responded with ACK as far as I can tell.

\$\endgroup\$
2
  • \$\begingroup\$ Yea that's what I thought too. DS1307 is NAKing right? \$\endgroup\$
    – vicatcu
    Commented Dec 20, 2011 at 1:40
  • 1
    \$\begingroup\$ @vicatcu: More precisely, it is not ACKing. Specifically NACKing implies a deliberate response. In this case the chip is not replying at all. You would get the same response if the chip were in a drawer and nothing was connected to the IIC bus. This is why you need to look at the electrical connections very carefully. Look at the signals on every pin right at the chip while having the datasheet open and checking that each is correct. \$\endgroup\$
    – Olin Lathrop
    Commented Dec 20, 2011 at 12:53
0
\$\begingroup\$

The address is incorrect. The address is 7 bits which is 0x68 but you need to add the R/W bit. Writing would be 0 and reading is 1. Which would make it 0xD0 for writing.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ yes, you see effectively 0xD0 for a write and 0xD1 for a read. But that is what is depicted in the waveforms above. 11010000 (0xD0) and 11010001 (0xD1) respectively, so I'm not sure what your response is suggesting might be wrong... \$\endgroup\$
    – vicatcu
    Commented Dec 22, 2011 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.