Products > Test Equipment
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 :-DD
- 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 ;D 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.
Navigation
[0] Message Index
[#] Next page
Go to full version