Rwvb Just some thoughts. What programmer are you using? If a PICKit3 can you single step in debug mode and view the SFR registers. Cheers and good luck!

An alarm clock using six 7-segment displays is used in this project to display the time in HH-MM-SS format using a micro controller ATMEL-89s8252. Dedicated Clock and Alarm chips seem to have vanished after the micro controllers took over and only a micro controller with an RTC. Ds1307 Bascom Program. Micro SD card Tutorial How to add lots o' storage with microSD (and SD) cards. Ds1307 Bascom Programming.

I am using a Pickit2. I tried single stepping through the code. PORTB looks toggling. With the changed pullup resistors to 3k3, the SFR's looks thus.

The transitions are indicated with '->' on single stepping. It still doesn't make any sense to me that 'Acknowledge was not received from slave' TRISB=0xff SSPBUF=0xd0 SSPADD=0x77 SSPSTAT=0x00 ->0x80 ->0x88->0x8d->0x8c->0x88 SSPCON2=0x00 ->0x01 ->0x00 ->0x40 PIR2=0x00 PORTB=0x00->0xa0. ->0xb8->0xb0->0xb8->0xb0->0xb8->0xbd->0xbf.0xbd Regards, Manu.

Rwvb The SFR's look okay to me but I'm no expert! Have you tested the voltage on the DS1307? The voltages look okay. Vcc = 4.9V Vbat = 3.2V X2=2.9V X1 ~= 0V Unless I can write to the control register over I2C, I won't be able to start the oscillator on the DS1307. I have a LED connected to SQWV out with a BS170 MOSFET to indicate the square wave. With the code in place, I should be able to see a clean 1Hz flash on the LED. But, since the writes are failing, the oscillator fails to start up, also I don't have any square wave out.

Regards, Manu. Hi all, I did a bit more debugging. Connected a Bus Pirate to SCL and SDA pins (1) did a scan for I2C devices: Searching I2C address space.

Found devices at: 0xD0(0x68 W) 0xD1(0x68 R) (2) Put the Bus Pirate into I2C snoop mode, trying to read the data on the bus. And it goes on till hell's end (3) Changed the Bus pirate from Snoop mode to Write Mode and wrote the following I2C>[ 0xd0 0x00 0x00 0x00 0x17 0x01 0x13 0x02 0x12 0x90 ] where '[' = START bit and ']' = STOP bit Got a response on the console: I2C>[ 0xd0 0x00 0x00 0x00 0x17 0x01 0x13 0x02 0x12 0x90 ] I2C START BIT WRITE: 0xD0 ACK WRITE: 0x00 ACK WRITE: 0x00 ACK WRITE: 0x00 ACK WRITE: 0x17 ACK WRITE: 0x01 ACK WRITE: 0x13 ACK WRITE: 0x02 ACK WRITE: 0x12 ACK WRITE: 0x90 ACK I2C STOP BIT I2C>And the DS1307 became alive, the 1Hz Square wave LED started flashing. So, it can be deduced that my code to write to DS1307 I2C for the 18F4550 is wrong, which can be verified from the I2C snoop log Now my question is, what's wrong with my I2C code, since the hardware is functioning as expected? Thanks, Manu. Abraham.manu DarioG Strange. What is the actual speed of the I2C clock? 18F4550 with 20MHz xtal, Fosc = 48MHz, I2C bus speed =100kHz, SSPADD=((48,000,000/100,000)/4)-1 = 119 Bus pirate snooped @100kHz, wrote @100kHz succesfully.

Regards, Manu Finally, Enabling SLEW got the communication to work. I2C>(2) Sniffer Any key to exit [0xD0+0x00+0x00+0x00+0x17+0x01+0x13+0x02+0x12+0x90+] DS1307 is alive. Wonder why the datasheet states disable SLEW for 100kHz. At least things are a bit sane now. Regards, Manu. Abraham.manu abraham.manu DarioG Strange.

What is the actual speed of the I2C clock? 18F4550 with 20MHz xtal, Fosc = 48MHz, I2C bus speed =100kHz, SSPADD=((48,000,000/100,000)/4)-1 = 119 Bus pirate snooped @100kHz, wrote @100kHz succesfully.

Regards, Manu Finally, Enabling SLEW got the communication to work. I2C>(2) Sniffer Any key to exit [0xD0+0x00+0x00+0x00+0x17+0x01+0x13+0x02+0x12+0x90+] DS1307 is alive. Wonder why the datasheet states disable SLEW for 100kHz. At least things are a bit sane now.

Regards, Manu Disconnecting the Bus Pirate from the I2C bus brought the problem back. Simply connecting the Bus Pirate gets the communications to work properly. Any idea, what could be the cause?

Pullup impedance? (Reflections on the bus?) Thanks, Manu. WaltR What is your hardware setup? Both devices (I2C Master & Slave) on a PCB two PCB's with wires between them?

Or a plugin protoboard? What is the distance between devices? I have have issues when using a plugin protoboard whereI2C worked if a scope probe is connected. 18F4550 is the I2C Master, DS1307 is the I2C Slave, I2C bus running @100kHz The DS1307 is on a board and the 18F4550 is on another board, both connected together with a short 15cm cable. The Bus Pirate is connected to the DS1307 PCB rather than the 18F4550 board.

You can see it in this following picture. I have used much longer wires for I2C debugging, in which case it was about 30-40cm long, the I2C master being a PCI express bridge on a PCIe slot in a PC and the Slaves also on the sane PCB, while the Bus Pirate was connected over the longer cable in comparison. Quite lot of debugging sessions went ahead smoothly that way.

The still shorter cable between the 18F4550 and the DS1307 makes me wonder. I thought the issue could be likely due to FEXT (Far End Cross Talk) but trying to slow things down a bit with 22pF ceramic caps on SDA and SCL to GND also doesn't seems to make any difference at all.

Wonder how else this could be solved, other than going in for a single PCB. Regards, Manu. I found that with a PICkit3, when programming the PIC, it goes through several reset sequences before actually getting down to programming.

During these aborted resets, the I2C lines wiggle rudely (and uncontrollably). I previously found, on an old project, that certain sequences if I2C control signals can apparently get the DS1307's I2C state machine into a non-recoverable state. I found this when testing some buggy I2C code that was supplied with another (non-PIC) processor. (That's another story---don't get me started.) Anyhow.

Your problem sounds kind of familiar (and a little unsettling), so I decided to run some tests. Here's my test setup: Similar to yours, with a PIC18F4550 on an externally-powered FSUSB demo board with the DS1307 (and a couple other circuits) on a separate perf board. Power was supplied to the DS1307 from the +5 Volts on the FSUSB board through jumper wires something like 15 cm long. Since there were no pullups on the I2C lines, I put a couple 2.7K resistors on a solderless breadboard, so the actual connections for power and I2C lines were in two stages. FSUSBSolderless BreadboardDS1307 Board I tested with C18 version 3.40 and with XC8 version 1.12 running from MPLABX version 1.80 on my Centos 6.4 Linux workstation.

With your I2C code, as well as with some code that I might usually implement (using I2C_EEPROM functions), the DS1307 sometimes works and sometimes becomes non-responsive to the I2C commands after programming, so I can't read or write the registers. I tried extra bypassing, mild filtering on the I/O lines, etc., and nothing made a perceptible difference. The thing is that two quite different sets of code give bad results even though the code itself (I think) is valid. Now, here's the big thing: Note that, after programming, I can power-cycle the FSUSB board (along with the DS1307) and everything starts working. I tried various delays at the beginning of the program and I think it might have improved a little, but still had frequent failures when programming. I still think that those incomplete and partial reset sequences during programming are screwing the pooch.

I used an I/O pin from the '4550 to power the DS1307. At the beginning of the program, I set that pin to be an output and set its value low for a little while and then set it high. I haven't had any failure-to-launch problems since.

An additional note: I have used I2C for numerous other devices, on-and off-board and have never seen this particular problem. For example I have a frequency synthesizer test setup using a Silicon Labs SI5338 development board with power and I2C interface lines supplied from my PIC18F25K50 breadboard.

(Length of the connecting wires is about 15 cm.) No particular extra care was required in signal conditioning, software restarts, or anything else. I have programmed this module hundreds of times (maybe more) with never a problem.

I looked at the I2C lines on a 'scope, and they are wiggling like crazy during programming with the PICkit3. This device has something like 350 registers. I read and write these registers immediately after programming and frequently during normal operation. If it ever got into an un-recoverable state, I would really, really know it. That has never happened with this particular device.

Bottom line: I think the key is to power-cycle the DS1307 after programming with a PICKit. IWFMYMMV (It Works For Me; Your Mileage May Vary.) Regards, Dave. Davekw7x I found that with a PICkit3, when programming the PIC, it goes through several reset sequences before actually getting down to programming. During these aborted resets, the I2C lines wiggle rudely (and uncontrollably).

I previously found, on an old project, that certain sequences if I2C control signals can apparently get the DS1307's I2C state machine into a non-recoverable state. I found this when testing some buggy I2C code that was supplied with another (non-PIC) processor.

(That's another story---don't get me started.) Anyhow. Your problem sounds kind of familiar (and a little unsettling), so I decided to run some tests. Here's my test setup: Similar to yours, with a PIC18F4550 on an externally-powered FSUSB demo board with the DS1307 (and a couple other circuits) on a separate perf board. Power was supplied to the DS1307 from the +5 Volts on the FSUSB board through jumper wires something like 15 cm long. Since there were no pullups on the I2C lines, I put a couple 2.7K resistors on a solderless breadboard, so the actual connections for power and I2C lines were in two stages. FSUSBSolderless BreadboardDS1307 Board I tested with C18 version 3.40 and with XC8 version 1.12 running from MPLABX version 1.80 on my Centos 6.4 Linux workstation.

With your I2C code, as well as with some code that I might usually implement (using I2C_EEPROM functions), the DS1307 sometimes works and sometimes becomes non-responsive to the I2C commands after programming, so I can't read or write the registers. I tried extra bypassing, mild filtering on the I/O lines, etc., and nothing made a perceptible difference. The thing is that two quite different sets of code give bad results even though the code itself (I think) is valid. Now, here's the big thing: Note that, after programming, I can power-cycle the FSUSB board (along with the DS1307) and everything starts working. I tried various delays at the beginning of the program and I think it might have improved a little, but still had frequent failures when programming.

I still think that those incomplete and partial reset sequences during programming are screwing the pooch. I used an I/O pin from the '4550 to power the DS1307. At the beginning of the program, I set that pin to be an output and set its value low for a little while and then set it high.

I haven't had any failure-to-launch problems since. An additional note: I have used I2C for numerous other devices, on-and off-board and have never seen this particular problem.

For example I have a frequency synthesizer test setup using a Silicon Labs SI5338 development board with power and I2C interface lines supplied from my PIC18F25K50 breadboard. (Length of the connecting wires is about 15 cm.) No particular extra care was required in signal conditioning, software restarts, or anything else. I have programmed this module hundreds of times (maybe more) with never a problem. I looked at the I2C lines on a 'scope, and they are wiggling like crazy during programming with the PICkit3. This device has something like 350 registers. I read and write these registers immediately after programming and frequently during normal operation. If it ever got into an un-recoverable state, I would really, really know it.

That has never happened with this particular device. Bottom line: I think the key is to power-cycle the DS1307 after programming with a PICKit. IWFMYMMV (It Works For Me; Your Mileage May Vary.) Regards, Dave Thanks for the pointer. As you stated, the issue you mention exists when the PIC is being programmed. But AFAICS, the issue exists when the PIC is powered up (after it is programmed too) Another thing that I would like to mention. I have hooked up a 7 segment display, to output error codes on it (after the Bus Pirate has been disconnected) The display will display the error code from WriteI2C(). If WriteI2C() didn't have any errors, the display will simply output the number of bytes transferred over I2C to the Slave.

So, after the Bus Pirate has been disconnected, I do see '9' on the display instead of '2' (2 is the return value from WriteI2C() when the Slave does a NACK). A 9 indicates that 9 bytes got transferred to the DS1307 without any errors and that the DS1307 did provide an ACK as what was expected. Even when '9' is displayed (without the Bus Pirate connected), the DS1307 is 'not alive'. But becomes alive as soon as the Bus Pirate is connected.

I guess, the initial issue that the DS1307 was not getting initialized due to the Slave NACK's might not be true after all. (There are times where even with the Slave ACK, the DS1307 is not getting initialized as what is expected of it). It is not the programming sequence that confuses the DS1307 either. Struggling to find out, what the real issue is hiding in there. Regards, Manu.

The I2C(I Squared C) communication means ' Inter-Integrated Circuit ' communication. Card Rescue Mac Serial Terminal. A microcontroller can communicate with low power peripherals through I2C.To make a successful I2C communication we just need two ends or pins[ SCL and SDA ].Here SCL for clock selection and SDA for data. Both SCL and SDA are Open Drain drives that means the chip can drive it's low output and cannot drive the high output. It 's required to connect two pull up resistors in such way that one end of both resistors with +5v and others end with SCL, SDA respectively so that the higher output can be driven.The pull up resistors value will be according to the I2C bus frequency.We are using 2k Ohm pull up resistor in this Tutorial.

Here in I2C1_Rd(0); To read data we will use Readdata(adrs) function and it is a user defined function. In 'Readdata(0);' function we will write 0 as argument and the 0 means address of Seconds Register.This function returns short type data in BCD. I this way we can read data from each address.An important thing needed to notice that bit 6 of hour register is defined as the 24-hour or 12-hour mode selection bit.If we select 1 the bit 5 of hour used for representing AM/ PM and if we select 0 the bit 5 used for representing hour.

Real time clock DS1307 interfacing with Arduino, In this article you will learn how to interface real time clock DS1307 with Arduino. What is real time? Why real time clock is used? What is dedicated integrated circuit for real time clock? How to make digital clock using Arduino and integrated circuit DS1307? What are application of real time clock DS1307? Hardware connections of liquid crystal display 16 X 2 LCD and real time clock DS1303 with Arduino.

How to use library of real time clock to display time and date on LCD? You will get answers of all your questions in this article. What is real time clock?

As it name suggests, real time clock is used to keep record off time and to display time. It is used in many digital electronics devices like computers, electronics watches, date loggers and situation where you need to keep track of time. One of the great benefits of real time clock is that it also keep record of time even if power supply is not available. Now the question is how can a electronics device like real time clock work without use of power supply. Because it have small power cell of about 3-5 volt inside which can work for years. Because real time clock consume minimum amount of power. There is many dedicated integrated circuits are available in market which is used to make real time clock by adding necessary electronic components.

But in this article I will discuss DS1307 real time clock IC. DS1307 IC for real time clock: DS1302 is IC for real time clock which is used to count seconds, minutes, hours, days, months any years. It use I2C communication protocol for communicating with other devices like in our case we are using Arduino. Arduino read values of time and date from DS1307 using I2C communication protocol. It also have feature to keep record of exact time in case of power failure. It is a 8 bit IC.

It is used to make real time clock using some other electronic components. Pin configuration of DS1307 is given below. Pin configuration of DS1307 Functionality of each pin is given below: • pin number one and two is used for crystal oscillator. Crystal oscillator value usually used with DS1307 is 32.768k Hz. • Pin three is used for back up battery. Its value should be between 3-5 volt.

Voltage more than 5 volt may burn DS1307 permanently. Back battery is used to keep track of time in case of power failure to DS1307. After getting power DS1307 shows correct time due to back up battery. • pin 4 is ground pin of power supply. • pin 5 and 6 is used to communicate with other devices with the help of I2C communication protocol. • pin 5 is serial data pin and pin 6 is serial clock.

If you don’t know about I2C communication, i recommend you to learn about it. • Pin 8 is used for 5 volt power supply. You need external components to connect with DS1307 to use it as a real time clock. Circuit diagram with necessary components is given below. Circuit diagram of DIgital clock using real time clock and Arduino result In above code “#include “RTClib.h”” is used to include library of real time clock. If you don’t have already library installed in your Arduino IDE compiler. You can add it very easily.

Download library from given below link. After downloading code, abstract the code and paste the file into libraries folder of Arduino UNO folder. You can also use above library for days. Good luck for your project. Kindly don’t forget to share it with your friends thanks 🙂.