16MHz 68000 CPU card debugging in HP 8753A

[Timbo2020]

The CPU card in my 1985 HP 8753A won't start up and I'm pretty certain the fault is with the CPU card rather than elsewhere in the machine.

This is, by todays standards, a really simple CPU card: 68000 with RAM and EPROMs (fresh verified with original binaries), running at just 16MHz. All the parts are through hole, DIP, no SMT parts.

I've made extender cards to have easy access to the card. (See attachment)

Being an RF engineer, I've not done much CPU debugging before and would really like some help with how to tackle this.
I have a multimeter and a 100MHz analogue oscilloscope.

I have the service manual with schematics for the "A9 CPU card" from here:

http://www.ko4bb.com/getsimple/index.php?id=download&file=06_Misc_Test_Equipment/1_Brochures_and_Datasheets/HP-8753A-Manual-Service.pdf

It tries to start on power up, but halts after two seconds before displaying a garbled message on the display.
I have posted a video of the CPU card LED's on Youtube:

There is no truth table for what these LEDS mean in the service manual, it just says the left hand three should be flashing with activity.

Where do I start?

Thanks in advance

Tim

[chriva]

A few things to check:
Voltages
System clock
Reset circuitry. Does it pull it low and release control as it should?
Is HALT behaving as it should?

I could only find a lite version of the datasheet but it has pinout which should give a hint: https://www.datasheetarchive.com/SCN68000CAN64-datasheet.html

[Timbo2020]

Thanks.

Voltages, yes check +5V on every supply pin
System clock 16MHz running and 8MHz clock on CPU pin checked
Reset pulls low on pressing front panel "PRESET" button

Data and Address pins all seem to have activity on them

What is the "HALT" behaviour ? What should I see please?

Tim

[MarkL]

The manual you posted a link to is just the schematics and parts list, which you may need, but regardless of its title it's just the CLIP (Component Level Information Packet).  You want the real service manual here:

  http://literature.cdn.keysight.com/litweb/pdf/08753-90022.pdf

It explains the LED codes and everything else.


EDIT: Also, if you find any information still missing, Artek has a full manual set available.  Their scans are top quality:

  http://artekmanuals.com/manuals/hp-manuals/

[Timbo2020]

Thanks MarkL.

I thought I had all the service manuals but hadn't seen this one!

I see Page 291/298 clearly explains that with the "2" and "4" LEDs on, it's failing test 6, Main DRAM.

I'll be back on this tomorrow morning.

 

[chriva]

I have to say I'm sorry. I didn't watch the video since the app on my phone is kinda iffy.
Clocks and reset is clearly working since the leds are changing state.

Let's hope it's just a dead ram chip. Usually very cheap and easy to find new

[Timbo2020]

Thanks for the help so far, this forum is awesome.

I've run the DRAM test and it strongly suggests a bit 0 failure, but, the result is also confusing me.

Comparing it, bit by bit with the expected result (using a little bit of software someone wrote to help me).

Actual error message as dispayed on the instrument:
E S@M G@IL!1=PQPQPQPQPQPQPQPG>m

From the documentation, it should read like this (with a Bit0 failure)
D RAM FAIL m<PPPPPPPPPPPPPPPF>1

Firstly, it appears there is a minor bug in the RAM test which labels the output display as running LSB to MSB, although the actual data (and the documentation) show the result will be MSB to LSB. This was confusing at first!!! but correcting for that.....

The test result is in the attached image.

Some characters are correct, some are incorrect.

The incorrect characters are always ONLY wrong in the LSB, but sometimes high (1) when they should be low (0), sometimes the other way around. I can't see a pattern to it.

Also, in the Pass/Fail section, (rows 13 to 28), EVEN numbered bits (0,2,4,6..) behave differently to ODD numbered bits (1,3,5...) and I can't see anywhere the hardware is different in this regard. (Might this be an artefact of the software doing the testing?)

The architecture has CPU, EPROM (with the test program) and CMOS RAM on a 16 bit bus. The CMOS RAM passes it's test OK.

The DRAM with the problem is connected to the memory bus by a pair of 74LS245N transceivers. This new bus is called the Memory Data Bus (MD0-15)
(It is MD0 that the test is flagging a fault on)

The DRAM comprises 16,  64k by 1 M5K4164ANP DRAMs.

Also on this MD bus are the display latches 74ALS257N which send the data out to the display, so faults on MD bus can corrupt the displayed data.

The only other devices connected to the MD bus are a pair of transceivers to the DSP (TMS32010) which I do not believe would be involved at this stage of basic memory testing.

I have ordered some replacement DRAM's, should arrive next week.

Whilst it seems highly likely there is a problem with MD0, I don't understand the test results so changing the DRAM might not fix it.
Will update here, meanwhile, any suggestions or possible explanations, or suggested experiments, would be great.

Thanks,
Tim.

[Timbo2020]

Delighted to report that after fitting the replacement DRAM today the unit immediately boots up ! 

Thanks for the help here it made all the difference.

Of course, now I have access to the extensive self-test capability, it immediately flagged a new problem with CPU to synthesiser communications...

I'll get to work on that tomorrow.

Tim

[Timbo2020]

Just to close out this thread in case it is some use to anyone.

Synthesiser problem diagnosed to be a faulty U45 on A16 (Frac-N synthesiser PCB), a custom HP device.

Having changed all the TTL logic around it in the hope it wasn't the impossible-to-obtain-part, I was Googling for further info and came across a replacement PCB on Ebay for £40.

Job done.

Fully repaired and working now.