VOGONS


First post, by appiah4

User metadata
Rank l33t++
Rank
l33t++

Is there a way to check and make sure a Dallas RTC chip has juice left? I have a board that needs one, and a chip with a manufacture date of 2005 but I don't know if it has power left or not, and I would rather be able to check before I order a new one..

Reply 1 of 5, by Horun

User metadata
Rank l33t++
Rank
l33t++

Unfortunately there is no easy way to check most of the 1287, 12887, 1387, 1587 (or equal) type RTC because they cut the battery pins off or use them internal to the black box.
The only way to check is to grind a bit of the plastic to expose those two pins (like you were doing an ext. battery mod) and then use a voltmeter to check. iirc a few of the versions you only need to grind where the +bat is and check it against ground.

added: I can confirm that on a DS12887 series that you only need to grind-n-find the bat + at pin 20. The bat - is tied to the ground pin 12 (and pin 16 but that would be missing).

Hate posting a reply and then have to edit it because it made no sense 😁 First computer was an IBM 3270 workstation with CGA monitor. Stuff: https://archive.org/details/@horun

Reply 3 of 5, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

I was looking into the same and just for fun started building a simple program for Arduino for quickly testing the Dallas chips (reading RTC, loading, writing). I'll share it once done.

Blog|NexGen 586|S4

Reply 4 of 5, by foggy

User metadata
Rank Newbie
Rank
Newbie
mpe wrote on 2020-02-08, 14:10:

I was looking into the same and just for fun started building a simple program for Arduino for quickly testing the Dallas chips (reading RTC, loading, writing). I'll share it once done.

Hi, just came across your post looking for exactly what you're proposing. Did you ever get it done?

Reply 5 of 5, by Snial

User metadata
Rank Newbie
Rank
Newbie
foggy wrote on 2024-06-24, 17:17:
mpe wrote on 2020-02-08, 14:10:

I was looking into the same and just for fun started building a simple program for Arduino for quickly testing the Dallas chips (reading RTC, loading, writing). I'll share it once done.

Hi, just came across your post looking for exactly what you're proposing. Did you ever get it done?

I have a simple arduino circuit and sketch with the intention of testing my Dallas 1386 RTC. This one came from an SGI Indy, which I got (for free from freecycle) in 2009. After 16 years I've finally gotten around to scraping off all the epoxy around the battery and removing it.

So, my setup is:


          +--u--+
NC--/INTA-+1  32+-Vcc-5V (on arduino)
NC--/INTB-+2  31+-SQW-NC
NC--NC----+3  30+-Vcc-(pin 32)
GND---A12-+4  29+-/WE-Pn4
GND---A7--+5  28+-NC--NC.
GND---A6--+6  27+-A8--GND
GND---A5--+7  26+-A9--GND
GND---A4--+8  25+-A11-GND
GND---A3--+9  24+-/OE-Pn5
GND---A2--+10 23+-A10--GND
GND---A1--+11 22+-/CE-GND
GND---A0--+12 21+-DQ7-NC
Pn2---DQ0-+13 20+-DQ6-NC
Pn3---DQ1-+14 19+-DQ5-NC
GND---DQ2-+15 18+-DQ4-NC
GND---GND-+16 17+-DQ3-NC
          +-----+

(where Pnx means Digital pin x on an arduino). Pin 1 is the Dog's head end, i.e. the battery end, because pins 32 and 30 are connected.

And the sketch is:

int gCounter=0;

#define kA0 2
#define kD0 3
#define kWe 4
#define kOe 5
#define kCs 6

void RtcPoke(uint16_t aAddr, uint8_t aVal) {
digitalWrite(kA0, aAddr&1);
pinMode(kD0, OUTPUT);
digitalWrite(kD0, aVal&1);
digitalWrite(kWe, 0);
delayMicroseconds(2);
digitalWrite(kWe,1);
pinMode(kD0, INPUT);
}

uint8_t RtcPeek(uint16_t aAddr) {
uint8_t val=0;
digitalWrite(kA0, aAddr&1);
digitalWrite(kOe, 0);
delayMicroseconds(2);
val=digitalRead(kD0);
digitalWrite(kOe,1);
return val;
}

void RtcTest(bool aWriteTest) {
int addr, val;
for(addr=0; addr<2; addr++) {
val=RtcPeek(addr);
if(aWriteTest) {
Serial.print("w:");
RtcPoke(addr,val^=1); // invert.
}
Serial.print("Mem[");
Serial.print(addr);
Serial.print(']');
Serial.print(val);
Serial.print(", ");
}
}

void RtcInit() {
digitalWrite(kCs, HIGH);
pinMode(kCs, OUTPUT);
digitalWrite(kA0, HIGH);
pinMode(kA0, OUTPUT);
pinMode(kD0, INPUT);
digitalWrite(kD0, LOW);
digitalWrite(kWe, HIGH);
pinMode(kWe, OUTPUT); // no write enable.
digitalWrite(kOe, HIGH);
pinMode(kOe, OUTPUT); // no write enable.
digitalWrite(kCs, LOW);
}

void setup() {
// put your setup code here, to run once:
Show last 25 lines
  pinMode(LED_BUILTIN, OUTPUT);
RtcInit();
Serial.begin(9600);
}

void loop() {
// put your main code here, to run repeatedly:
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(250); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(250); // wait for a second
Serial.print('\r');
Serial.print(++gCounter);
if (Serial.available() > 0) {
int inByte = Serial.read(); // get incoming byte
Serial.print("You typed:'");
Serial.print((char)inByte);
Serial.print('\'');
if(inByte=='w' || inByte=='r') {
RtcTest(inByte=='w');
Serial.println();
}
}
}

You run the code, and observe monitor. Type 'r'<return> to read bit 0 of bytes 0 and 1; 'w'<return> to write back the inverse of bit 0 of bytes 0 and 1 to bytes 0 and 1.

So, really, I figured I could test whether data can be read or written with this and whether it's retained when I add a replacement battery. As yet, I haven't gotten it to work though. With the RTC powered and the sketch running and typing 'r'<return> I see

Data[0]=0, Data[1]=0; when I try 'w'<return> I see
Data[0]=1, Data[1]=0 (didn't expect that) and finally when I try 'r' again I see:
Data[0]=0, Data[1]=0 , but I'm probably missing something from the datasheet:

https://www.analog.com/media/en/technical-doc … 386-ds1386p.pdf

This is someone's opportunity to see what I have wrong. I can think of a few possible errors:

  • It's reading from proper registers, but only writing to shadow registers (there's a bit in the datasheet that implies that)
  • I don't have a big enough delay between one access and the next (so Data[1] isn't meaningful, but the Serial.print won't be fast, so probably not)
  • I leave /CE down all the time, but maybe it should start high and I should only lower it when needed.

I'll probably do a bit more work on it, but some insight would be helpful.