Atlas 550 (beige units) failing to boot. Relay clicks, boot looping.

[newfuturevintage]

Hi-

I'm trying to get a handful of Atlas 550s up and running for a project. I am running into the "old dead battery in the Dallas chip" issue, so have been hacking into the chips to attach an external 3v battery which has been working OK, for the most part.

Except that I have a pair of units that after attaching the external battery are failing to boot. One boot-loops after the VT100 terminal reports Executing, Please Wait, the other does not output any info via the VT100, and just relay clicks.

Both units will boot into force download if I boot with the ACO button depressed, and both will load A_04 or A_05 firmware and appear to function.

If I try loading anything newer (larger?) I get the relay clicks, boot loops, or a message the firmware load was bad, different results depending on different firmware versions.

I have access to an EEPROM burner, and tried to copy to a freshly erased M27C4001 chip firmware from a working unit (C0803), but just got relay clicks on boot.

I also have a handful of New Old Stock Dallas/TI NVRAM chips en route and will try those if I can't get this solved by the time they arrive.

Any help would be greatly appreciated!

Thanks,

Ron

[newfuturevintage]

Having loaded A_05 into both failed units, and running system self-tests, I see the following failure:

RTC RAM TST Address Bus Failure.

I'm assuming RTC - Real Time Clock, and that this failure references the Dallas chip. If this is the case, I'll put down the project until the replacement chips arrive and solder those in.

I've seen enough of these dead chips to believe a dead battery internal to the Dallas chip won't cause this, as all the units I've seen with dead batteries function just fine, but don't retain programming information on power cycle.

[newfuturevintage · Accepted solution]

I think I solved my own problem:

Yes, the chips can throw a "RTC RAM TST Address Bus Failure" if the battery's completely dead, missing, or in my case, the replacement battery isn't actually soldered to the internal pins exposed by dremeling.

The lead wire I used must have just melted to the plastic housing mimicking a solder joint. That was the first unit. The second, I'm sure I tried to test it without soldering in a battery first.

Both units now boot, have successfully updated to the final version of firmware, and seem to be chugging away.

FWIW, I was able to grind down the chip to expose the battery leads with the chips in situ, even leaving the motherboard attached to the bottom of the chassis. Much easier than removing 20 pins' worth of solder from the PCB. I'm using a CR2032 battery/holder hot glued to the top of the chip, and attached to the solder points with small jumper wires. "Pin" 16 on the chip is - and "Pin" 20 is +. I say "Pin" as this pin is bent up from the internal chip and connects to the internal battery; these do not exit the chip housing from the bottom.