Vaxstation 400/90 power supply

[Maciej W. Rozycki]

On Mon, 23 Mar 2020, Brent Hilpert via cctalk wrote:

> > I have 4000/90 which behaves funny. It only starts, after switching on
> > twice. The first time, all LEDs stay on, flipping the switch off/on, it
> > boots happily.
[...]
> I've experienced behaviour like this in an Apple-something.
> It related to a dead RTC/boot-ROM battery. I figured it out (years ago) 
> but now forget the exact mechanistics, but it was along the lines of the 
> first power-on leaves enough charge in a capacitor for the subsequent 
> power-on to see the RTC/ROM as at least 'valid', albeit not 'correct', 
> if you get my drift.
> 
> That's just a suggestion/possibility - I'm not acquainted with the 
> 4000/90 specifically.

 A correlation with an expired DS1287A chip seems plausible, though not 
fully verified.

 I have a 4000/90 that seemed dead having been stored alive and left 
unused for a prolonged period.  The symptom were all LEDs steady lit after 
power-up, as if the CPU has failed to execute any instructions after 
coming out of reset.  Multiple consecutive power-ups didn't help.

 The 4000/90 has a couple of potential reasons as to why its CPU would not 
start executing:

- a broken CPU (obviously) or chipset,

- flash ROM corruption (with no write-protection provided regrettably all 
  too easy to happen),

- bitfile ROM corruption (used with the CEAC and SQWF FPGAs in the /90 
  only; replaced with ASICs and the ROM removed in the /90A and the /96),

- power-good signal not asserted by the PSU.

NB the LED latches sit on EDAL (as does the DS1287A), so if the CEAC FPGA 
does not come up they won't budge even if the CPU executes from main flash 
ROM.

 If I were to believe documentation, I'd expect the very first couple of 
instructions executed from the reset vector to poke at the LEDs rather 
than the DS1287A to indicate execution has started, but I haven't actually 
looked at the code there (I should have!).  I didn't therefore consider 
the DS1287A, especially as it was already dead in that machine before it 
was left to sit.

 It appears to make a difference however whether the DS1287A has been only 
discharged enough not to keep the contents across a power down or whether 
it has been indeed deeply discharged (the chip obviously continues to suck 
power from its lithium cell even past the point it cannot hold contents 
from anymore).  I experimented with replacing the chip with a couple of 
spares, but it didn't help.  Frustrated I put the machine aside and left 
it untouched for a couple of months.

 I came back to it once again, disassembled, reassembled, disassembled 
again and verified the tantalum capacitors in-circuit (all measured fine) 
replaced the PSU, replaced the DS1287A a couple of times again, and then 
suddenly with one of the replacement DS1287A chips it started to work.

 I tried the chips that didn't again and oddly the machine continued to 
work, and kept working on many occasions for a couple of years more until 
I last checked it sometime last year.  Hopefully it still does (and I plan 
to replace the DS1287A once expired with one of my reworked chips as shown 
here: <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/ds1287/>; so 
far I only did the replacement with a couple of DECstation 5000 systems), 
however I cannot verify that now due to the current chaos in Europe making 
travel impossible and keeping me away.

 I need to warn you too that the H7819 PSU the 4000/90 uses also suffers 
from the quaternary ammonium salt system issue with some capacitors used, 
so it's at risk of developing catastrophic leaks (I don't remember offhand 
if the capacitors are safely upside down as in the H7821, and I can't 
easily check right now; I highly suspect it is the case though, so try 
keeping the machine in the right position while in storage).  Furthermore 
much of the contents of this PSU has been treated with hot melt, making 
any diagnosis or repair a real pain.  I would recommend examining the PSU 
just in case anyway.  It might be on the verge of giving the power-good 
signal.

 I realise I may have added confusion rather than helped, but at least 
there may be hints as to the causes for odd behaviour and a hope for full 
recovery.

  Maciej