Dallas DS1742W-120, things I've learned

vvuk

Member
Aug 25, 2021
36
26
18
I've got a few machines that need a new DS1742W-120 (Fuel, O350). I'm kicking off a thread because we somehow don't yet have a Dallas thread :D

I ordered some replacement DS1742W-120's from ebay -- the seller had -120's listed, a -120 was pictured, but -120+ was what I got. This, in theory, should be fine; the "+" just signifies RoHS and should have no functional difference. Unfortunately, from the time of SGI's DS1742W's to.. whenever these were manufactured, it looks like the physical specs of the chip changed.

The original -120 chip that was in my Fuel has pins that are .20mm x .40mm (one of the biggest I checked, they vary by ~.02mm). The new -120+ pins are .30mm x .58mm, so almost 50% larger in each dimension. The DS1742 data sheet lists pin size to be 0.25-0.45mm x 0.43-0.58mm, so the new chip is right in the middle of that spec. The old one is way under.

SGI used a socket with really small round pin holes; the new chip pin size physically does not fit. A standard 2.54mm-spaced header (typically .63mm square pin) does not fit into them. However, a 1.27mm header with every other pin removed fits nicely (these are typically .40mm square pin). (The new chips are also physically bigger; there's a capacitor on the fuel that the new one barely clears.)

I've got a variety of adapters, but I'm not hopeful as I think they'll all have way too thick pins. I suspect I'll have to build my own; the smaller pin size but with a 2.54mm pitch does not seem to be a thing in any existing adapters.
 
  • Like
Reactions: LarBob and Elf

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
That's Odd...are you sure you have a genuine chip and not a fake part? I ask because all the datasheet versions I can find (pre + and after) have the same tolerance dimension on the last sheet. While it's barely in tolerance, if the actual BODY isn't the same size, I'd say you may have purchased a fake. Several people have had this happen...nearly 100% of all the Dallas RTCs on eBay are fake (even US ones). I bought a lot of 5 myself two years ago and am waiting to try them to see if they are fakes or not, they look real and were from a a US seller with 100% feedback on electronic NOS. But you really cannot tell without serious probing or X-rays.

Old datasheet (no mention of +): https://pdf1.alldatasheet.com/datasheet-pdf/view/58531/DALLAS/DS1742W-120.html

Another way to tell if you got a fake is the cell battery placement (using a magnet, if that works), location shouldn't change. On the originals the battery is located on the bottom, not the top...another factor to check.

I'd advise carefully drilling out your old RTC (which you know works) and hook up a coin cell holder.
 

Attachments

vvuk

Member
Aug 25, 2021
36
26
18
Hmm, from datasheets:

1635951334521.png


J is pin thickness, K is pin width (seen from the side). 0.20mm and 0.40mm are below the minimum in both dimensions.

I don't know if it's a fake; I'll check the battery. It is certainly physically bigger; these are also from a US seller -- specifically 5PCS/New In Box DALLAS DS1742W-120 Nonvolatile Timekeeping RAM 880471764706 | eBay . The auction also listed -120, and a -120 was pictured, so it should be an easy refund via ebay.
 

vvuk

Member
Aug 25, 2021
36
26
18
I also just measured the physical package size of the "120+": 33.6mm x 17.6mm which is well under the minimum (37.3 x 17.15mm) on the spec sheet; but the original one is even smaller, at 32.2mm x 17.3mm. So I don't know what to believe!
 

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
Holy sh*t, that’s the same seller I got a batch from in July 2020!! I didn’t own a Fuel yet, they were preventative stock.

Just tried to insert one in my Fuel, pins line up perfectly but you’re right will not slip in (didn’t want to use extreme force).

looks like I got taken too.
They were originally for my Tezros but I’ll assume SGI didn’t magically use two different slots.

Yeah, I guess I’m stuck with these and yeah, I assume they are fakes now until proven otherwise.

I see what you’re saying on the Fuel (and perhaps others) that socket is very tight against things, if it were more on its own (and through-hole?) I’d install a universal ZIF testing socket to hold the RTC.

We’ll, I’ve not seen that seller for awhile, so I assumed I was safe. I’d say if you have the opportunity, return them as “not as advertised”. It’s too late for me :-(.
 

vvuk

Member
Aug 25, 2021
36
26
18
@HAL actually ordered from the same seller. I've got a programmer; I just tossed one of the chips in. Results are still inconclusive: I had to blank the chip first before anything would work, which is expected I believe; however after that, while I do see what looks like clock values in the last 8 bytes, the rest of the chip reads as 0x55. However, I don't trust the programmer software. After work I'll use a different piece of software so that I can get a better understanding of what's going on, because it would be odd for there to be a working clock, but non-working nvram (that's.. the easy part?).
 

vvuk

Member
Aug 25, 2021
36
26
18
So a quick test over lunch, and I think these work fine? I may have screwed up the clock portion in this one by writing all 0xaa's. That sets the clock write bit, turns on the oscillator, then writes a bunch of 1's into places that are marked as "these should have 0 written during write". I just crafted what I think is a proper "clock set", and while that did take.. oh I just realized I never triggered the "read" bit. I'll try that. One concern is that it started reporting a '0' in the battery flag bit, where originally it was reporting a 1. I don't know if that was due to my junk write shenanigans, if the battery actually _did_ just fail, or what.

But data that I stored to nvram seems to be verified fine, and was still there upon reading a few minutes later after removing power. I'll check again in an hour, and I'll keep building my little adapter tonight and will try it in the Fuel.

For the TL866II programmer -- the windows software seems to be garbage. The open-source "minipro" actually seems to work.
 

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
Well, if you end up adapting or resocketting let us know if it works. I at least have a vested interest, as I bought the same units.
 

vvuk

Member
Aug 25, 2021
36
26
18
So -- new chip seems to be fine after an hour. Data retained. Interestingly... old chip that I pulled out, also seems to be fine?! Reading it, it has valid contents, and I can see the clock ticking. Battery flag is 0, though. The contents are interesting. Everything from 0x1228 onwards is just the L1 log. The first 0x1228 bytes have some timezones, some serial numbers, and then some binary data and a bunch of 0s. There is no nvram data in here whatsoever. I've always wondered what's on the snaphat nvram and what's on the dallas chip on IP35 -- I guess now I know?

(It also means that somehow my snaphat is dead which.. it shouldn't be)
 

vvuk

Member
Aug 25, 2021
36
26
18
More (related, now) notes -- the snaphat battery as shipped stock is M4T28-BR12SH1. The M4T32-BR12SH1 is the same part, but with 120mAh capacity instead of 48mAh. Price difference is negligible, so I'd get the 120mAh replacement. mouser currently has them in stock for $11.

Note that this means that if you see a "NVRAM checksum incorrect" message during boot on an IP35 system -- it is the snaphat that failed, not the Dallas chip.
 
Last edited:

vvuk

Member
Aug 25, 2021
36
26
18
In my case, the contents of nvram are always reset after a full power off, I think the clock as well. Given that the Dallas chip also has a real time clock, I'm starting to think that the Dallas chip is _only_ used by the L1 controller (I need to go check if the log entries have valid timestamps), and the snaphat TIMEKEEPER clock is used as the system clock. This all goes against assumptions I've read elsewhere though -- previous assumptions are that the snaphat (technically, the Timekeeper RAM, given that the snaphat is just the battery) served as "backup" for serial numbers, and that if the Dallas chip died, the serial numbers would be read from the Timekeeper and things would go on. I'm sure they would get updated in both directions, but I think where the serials are concerned, it's more accurate to think of the Dallas chip as the "backup" (or maybe master?), and the Timekeeper as the nvram + clock for the system.

I don't have a good way of dumping the Timekeeper contents, short of sticking a logic analyzer on it and recording access, though.
 

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
Sorry, no, it’s been proven that the Dallas DS1742w is for the L1 and L1 time only, snaphat RTC is what you see in Irix. This has been confirm on other forums. If you lost time on Irix and your boot parameters you needed a snaphat. Only L1 issues deal with the RTC your trying to change.
 

vvuk

Member
Aug 25, 2021
36
26
18
Sorry, no, it’s been proven that the Dallas DS1742w is for the L1 and L1 time only, snaphat RTC is what you see in Irix. This has been confirm on other forums. If you lost time on Irix and your boot parameters you needed a snaphat. Only L1 issues deal with the RTC your trying to change.
Yep agreed -- sorry, I was more referring to the nvram portion. I may have misunderstood, but I think I've read about people pointing at the Dallas chip if nvram isn't retained (on IP35). But it is indeed:

Dallas - L1 data & L1 RTC
Timekeeper - nvram & system RTC
 

vvuk

Member
Aug 25, 2021
36
26
18
Great news! These adapters -- https://www.amazon.com/gp/product/B07H3SK179 -- fit fine in the Fuel's socket and the 120+ chips' pins fit into them! It took a bit -- there's very little clearance, had to manually position pins in the middle of the adapter but it did go in. I flashed the new 120+ with the contents of the previous 120.

Fuel L1 comes up fine; it sees the old log entries from the flash & serial numbers, new log entries get added. Setting the clock via the date command sets it fine, and makes it start ticking (this was the 120+ chip I thought I had wedged by writing junk). I removed power from the power supply for 5 minutes; clock kept ticking fine, log entries remained etc.

So I think these are good chips! Just the pins are a giant pain in the butt. Also there's plenty of clearance between the blue shroud and this; I thought it was tighter. That capacitor to the side is questionable; I had to be very careful to not bump it too much. I think also there is about 3-5mm of exposed pin of the adapter in the Fuel's socket, I didn't want to press too hard.

IMG_2099 Large.jpeg
 
  • Like
Reactions: Elf

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
Wow, seriously? Just wow, wow, expensive buggers but no one ever said SGIs were cheap!! Great tip, I have the same RTC chips so I guess I’ll have to get them as well.
 

weblacky

Active member
Jan 13, 2020
130
34
28
Seattle, WA
Yeah, you're right, I'm going to do a DigiKey order soon, I'll get some from them. These aren't so much "adapters" as they are the same pitch to same pitch with slop-enough to handle the IC. So I'll pick up a similar socket. Good catch on the fact that you just needed smaller pin instead of a change in pin spacing. These cup-style socket have the low tolerance to take larger pins. Nice idea...though I'd have been convinced these RTCs were fakes...why would the producer allow this much variance in the same model/series.
 
Last edited:

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu