RTC's SDA and SCL Resistors

[William B]

Hi! 

I'm installing a real-time clock (RTC) on Beaglbone Black and I'm seeing divergent information abount hardware of the DS1307 integrated circuit, that operates at 5V voltage, while the I2C IO buses of the BeagleBone operate at 3.3V.

In the Adafruit RTC, they indicate removing the SCL and SDA resistors from the DS1305 kit as shown here: 

https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/wiring-the -rtc

In linux.org, nothing is reported about the resistors and there are other places that also do not say anything about the resistors: 

http://elinux.org/Adafruit:_RTC_DS1307

Question:

Should I keep the SCL and SDA resistors? Or should I remove the resistors?

[John Syne]

Connect the pullup resistors to 3v3.

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3e5c2f95-d7d4-47e6-9fd9-6c027792386f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Syne]

Just to be clear, the Adafruit module has 2k2 resistors to 5V. These must be removed. However, the BBB still needs pullup resistors to 3v3.

Regards,

John

On Jul 26, 2017, at 1:42 PM, William B <wbbe...@gmail.com> wrote:

[William B]

John, I get it. But I do not know how it would be possible to do this in my DS1307 module which is of this type:

http://www.ebay.com/itm/5-PCS-I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Module-For-AVR-ARM-PIC-/172308340060?epid=846722400&hash=item281e609d5c:g:VxcAAOSwawpXsn0J

How would It connect to 3.3V hardware instead of 5V?

Thank you again!

[William Hermans]

The page you've linked is 404. But . .

#1 3v3 is the absolute max you want to put on any beaglebone I/O pins ADC lines are max 1v8

#2 If those are pullups, you have to have pullups on any I2C SCL / SDA line.

You need to read the datasheet for that part. If in fact the I2C data and clock lines are 5v, you've got the wrong part. However, I wouldn't be surprised if that part could also be powered by 3v3 too. One wire RTC's can also functionally be powered by multiple voltages. At least the one I'm using( DS3232 ).

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

[John Syne]

OK, if you read the datasheet, you will see VIH = 2v2 and VIL = 0v8, which means the I2C signals are compatible with a 3v3 pullups. The module you referenced has pullup resistors to 5v0, which means they must be removed. There are voltage convertors from TI for I2C devices, but in this case they are not required. However, if you want to leave the 5v0 pullup resistors on the module, then you must use one of these voltage translators. Here is an example:

https://www.sparkfun.com/products/11955

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2b99797f-afbb-4408-a47d-3efcbf10b0d4%40googlegroups.com.

[Greg]

Here is what I used:

https://www.seeedstudio.com/Grove-High-Precision-RTC-p-2741.html

I'm using the Greens so it conveniently plugs in to the Grove connector.  The lithium coin cell was not available at the local stores and I had to order via Amazon.

This device uses 3.3V battery and it is plug-n-play with regards to the hardware.  The Beagleboard distributions include a driver for it.

In addition to confusion with logic voltages, the Linux ecosystem for RTCs is pretty confusing as well.  The man pages have outdated or insufficient information.

It was possible to get the RTC to work without touching the Device Tree.

I've got the RTC to work and it is timing my irrigation control system reasonably well.  I'm still not confident with what I am doing with the hwclock command.

I've documented what I did in the PDF file page 26:

https://github.com/Greg-R/irrigate-control/tree/master/doc/latex

Good luck with the RTC and please share you results here!

Regards,

Greg

[John Syne]

This looks like a much better solution given that this module is powered from 3v3.

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/95bd10e9-2888-4a21-baa0-d2df2536cc8f%40googlegroups.com.

[Greg]

I have 2 of them running here connected to BBGWs and performance is satisfactory so far.

[William B]

I'm convinced that the PCA9306 and the RTC PHILIPS PCF85063TP are excellent solutions. However, removing the resistors I think is not good. I'm going to use the bidirectional I2C-bus translator because it's easier to find where I live.

Thank you everyone for the attention.

PS: William Hermans, the link is working fine for me. I don't understand why it didn't work for you... No problem!

http://www.ebay.com/itm/5-PCS-I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Module-For-AVR-ARM-PIC-/172308340060?epid=846722400&hash=item281e609d5c:g:VxcAAOSwawpXsn0J

[William B]

Hi! 

I bought the I2C logic converter 3.3V => 5v and I've connected the RTC to the BBB, but running "i2cdetect -y -r 1" doesn't find the RTC device. I've checked the wiring of the connections and I repeated the process a few times, but it doesn't detect the RTC.

Any suggestion?

[William Hermans]

#1 You're sure you're connected to I2C-1 ?

#2 Did you load the device tree to get I2C-1 active ? It's not enabled by default.

[Graham]

What version of Debian are you running.

On Debian 8, what was in the docs as I2C-1 is now I2C-2.

Hook your translator to pins P9-19 and P9-20 and run "i2cdetect -y -r 2"

I2C-2 is enabled in the device tree by default.

--- Graham

==

[William Hermans]

It's not so much the debian version, as it is the kernel. kernel 3.8.x is different from kernel 4.x. The easiest way to see what is attached it this:
root@wgd:~# i2cdetect -l
i2c-0   i2c             OMAP I2C adapter                        I2C adapter
i2c-1   i2c             OMAP I2C adapter                        I2C adapter
i2c-2   i2c             OMAP I2C adapter                        I2C adapter

[William B]

Grahan:

You're 100% correct. Running "i2cdetect -y -r 2" instead of "1" at the end, it detected the RTC at address 0x68, as we can see in the available tutorials.

Answering your question, I'm using the latest available Debian release (bone-debian-8.8-iot-armhf-2017-07-01-4gb.img) available here:

https://rcn-ee.net/rootfs/bb.org/testing/2017-07-01/iot/

William Hermans: 

When I run the command "i2cdetect -l", I get this information:

root@beaglebone:~# i2cdetect -l

i2c-0   i2c             OMAP I2C adapter                        I2C adapter

i2c-1   i2c             OMAP I2C adapter                        I2C adapter

i2c-2   i2c             OMAP I2C adapter                        I2C adapter

Now I can continue with the process normally and as soon as it works I report here.

Thank you again!!!

[Graham Haddock]

William B:

If you are using older code examples, now just change all references to I2C-1 to become I2C-2 and you should be on your way.

--- Graham

==

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ZFioCmr8Fy0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3ac8db97-2938-433e-992b-2422278bb1c6%40googlegroups.com.

[William B]

Ok! Thanks for the tip!

[William Hermans]

Sounds about right . ..
root@wgd:~# cat /sys/bus/i2c/devices/2-0068/name
ds3232

Funny, I'm actually using an i2c RTC, forgot, and confused the temp sensor I'm using over one wire. By the way, the DS3232 is also an accurate RTC, but it does cost like $8.xx per. So not exactly cheap.

[William B]

Is there any other difference in this latest version of Debian? I'm following a tutorial below, but the command "hwclock -r -f /dev/rtc1" is indicating failure to communicate with the new device:

TUTORIAL:

https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/set-rtc-time

ERROR:

root@beaglebone:~# hwclock -r -f /dev/rtc1

hwclock: Cannot access the Hardware Clock via any known method.

DEVICES:

root@beaglebone:/# ls -la /sys/bus/i2c/devices

total 0

drwxr-xr-x 2 root root 0 Jul 27 20:19 .

drwxr-xr-x 4 root root 0 Jul 27 20:19 ..

lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0024 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024

lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0034 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0034

lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0050 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050

lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0070 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0070

lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0054 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0054

lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0055 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0055

lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0056 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0056

lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0057 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0057

lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-0 -> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0

lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-1 -> ../../../devices/platform/ocp/4802a000.i2c/i2c-1

lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-2 -> ../../../devices/platform/ocp/4819c000.i2c/i2c-2

[William B]

Just adding:

root@beaglebone:/# i2cdetect -y -r 2

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: 50 -- -- -- UU UU UU UU -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

[William Hermans]

You have to write to the RTC before you can read from it. Something that guide confuses . . . So actually the first steps you need to take is like this:
root@wgd:~# apt-get install ntpdate
root@wgd:~# ntpdate pool.ntp.org
27 Jul 16:39:29 ntpdate[1903]: adjust time server 199.223.248.101 offset 0.004123 sec

Then if it's important to be on the right timezone . . .

( optional )
root@wgd:~# dpkg-reconfigure tzdata

Current default time zone: 'America/Phoenix'
Local time is now:      Thu Jul 27 16:40:54 MST 2017.
Universal Time is now:  Thu Jul 27 23:40:54 UTC 2017.

Then you can write to the RTC:
root@wgd:~# hwclock -w -f /dev/rtc1

So what all this does is update the system time, configures the timezone, so that system time can be written to the real time clock. You could in fact just write to the real time clock without doing all the above. But the RTC will not be accurate.

Now we should be able to read from the RTC.
root@wgd:~# hwclock -r -f /dev/rtc1
Thu Jul 27 16:45:41 2017  -0.646341 seconds

[William Hermans]

William,

Also to save you from future grief. Make sure you load the proper drivers for your hardware,then if you're going to write your own software to read from the RTC. Use /dev/rtcx( probably /dev/rtc1 ), and do not try to read directly from the RTC over I2C. Trust me . . .

[Greg]

Try

lsmod

and see if the driver for your RTC is listed.

If not, try

dmesg

(I usually use dmesg | less, f is forward, b is backward, and q is quit)

and search for a message which may indicate a problem loading the driver.

Look for the character device

/dev/rtc1

Also, hwclock command behaves strangely sometimes, try sudo hwclock from a regular user account instead of from root.  There may be some funky permission issues.

Greg

[William Hermans]

My driver is actually loaded from a custom overlay write I wrote myself. So all of the initial steps listed on that adafruit link, I do not have to bother with. But that's a bit advanced, and going from experience, trying to explain how I did that "wont compute" until said person trying to understand what I'm saying has a firm grasp of how device tree overlays work.

[William B]

Finally I got ... the last hint from William Hermans indicated me something about the device name, which could be "rtcX", which made me execute: "ls -la /dev/rtc*":

root@beaglebone:~# ls -la /dev/rtc*

lrwxrwxrwx 1 root root      4 May 21  2016 /dev/rtc -> rtc0

crw------- 1 root root 254, 0 May 21  2016 /dev/rtc0

1) Replace "rtc1" with "rtc0" in the commands and everything works! (the system date and time were already correct):

hwclock -w -f /dev/rtc0

2) To test if it worked and if the date and time were actually adjusted, I changed the system time, restarted the BBB and disconnected it from the internet to ensure the date and time would not be auto-tuned. After restarting it, I checked if the system time was still wrong and then read the RTC time (which must be correct!).

hwclock -r -f /dev/rtc0

It works!!! RTC date and time were correct.

I don't even know how to thank everyone for their help. It should be simple to solve this problem, but it takes a lot of time, especially for those who don't have experience like me.

Thank you very much!

[William Hermans]

Well, rtc0 is most likely the on AM335x on die real time clock, which will not persist time across reboots.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9c2b0a36-e70d-4fec-a904-6a0f6b5e0a49%40googlegroups.com.

[William B]

Actually what is happening is this: when I remove the power from the BBB, the date and time return to the default setting. Because the RTC is automatically associated with system time auto-tuning, then its time is also being changed incorrectly (I had not noticed this in reboot because it is necessary to remove the power).

How do I prevent the system from automatically correcting the RTC? How do I remove this connection from the RTC with the system?

I intend to create a script to set date and time.

[Greg]

There is lots of stuff going on, and it is messy.  Check out this link:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785445

I tried the configuration via udev, but as reported in the above link, it doesn't work.

Apparently the only way to get the /dev/rtc link to point to rtc1 instead of rtc0 is to change the kernel configuration and compile it that way.

I found the configuration setting, but I was too lazy to change it and compile a new kernel.  My systemd service seems to be good enough.

And that brings up another point.  Another system getting into the RTC act is systemd.  Try this command:

timedatectl

Greg

[William B]

Greg,

I'd just like to prevent the RTC from being updated with the system date and time so that I can even use a script to do this task when I need to.

How do I prevent the RTC from being updated automatically?

Command response "timedatectl"

root@beaglebone:~# timedatectl

      Local time: Fri 2017-07-28 09:59:52 -03

  Universal time: Fri 2017-07-28 12:59:52 UTC

        RTC time: Sat 2016-05-21 22:38:04

       Time zone: America/Sao_Paulo (-03, -0300)

 Network time on: yes

NTP synchronized: no

 RTC in local TZ: no

[William B]

Greg, it's okay. I was able to make the RTC be recognized as rtc1 in the system. Just turned off the BBB, disconnected everything that was connected to the hardware and starts again. I'm sure the RTC module was properly connected to the BBB, so I believe that there could only be some configuration conflict going on.

Thank you!

[Greg]

Only /dev/rtc0 is going to be updated automatically.  /dev/rtc1 is not going to be updated automatically, as far as I can determine, with the Debian distributions as published.

You would have to use the config tools to switch from rtc0 to rtc1 and compile a new kernel.

So the common scheme you will find, for example, at the Adafruit site uses a script which is run by systemd to set the system time from /dev/rtc1.

This will happen soon after boot, but I am not precisely sure when.

An important point is that "system time" is what matters.  That is what you will see with the date command.

So the common scripts use the hwclock command with option --rtc /dev/rtc1 (this is same as -f option) to set the system time.

So you have to assume /dev/rtc1 has been set accurately.

The best way to set the /dev/rtc1 is to use the hwclock -w /dev/rtc1 command with the device connected to the internet and accurate NTP time being in force.

This command writes the system time to the RTC.  So if the system time is correct, the RTC time will be correct.  This is like setting any clock.  Thanks to the RTC having a battery, it will maintain time with Beagleboard power going off.

This can also be done manually at the command line if you don't have an internet connection (but you have another accurate time source).

So basically the common scripts floating around out there overwrite the system time which was set automatically with the time provided by the RTC /dev/rtc1.

Note that there is a compensation system for the RTC which is also included in the system.  I'm still working out the details on how to understand and manage what it is doing.  What I am doing for now is periodically rebooting my BBGW with it connected to the internet + NTP.  The compensation scheme is working, but the system time is running a little bit fast.

Greg

[Greg]

Look at the link in /dev/rtc:

ls -al | grep rtc

If you got it to point at /dev/rtc1, I would very much like to know how you accomplished that!

[William B]

I couldn't point to the rtc0 device, but after much suffering I was able to create the rtc1 device.

root@beaglebone:~# ls -al | grep rtc*

-rw-r--r--   1 root root     0 Jul 27  2017 rtc0

root@beaglebone:~# ls -la /dev/rtc*

lrwxrwxrwx 1 root root      4 May 21  2016 /dev/rtc -> rtc0

crw------- 1 root root 254, 0 May 21  2016 /dev/rtc0

crw------- 1 root root 254, 1 May 21  2016 /dev/rtc1