HP8656B fractional-n microprocessor

[ekoloski]

Hi All,

I have an otherwise functional 8656B that has experienced an interesting, and annoying fault. The microprocessor (A3U28) that interprets serial data and issues commands to the fractional-n asic (A3U17) has stopped working. I do see that the 4MHz clock is working, power is good, the reset line is good, and serial data is being clocked in, yet nothing appears on the output pins. This not only causes an inability to lock the low frequency loop, but it also impacts modulation.

The failed chip is a custom Motorola microprocessor, HP PN: 1820-3618, Motorola PN: SC87336CP. I am unable to find any information on the chip, let alone the firmware that HP loaded onto it.

As I see it, I have a few options for repair:

  - Obtain a replacement chip from a donor unit (this is the boring option, and I would not be able to bring myself to cripple a working unit).
  - Obtain a working 8656B and painfully observe the input/output with a logic analyzer, and try to reverse engineer the instructions (I am patient and crazy enough to do this). Then use this to write a firmware for a modern microprocessor.
  - Obtain a working 8656B and attempt to read out the contents of the EPROM (see below for an explanation of why this may not be possible and why it may be unethical) then use it to write a replacement firmware for a modern microcontroller.
  - Obtain documentation on the fractional-n asic, a chip which seems just as illusive in terms of documentation as the Motorola microprocessor, then use it to write a new firmware for a modern microcontroller

Regarding reading out the firmware. Similar early motorola microprocessors used an interesting schema to program their EPROM. In short, there is a hardcoded bootloader which can be called. This bootloader is designed to program the EPROM in-situ. An external EEPROM containing the desired code is connected to one of the ports, and an external counter is connected to the address lines of the EEPROM. The microprocessor outputs a clock and reset signal which increments a counter to control the EEPROM address lines. The microprocessor accepts the data from the EEPROM and programs itself one byte at a time, iterating through to the end. Following a programming cycle a verify is performed. During this verification stage I would expect the clock pulse duration to change based on a successful or a failed compare of the byte. If I do not apply  programming voltage to the microprocessor during programming, the EPROM should remain unchanged. I can use this to my advantage. By iterating through all 256 combinations of values per byte and measuring this clock duration, I should be able to compile a table of values from the EPROM. It is a painstaking process (thank goodness for automation) but I believe it could work. From there, I would have the binary contents of the program and can dissassemble it, then hope that there are no custom opcodes in this microprocessor. Oh, and beyond all of that, if the chip has been configured in secure mode by setting bit 3 of the mask option register, as I expect it likely will have been, the programming bootloader will not run and none of this will work.

Let's say I do this, and am successful. There is still the moral implications of copying HP's intellectual property. I believe that, since this is a long out of production/support piece of equipment, and that I would use the knowledge only to repair the unit, I would be able to sleep well at night having copied it.

My questions to the group before deciding how to proceed are:
  - Does anyone have any information at all about the fractional-n asic, HP PN: 1820-2004 or it's instruction set?
  - Does anyone have any information at all about this microprocessor?
  - Does my approach to read the microprocessor EPROM sound valid, or have I gone off the deep end 
  - Is it immoral of me to even attempt to copy the firmware and port it to a modern microcontroller, provided I would not distribute it at large, unless anyone on the forum finds themselves in a similar issue where it may help?

[m k]

But you wouldn't know the correct answer, only the current answer.

Reverse engineering would be fine in EU.
But sane, maybe it's a matter of perspective.

Much easier is tapping a working machine and then duplicate the outcome.

[ekoloski]

I agree. My initial thoughts were to find a cheap (broken) 8656B to harvest the part from. Ultimately I'd end up wanting to repair the second 8656B, since I hate to see these things end up in the trash bin if they are repairable. With only one functional chip between the two that presents an obvious problem.

Reading out the replacement chip's firmware is unlikely. I can't imagine that HP would not have set the security bit in the mask ROM, but I'll still give it a try if/when I get my hands on one.

The chip appears to have a rather uncomplicated role in life, for the most part it just converts serial data to parallel, and adjusts the bits that it outputs dependent on the pll lock status. I am patient, have a decent logic analyzer, and a bunch of spare microprocessors. I believe I will be able to cobble together something that will accomplish a reasonable facsimile of the functionality. Something like a cheap atmega16 should do the trick, and putting it onto a board to break it out to the correct pins in a dip form factor should not be too tough.

As for sane? Ha, I harbor no delusions, but at least it's a constructive project to revive some useful test equipment 

[m k]

Take the faulty chip off and send it to Noopy.
He'll then liquidate the top of the chip away and send it back to you.
In a mean time you've constructed a test facility with those very sharp pins.

Afterwards when you're done with the Motorola chip and have a reference you can start a side job as TE old ASIC rescue service.
I can instantly point "few" other models that need some cure.

Reverse engineering in EU goes so that if manufacturer is not supporting your repair you are free to try intrusive techniques.
You're obviously still not allowed to profit from manufacturer's immaterial stuff, but...

Are you sure there are no ready/steady/go pins?
Nothing out is always a bit different than something out.

Can you exclude something by cross checking pins?
Even Motorola had sort of limited variations.
'88 manual has 3 families, 6800, 6805 and 68k.

[ekoloski]

There's an idea, delid the faulty chip and see if there's any helpful markings on the die  That's beyond the scope my abilities and arsenal of tools, but I'd consider enlisting some help. I certainly wouldn't be capable of microprobing the die to do any forensics though.

I've reviewed everything I can find in the service manual for the 8656B and there are some external inputs to this microprocessor that could change it's behavior. For example, the unit starts up in a special 'low frequency loop service mode', and there are four jumpers (only two of which seem to be used) to place it into various test modes. Nothing seems to suggest that the chip would be held in a halt or wait condition though, with the exception of the reset line which is active low and is not being pulled low during my observations. The long and short of it is, serial data appears on the input, and nothing appears at the output.

The service manual does contain some valuable hints. To paraphrase, serial data consisting of an instruction and several words of data are clocked in. The microprocessor stores this and transfers it to the fractional-n asic in the form of 4 bit parallel words. The first word is transferred followed by a 70uS delay to ensure that the fractional-n asic has received a cycle start pulse. Sixteen 4bit words are then sent followed by an instruction word to define the data, and finally an instruction to terminate the transfer. This microprocessor also sends instructions when FM is enabled. There is also an 'out of lock' signal present as an input.

I can't find anything specific about the fractional-n asic and the commands/data it expects to receive. But the block diagram in the service manual implies that data is accumulated in a register which feeds into an adder. This forms the start of the loop and with input from the [hase accumulator decides when ti remove a cycle. I'm guessing that the 'data in' and the 'data out' of the microprocessor are pretty much a 1:1 serial to parallel conversion, with some magic timing sprinkled in to allow the asic to digest the input. If that is in fact the case then even without a firmware dump from a working microprocesor I believe I should be able to write a suitable firmware. The first step is to acquire a working mcroprocessor from which to make detailed observations.

Regarding the micro itself, I strongly believe it's a custom variant of the 6800 series. I can find no datasheet or specifics, but it is very similar in function and identical in pinout to a MC68705P5, which is a slower chip and is a UVPROM variant as opposed to the EEPROM that HP seems to have sourced. I believe I have devised a method to simulate a program of the chip (without supplying a programming voltage) and tricking it into performing a verify. This all relies on the hopes that the secure bit is not set in the option mask, and that the programming bootloader will run, and this was not a one time programmable chip. If so, and this is a lot of wishful thinking, I would be able to dump the EEPROM. From there, as long as there are no magic opcodes for this variant of the chip, I can dissassemble the firmware and better understand what exactly it is doing.

It's a challenge.

[aeg]

If it is indeed a house numbered MC68705P5, I would expect it's the same die in a package without a window. But are you sure it's not a mask ROM MC6805?

[m k]

The manual I found has a bit low picture quality, but I'm quite sure the MCU has a text NMOS, if that is excluding something.

Motorola manual is also stating that verifying ROM is a special thing and for internal use only.

Is there any life in any port pin?
Some have different directions than others.
I couldn't find how the situation is initially, wrong manual I guess.

[ekoloski]

The manual online is a poor quality scan, I've ordered a better one from Artek but the gentleman who runs it has been unexpectedly offline for two weeks. There's a community of concerned folks over on the HP-Agilent group at groups.io who started a thread about it, I really hope that he is OK.

Regarding the chip, it's pretty dead. I haven't seen anything on the outputs. I've since removed it, installed a quality socket in the 8656B, and will place it in a breadboard to see what I can find out. I think it's done though.

Oh, and @aeg, I hope it is not a mask ROM. That would rule out any chances of reading out a firmware.

It looks like my best option will be to find a broken 8656B and do some detailed observation of the signals in and out of the chip. From there, I'll write up a replacement firmware, and then I'll have another 8656B to fix up. I'll post back here if and when I make any progress, maybe it can help someone else down the line if they run into this same failure mode.

[ch_scr]

If it is indeed mask ROM (and surely HP was no stranger to that concept), the ROM content might be restored from pictures - so there could be some value in sending it to Noopy, after all.

[ekoloski]

Hello all, I know it has been quite a while since there was any update on this. I had started the project but put it onto the back-burner. In the last couple of weeks I have revisited it and made significant progress. It's posted here in hopes that it could be helpful to others.

The chip is indeed a mask ROM. From it's pinout and some guesswork I believe it to be based on the Motorola 68705P5. Recently I came across some work done by [Sean Riddle](http://seanriddle.com/mc68705p5.html) with this and similar chips. He describes an obscure operating mode from this same family of CPU, and how he exploited it to read back the address space of the chip.
 

This 'non-user' mode is entered by powering the chip with /RESET /INT and TIMER high to VCC, and PC0 pulled up to 7.5V. A Clock is supplied to the chip. When it comes out of reset it will ingest opcodes to execute from PortA. At the same time an output is latched onto PortB. If the instruction on PortA happens to be 0x9d (nop) then the chip will simply continue to increment and wrap through all 2K of it's address space. The output on PortB is both a permutation of the current address, and the contents from that location in memory. There is also apparently some additional data on PortC, but that seems to be what is damaged on my chip, so I had no success there. Anyway, I figured I had nothing to lose by trying this, the chip was already broken. So I breadboarded everything up and hooked up the scope.


To my amazement, there was data! The output is sampled on the falling edge of each clock, 8 clocks are required to produce one byte of actual data, it appears in the form of:
{ADDR} {ADDR} {DATA} {DATA} {ADDR} {ADDR} {DATA} {DATA}


I found that the pattern was repeating at each 16K boundary, meaning we have a 2K address space, which matches the 68705P5. The chip will happily loop through and read out the entire address space until reset.



A healthy chunk of this data was captured on the logic analyzer. The ROM data was sifted from the noise and any non ROM locations were replaced with nops. I then disassembled it with unidasm from the [MAME project](https://www.mamedev.org/), and the result actually looked sensible.

After learning the 6805 instruction set I now understand how this chip functions and was able to write a replacement for a modern Atmel 32U4. It's also clear that reverse engineering this as a 'black box' would have eventually gotten me some of the functionality, but the test modes and some seemingly unused commands would never have been implemented. Maybe the 8656B uses them, and I just haven't figured out when, or maybe they were written for some other use. After reviewing the code I also see why a damaged PortC would bring the chip out of normal operating mode and into test mode. When TP26 is high, the chip will loop until reset waiting for one of the test mode selection pins to be brought low.

I plan to post the original dump along with my port and the gerbers for a board to fit a mega32U4-MU into the original footprint. Overall, this method seems a little more accessible than decapping but I'd still love to try it on this chip someday!

[Tomorokoshi]

Regarding Artek:

https://www.eevblog.com/forum/testgear/artek-manuals-digital-download-orders-working-again/

[ekoloski]

Excellent note about Artek! It's wonderful that they're continuing on and making these manuals available.

In case anyone is interested, I've posted the files on github: https://github.com/ekoloski/hp8656b Posted here are a short writeup on the process to dump the original ROM, the kicad files for my replacement board, the original disassembled code from the HP Mask ROM, and my modernized replacement for the 32U4. I hope that this could help someone else in the future who may need to perform a similar recovery on another mask ROM.

[Tony_G]

This is outstanding Ed - Congrats on the work.

Have you tried it in the 8656B yet? How'd it go?

Look forward to hearing from you,

TonyG

[ekoloski]

Thank you! It does work well in my spare 8656B.

While writing the 32U4 firmware I spent quite a bit of time verifying that the timing of the new version matches up with the original. The 1820-2004 Fractional-N controller seems to be as sparsely documented as the 1820-3618 mask ROM. I couldn't find a datasheet and was sort of flying blind on any timing constraints.

An arduino was used to simulate serial commands, so I could send whatever I wanted and vary the timing between commands. The new 32U4 and my only functional mask ROM were wired up in a breadboard with a logic analyzer on their outputs and everything was compared, then delays were added to compensate. I was also able to verify the various test modes and mostly validate signature analysis. I don't have a proper signature analyzer to check with, but the waveforms all matched up.

Once that was all done I threw it into the 8656B to confirm.