Mostek/ST 'Timekeeper' IC (Sun NVRAM) repair

[Kat Manton]

Part I

Old Suns (and a few other old machines) use a SGS-Thomson (formerly Mostek) 'Timekeeper' integrated SRAM, real-time clock, crystal and battery. (Types include M48T02, M48T08, M48T18; earlier ones were prefixed 'MK'.)

The system's MAC address, host ID and configuration information are stored in this NVRAM; the lithium cell lasts around 10 years and, when it dies, causes all manner of problems including a MAC address of FF:FF:FF:FF:FF:FF and a system which won't boot. It also appears that the design has been changed and some Suns refuse to work with the new ones.

There's more information in the Sun NVRAM/hostid FAQ, including how to reprogram new/repaired ones on several machines.

Google brings up a few pages detailing repair of the things but some attempts look a little crude and at least one appears to discard the crystal, leaving the clock inoperative.

So I thought I'd detail one of my recent attempts. I've done several over the last decade and have refined my methods.

Here's the offending article; this is one of the two from my SPARCserver 1000E.



According to ST Quality Note QNSR9701, the Date Code H994K9440 and Encapsulation Code HT3034A date it to 1994; no wonder it's dead!

For this recipe, one will require:

• Small vice
• Junior hacksaw
• Needle files
• Craft knife (X-Acto etc.)
• Self-adhesive copper foil tape
• Surface-mount CR1632 coin-cell holder (Renata SMTU-1632-1)
• Lithium coin cell CR1632
• 32.768 kHz watch crystal
• Solder, soldering iron, patience, coffee, etc.

Buried in ST Application Note AN934 TIMEKEEPER calibration I found:

At STMicroelectronics, the real-time clock has an internal capacitance of 12.5pF (except for the M41T6x device, which has an internal capacitance of 6pF) across the crystal input pins.

So I got watch crystals specified for a load capacitance of 12.5 pF. I'm currently reserving judgement on whether or not these are suitable, I'll have to observe how well it keeps time with the power off. It's not really a major issue as, although the system time is set from the real-time clock when the OS boots, correcting it is simply a matter of executing 'ntpdate' during system initialisation with a local or Internet NTP time-server specified.

Now, on with the destruction. The first stage is to remove the potted housing containing the cell and crystal, leaving pins protruding to which the new parts can be attached.

The crystal is located at the end adjacent to pin 1, the lithium cell is at the opposite end.

I started at the cell end; the cell is quite close to the end of the package making this end slightly trickier to separate.

First, I cut in from the end, working carefully until I felt the metal pins. (If it's ancient, failing to keep time and retain configuration information, there's unlikely to be any danger in short-circuiting the cell. If in doubt, cut at an angle so the saw only contacts one pin at a time.)



Now I knew where the pins were, I could cut in from the top until I felt the cell, make two angled cuts, then break off the encapsulation by levering it with a small screwdriver (it's fairly soft but also brittle.)



Next I made an angled cut to separate this end.



Then I turned the device around and repeated the process at the other end.



Continued in Part II...

[Kat Manton]

Part II

This is what was left of the poor thing after Part I.



Next, I carefully removed the encapsulation from around the pins at either end, keyed the top of the device with fine abrasive paper and cleaned it with IPA.



Pin 1 can still be easily identified on the device itself.

M48T02 (24-pin DIP)

• The pins adjacent to pins 1 and 24 are for the crystal.
• The pin adjacent to pin 12 (VSS) is cell -ve
• The pin adjacent to pin 13 is cell +ve

M48T08/18 (28-pin DIP)

• The pins adjacent to pins 1 and 28 are for the crystal.
• The pin adjacent to pin 14 (VSS) is cell -ve
• The pin adjacent to pin 15 is cell +ve

In both cases, the cell -ve pin is adjacent to and connected to the VSS pin; the cell +ve pin is on the same side as the VCC pin.

Next, I stuck copper foil strips on top of the device (after making the small holes) and applied Evo-Stik contact adhesive. I made the -ve connection the longer of the two.



I then keyed and cleaned the underside of the coin cell holder, applied Evo-Stik then carefully stuck the holder in position, making sure the polarity was correct.



Finally, I soldered all the connections and soldered on a watch crystal.



As a finishing touch, hot-melt glue could be applied over the soldered connections and used to secure the crystal.

All that remains to be done is to shove it back inside the computer, fit the cell and load the MAC address, host ID etc. back in.

Kat

[paulsherwin]

Good stuff Kat, well done.

I have to say it seems a pretty cretinous design decision to use a non-replaceable battery in any piece of equipment, let alone in an (at the time) expensive server. Why didn't Mostek just use a coin cell holder on the part, and given that they didn't why didn't Sun use something else?

[ppppenguin]

Originally Posted by paulsherwin

I have to say it seems a pretty cretinous design decision to use a non-replaceable battery in any piece of equipment, let alone in an (at the time) expensive server. Why didn't Mostek just use a coin cell holder on the part, and given that they didn't why didn't Sun use something else?

Hindsight is a very powerful tool. Unfortunately difficult to apply at the design stage. I've used this sort of device in a design for a client on the basis it was convenient and economical. Since the battery life was longer than the anticipated service life for the product I couldn't see a downside. Even with high end kit, you aren't usually designing for the convenience of the 2nd user.

Kat, that's a nice bit of surgery. Fairly simple compared to some the problems we will face in the future as ever more complex chips are found to have wear-out problems.

[neon indicator]

Originally Posted by paulsherwin

Good stuff Kat, well done.

I have to say it seems a pretty cretinous design decision to use a non-replaceable battery in any piece of equipment, let alone in an (at the time) expensive server. Why didn't Mostek just use a coin cell holder on the part, and given that they didn't why didn't Sun use something else?

Umm..

Some PCs used a similar part (the CMOS + RTC) and originally used NiCd battery on motherboard. Which would leak and corrode board.

Some used 2 x AA (Amstrad)

Some used large Lithium cells (4 main kinds)

Some used something very like (Identical?) that in the Sun.
I have 3 modules from PCs like the Sun module here
ODIN OEC12C887 x2
Dallas DS1287 (underneath is full 28pin chip)
Dallas DS1220Y (Same size but under you can see maybe 8pin DIL) (may not have a clock!)


Later they switched to coin cell in holder as per current PCs.

I have 2 x bare MC146818, one Hitachi and one Motorola

I have 2 x Mostek chips but they may be 2Kx8 SRAM
(all from PC)

All RTCC with extra "unused" registers used for original "CMOS" settings. Often the "CMOS" settings now is extended to a Flash memory chip too. A few boards didn't use "cmos" and only Flash and a power cut during setting change could "brick" the MoBo as unplugging the coin cell would only reset the clock


I think the idea of "all in one" crystal, battery, chip solution was to make it easier for mobo designers. I designed a Z80 controller in 1979 with a RTC and battery backup. Unfortunately it got the register values "clobbered" on power off or power up. I didn't need the clock really so left those parts out rather than fix it.

The original IBM PC in 1980/1981 unlike ACT Sirius1 contemporary had no HW RTC at all or "CMOS" BIOS settings. The advent of a variety of different hard drives led to the HW RTC becoming standard to have somewhere to store the drive geometry.

[paulsherwin]

Before the CR2032 coin cell battery used on ATX era motherboards, PCs mostly used a 3.6V NiCd soldered onto the mobo. This was easy to change, or could be replaced with a holder on some flying leads containing some NiCds or even a couple of AA alkalines. As Kat's surgery shows, changing the battery in the Sun setup is not a trivial job and it's a system killer if not done.

[Kat Manton]

Hi,

The PC devices aren't all that similar; there's much less SRAM for a start (about 50 bytes IIRC) and as Paul notes, an embedded battery/cell is unusual (I've never seen one in any PC and I've been inside a lot!)

The Suns have 2048 bytes (M48T02) or 8192 bytes (M48T08); the identity of the system (serial number, host ID and MAC address) is stored in it by Sun when the machine is manufactured. There's a lot of configuration information stored, much of it as strings of text. It's also possible to store commands and small Forth programs in it, to be executed before booting the OS (the boot PROM contains a Forth interpreter, debugger and disassembler; the manual for it runs to 182 pages!)

Among other things, any licensed software installed would be keyed to the host ID; if the NVRAM dies, the host ID disappears; even if you manage to manually boot the OS, licensed software won't run.

I suspect that a machine coming up on a network with MAC address of FF:FF:FF:FF:FF:FF (the broadcast address) might cause a few problems, too...

Sun could provide a pre-programmed NVRAM containing the system's identity if given the code which appears on a label on top of them in most machines. I don't think it's cheap and may not be possible with any 'end-of-lifed' system and/or without a current service contract.

If you replace or repair the device yourself, you need to have this information written down somewhere; it's possible to load it from the OpenBoot prompt. Otherwise the only recourse is to make it up (which I'll have to do with a few machines.)

So if you happen to have some old Sun kit which hasn't yet suffered amnesia, write down all the information before it disappears! (I'm doing that with the few machines which still retain it; I'll put it on a label underneath or inside.)

Fortunately in the 1000E, the system's identity is stored in EEPROM on the control board and is copied into the NVRAM on each system board. I've noted it all anyway, just in case.

Failure of the CMOS battery in a PC is somewhat trivial in comparison; it might get mildly tricky with very old machines which have the CMOS configuration utility on floppy. Not something I'd bother writing about...

Kat

[twocvbloke]

I recall seeing a similar process on Instructables where someone's old PC's CMOS had died and it had one of these chips with a built-in battery, and they did basically the same kind of thing, definitely a job for those with the patience, I'd probably break something...

Infact, here's the very project I recalled:
http://www.instructables.com/id/Revi...IBM-PS2-55SX-/

You definitely have a knack of getting old computers working...

[neon indicator]

Yes, only 64 bytes is the "original" PC AT spec. I meant "similar" in sense of potted with internal battery. Obviously not the same as they are all MC146818 compatible if from a PC (I think one or both Dallas modules may be from something else). But one place I worked "assembled" a lot of PCs using Mobo with the "Odin" part.

I forget if those modules came from 286, 386, or 486. Definitely an Asian clone maker though.

The tricky easier to "brick" PCs where the ones that only lost time and not BIOS settings if battery failed. We did actually have one some years ago, AMD cpu and Nvidia chip set that got "bricked".

Regular PC mobos it only Power fail during Flash Firmware update that bricks them. I fixed a "bricked" one by putting a good BIOS chip from same model, boot Floppy, carefully lever out chip and plug in "bricked" one while power on and then run the Floppy based Flash Firmware upgrade. If I had thought this likely to be a regular occurrence, I'd have made a daughter board with two sockets and a switch.

I might even still do that as you can put ANY file on the Flash memory and I have loads of them from scrapped Mobos. Apparently if you program Z80 and want to do your own code for original mono Gameboy the PC bios chips can wire direct to cartridge socket with no additional circuitry.

So what you going to use the Sparc for Kat?

[Kat Manton]

Hi,

Ages ago I had a PC with a duff battery and it was one which had the configuration utility on floppy. Rather than replace the battery (I think it was a soldered-on NiCd), I wrote a little program in BASIC and stuck that on a bootable (5.25") floppy with DOS. This set the hard drive type (type 2, Seagate ST225; it's funny the things one remembers), asked for the date and time, then invited one to eject the floppy, then rebooted. I used it like that for months and never did replace the battery!

I'm not sure that'd be possible on a Sun. For a start, it won't boot from anything and just drops to the OpenBoot prompt if the NVRAM checksum is invalid.

These things are a lot more fun than old PCs; but "complicated" and "fun" seem to go hand-in-hand with me...

Kat

[paulsherwin]

Ah yes, the late unlamented PS2 used one of those things among lots of other weirdness. I had a PS1 for a while, but that was much more conventional in all respects and used a standard CR2032.

[Kat Manton]

Originally Posted by neon indicator

Regular PC mobos it only Power fail during Flash Firmware update that bricks them.

Ah... that's actually a rather different problem to this. The OpenBoot firmware in the Suns is stored in EPROM (four 32-pin ones in the 1000E) so it's pretty much impossible to 'brick' them in the same sense as it is with a PC with BIOS in flash.

I think one of the things the NVRAM could be used for, though, is holding patches for the firmware.

NVRAM battery failure doesn't really 'brick' a Sun. You get dropped to the OpenBoot prompt and could then write a valid MAC address etc. into NVRAM, configure a few things then manually boot the OS; tedious to do but it'd be fine until you shut it down and kill the power.

Originally Posted by neon indicator

So what you going to use the Sparc for Kat?

Erm... I'm not sure... I think I'm using them primarily to play around with old Sun hardware...

Kat

[twocvbloke]

I quite like old computers me, even more so when they're working, and as for these Sun computers, I never even knew they existed until around 2002 when I got my first job (back then all I knew that existed were PCs & Macs, hadn't even heard of linux then either!!!), and seeing these ones here running modern internet browser applications, where a Windows or mac computer couldn't, it's very impressive...

And I like the idea of the BIOS settings being loaded from a 5 1/4" floppy (I want an old system with them, an old 486 with multiple FDD's, just like the "Phantom of the Floppera" vid on youtube!!), today that just wouldn't work, computers are so boring in that respect, hence why I love old hardware, there's more room to play...

What were Sun systems used for anyway? like I say I only learned of their existence in 2002, but, I never found out what they're for, I know networking them is common, but, other than that, I don't know anything about them...

[neon indicator]

I have boxes of 486 stuff twocvbloke. I was going to have a scrappage to recycling centre. 8", 5.25" and 3.25" floppies + drives available.

Real Engineers used Sun Sparc workstations also many backend servers used Sun. Most telcom backoffice (servers to make Mobile work, inc call handover between cells) is still exclusively Sun Server HW, Solaris and may have Oracle too.

Back when only a few Arts students used Mac, Engineers had DEC Alpha Workstations too, running NT 3.51, and later the 1st 64 bit version of windows on NT4.0 as well as various UNIX. DEC Alpha Servers and Workstations also had VMS, originally on VAX.

The telecom place I worked in 1980s used DOS based Apricot Workstations with terminal sessions to DEC PDP11 and also our own R&D server, a Cromemco dual Z80/68000 system running CROMIX, a Cromemco version of UNIX.

There were also MIPS and PowerPC workstations. In 1996 Windows NT ran on Alpha, Power PC, MIPS, 486, Pentium, Pentium Pro (which didn't run 16bit x86 code well, so was FAR slower on win95 than NT).

There were various 680x0 based computers/servers/Workstations. In late 1980s there was ARM based Archimedes which could take an x86 card and have ARM RiscOS and DOS/Windows on one desktop. It also had a UNIX.
In 1980s there was AT&T 3B2 box to run UNIX
Commodore had a professional Workstation version of Amiga (680x0 something) with x86 card option.

There were LOADS of "PCs" before IBM brought one to market in 1980. Some even ran x86.

The "BSD" was first "free" UNIX, years before Linux.

In 1981 we had Apple II with HDD and 1 Mbyte dual 8" drives, UCSD p-system, Z80 card and CP/M
A custom built S-100 system with CP/M
Research Machines with CP/M
ACT Sirius-1 with 800x400 graphics, GPIB, Parallel, serial, Clock, Audio, 1Mbyte floppies and CP/86 AND MSDOS. An IBM PC of same date was text only, 180k floppy standard and only a cassette port as standard. Serial, parallel & clock extra. No audio or GPIB options.
We bought a Sinclar Spectrum when they 1st launched to use as a cheap test card for Monitors we built for BBC Micro and Apple II computers.

PC and Mac are Fiesta and Polo of the Computing World Lots of other cars before and since.

[julie_m]

Nice job you've done there Kat

Withou wishing to go to far off-topic, have you ever tried removing the top from an OTP device to convert it to a conventional UV EPROM?

[Kat Manton]

Originally Posted by ajs_derby

[...] have you ever tried removing the top from an OTP device to convert it to a conventional UV EPROM?

Now that's taking things a bit far! (I've never been that desperate for UV-erasable EPROMs; places of employment tended to erm... provide a source...)

To illustrate the NVRAM problem, I've just grabbed a SPARCstation 2 (the label on the bottom dates it to 19th March 1991) off the pile, shoved some RAM in it, connected the serial terminal then hit it with mains for the first time at least a decade...



("Serial #16777215" is, of course, FFFFFF in decimal.)

It...

• fails to identify the keyboard because there isn't one (there isn't a framebuffer card or much else in it either)
• detects the NVRAM failure
• resets the configuration to defaults (which includes turning on 'diag mode', so it tests everything, including the RAM, which takes ages)
• defaults to attempting to boot off the network (/sbus/le@0,c00000 is the network interface)
• fails as it isn't plugged into my LAN (wise, given the ethernet address!)
• drops to a prompt.

That'll be an M48T02 heading for the operating theatre...

Kat

[wave solder]

I have been lucky on both of my Sun voyager and my Sun IPX machines in that the deceased coin cell in old age had expanded and cracked the top of the plastic module so all I had to do was remove the broken bits of plastic and with a tiny screwdriver prise out the old coincell, solder two pieces of tinned copper wire to the two stubs of metal left behind. To these two pieces of metal I then soldered on the coin cell holder (observing polarity) then glued it in place on top of the module.

[twocvbloke]

Gotta love the greenscreen, I haven't used one of those in many years, my dad used to have some computer in his loft that had a green screen, no idea how the thing was meant to work, but it was pretty cool and had 5 1/4" drives, somehow he managed to write a CV and a job application on it (and printed off on Dot Matrix or Daisy wheel printer (can't recall that part in detail)), it definitely wasn't the usual flavours of DOS though, I've no idea what make the computer was...

I shall PM about the 5 1/4" drives...