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?