Problem reading DS1683 Elapsed Timer ETC Register


#1

Please help,

I’m having trouble reading the ETC (accumulated time) register on the DS1683 “Total-Elapsed-Time and Event Recorder with Alarm” device connected to an i2c bus. I’m running Linux on an embedded platform.

My problem is: the high-order two bytes (0xC and 0xD) are always coming back as zero. The low-order two bytes (0xA and 0xB) are returning values and incrementing.

Is there a requirement regarding the way this register is read (e.g. must be read as a single 32-bit value)? Can it be read with 4 individual byte reads (or two 16 bit reads? Apparently, I can’t successfully write to the 32-bit Password Entry register either.

I’m using the Linux i2cget utility to read from the device register set.

Am I missing something?

Thanks – Ben


#2

Hi Ben,

Is this the DS1682 or DS1683? I don’t have that I/C at my desk at the moment.

Looking at this python library:

It looks as though ETC needs to be read in 8 bit increments.

Regards,


#3

It is DS1683. Thanks – Ben


#4

From page: 13 of:

The ETC register is a shadowed EEPROM register that contains the accumulated
time in 250ms increments that the EVENT pin has been held high. On power-up,
on every rising edge of the EVENT pin, and after an I2C write to the ETC register,
the value from the shadowed EEPROM location is loaded into the ETC counter
memory  (SRAM). When the EVENT pin is high, it is this SRAM memory that
is incremented once every 250ms. On the falling edge of the EVENT pin, this
value in SRAM memory is then written to the shadowed EEPROM memory
to store the accumulated time in 250ms increments.

It’ll take a long time for 0x0C/0x0C to show anything (somewhere around 250ms * 2^16)…

with i2cget you can only do register access:

root@beaglebone:~# i2cget -f -y 1 0x6b 0x0A b
0x5c
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0B b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0C b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0D b
0x00

But you can use i2cdump:

root@beaglebone:~# i2cdump -y -r 0x0A-0x0D 1 0x6b c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               5c 00 00 00                    \...  

Regards,


#5

Thanks for the information. I really appreciate your help and responsiveness. However, I’m still stuck on this issue. I calculate that the tick count in the low order two bytes should roll-over around every 4.5 hours:

2^16 = 65536
65536 * 250 = 16384000 ms
16384000/1000 = 16384 seconds
16384/3600 = around 4.5 hours

I can see this happen by periodically reading the chip. Unfortunately, when the rollover occurs, nothing is incremented in the two high-order bytes (they always remain zero):

i2cget -f -y 1 0x6b 0x0A b

0x25

i2cget -f -y 1 0x6b 0x0B b

0x6c

i2cget -f -y 1 0x6b 0x0C b

0x00

i2cget -f -y 1 0x6b 0x0D b

0x00

Also, I used an i2c diagnostic adaptor (Aardvark I2C Host Adapter) and produced identical results. This adapter connects directly to the i2c bus and acts as the bus master, bypassing Linux and the Linux i2c driver.

I don’t know what’s going on. Could my configuration registers be set wrong?
Here is a dump of my registers:

i2cget -y 1 0x6b 0 b COMMAND

0x00

i2cget -y 1 0x6b 1 b STATUS

0x04

i2cget -y 1 0x6b 2 b PWE

0x00

i2cget -y 1 0x6b 3 b PWE

0x00

i2cget -y 1 0x6b 4 b PWE

0x00

i2cget -y 1 0x6b 5 b PWE

0x00

i2cget -y 1 0x6b 6 b RSVD

0x00

i2cget -y 1 0x6b 7 b RSVD

0x00

i2cget -y 1 0x6b 8 b EVENT REG

0x00

i2cget -y 1 0x6b 9 b EVENT REG

0x00

i2cget -y 1 0x6b a b ETC REG BYTE 0 (note non-zero)

0x1f

i2cget -y 1 0x6b b b ETC REG BYTE 1 (note non-zero)

0x03

i2cget -y 1 0x6b c b ETC REG BYTE 2 (always reads as zero)

0x00

i2cget -y 1 0x6b d b ETC REG BYTE 3 (always reads as zero)

0x00

i2cget -y 1 0x6b e b RSVD

0x00

i2cget -y 1 0x6b f b RSVD

0x00

i2cget -y 1 0x6b 0x10 b EVENT COUNTER ALARM LIMIT BYTE 0

0x00

i2cget -y 1 0x6b 0x11 b EVENT COUNTER ALARM LIMIT BYTE 1

0x00

i2cget -y 1 0x6b 0x12 b ETC ALARM LIMIT BYTE 0

0x00

i2cget -y 1 0x6b 0x13 b ETC ALARM LIMIT BYTE 1

0x00

i2cget -y 1 0x6b 0x14 b ETC ALARM LIMIT BYTE 2

0x00

i2cget -y 1 0x6b 0x15 b ETC ALARM LIMIT BYTE 3

0x00

i2cget -y 1 0x6b 0x16 b CONFIG

0x00

i2cget -y 1 0x6b 0x17 b PWV BYTE 0

0x00

i2cget -y 1 0x6b 0x18 b PWV BYTE 1

0x00

i2cget -y 1 0x6b 0x19 b PWV BYTE 2

0x00

i2cget -y 1 0x6b 0x1a b PWV BYTE 3

0x00

Thanks – Ben


#6

I noticed from your previous post that you appear to have the same issue that I’m seeing (i.e., your high order two bytes are zero:

root@beaglebone:~# i2cget -f -y 1 0x6b 0x0A b
0x5c
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0B b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0C b
0x00
root@beaglebone:~# i2cget -f -y 1 0x6b 0x0D b
0x00
But you can use i2cdump:

root@beaglebone:~# i2cdump -y -r 0x0A-0x0D 1 0x6b c
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 5c 00 00 00 …

The low-order two bytes should be rolling over every 4.5 hours (see my previous post). Am I missing something?

Thanks – Ben


#7

Hey Robert, I still have the issue described in my previous posts. Further it looks like you re-produced it; in your post showing an i2cget of the time registers (0xA-0xD) the high order bytes (0xC and 0XC) were zero. Please help me resolve this issue.

Thanks – Ben


#8

Hi Ben,
I left it running for awhile while logging, it wrapped just fine:

Sun Oct 22 14:14:54 UTC 2017
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               e6 ff 00 00                    ?...
Sun Oct 22 14:14:59 UTC 2017
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               fa ff 00 00                    ?...
Sun Oct 22 14:15:04 UTC 2017
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               0e 00 01 00                    ?.?.
Sun Oct 22 14:15:09 UTC 2017
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               22 00 01 00                    ".?.
Sun Oct 22 14:15:14 UTC 2017
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:                               37 00 01 00                    7.?.

No changes to the DS1683’s default configuration.

#!/bin/bash

while true;
do date ; i2cdump -y -r 0x0A-0x0D 1 0x6b c ;
sleep 5;
done

Regards,