3
\$\begingroup\$

I have two identical PCBs that include the same MCU MC68705R3CP. Unfortunately, one of them has an output pin PB4 configured as Darlington drive output that has a high output regardless of the normal operation of the board (it seems that an output transistor is fried).

The other board has the same MCU but it is not responsive at all.

I want to transfer the code from the working MCU with the faulty output pin to the one that is not responsive.

\$\endgroup\$
4
  • \$\begingroup\$ I need a way to transfer the code. \$\endgroup\$ Commented Oct 23 at 18:02
  • 2
    \$\begingroup\$ The fried port pin might be required to read the data out. The code might also be locked. There are ways around this, but they’re not trivial. Nevertheless you’ll need hardware for that chip in order to program it…. And that chip was obsolete years ago. \$\endgroup\$ Commented Oct 23 at 18:30
  • 1
    \$\begingroup\$ Is there a reason to assume the non-working one is not responsive due to having lost the program? It could be completely fried. \$\endgroup\$ Commented Oct 24 at 10:51
  • \$\begingroup\$ No, just an assumption. \$\endgroup\$ Commented Oct 27 at 11:50

1 Answer 1

Reset to default
11
\$\begingroup\$

By regular means: you can't.

This is an ancient microcontroller, but it has an internal self-programming bootloader, which is rather cool for its age.

When you read its programming manual (Motorola AN-857), you'll learn that it's basically programming itself by reading an external EPROM IC. There's no data coming out of the chip, and no official debugging interface to externally interface the memory either.

You're out of options.

If you have a few more spare units, you can try this (archive.org memento) method documented by a person called Sean Riddle. You will need to unsolder that IC first, then:

I was able to electronically dump the EPROM using non-user mode. I used a 1 MHz clock on the EXTAL pin with XTAL grounded, tied /RESET, /INT and TIMER high, and connected PC7 to 7.5V via a 1K resistor. I tied the PORT A pins to +5 and ground using 8 1K resistors to set it to $9D, the opcode for NOP. The entire 4K address space contents were output on PORT B, including the I/O ports, RAM, EPROM and bootstrap ROM; I captured the bytes using a logic analyzer. In NUM, the chip outputs address information, fetches an opcode from memory as normal, outputs that opcode, then executes the opcode input on port A. Since the resistors feed it NOPs, it just keeps fetching the next byte and outputting it, dumping all of memory. The address info that's output is a permutation of 8 of the address bits.

The dump starts at offset $D9D because when the chip fetches the reset vector, the resistors feed it $9D9D.

You do the same, capture the bytestream, extract the EPROM contents, and use that with a programmer board built according to the instructions in AN-857. You will hence need to

  • unsolder at least the program containing microcontroller
  • build one dumper board,
  • capture the bytestream
  • reconstruct, manually, from an instruction table and understanding of what the program is supposed to do, the missing 4. bit, which is stuck due to the output problem, which means all certifications and functionality guarantees of the original are void, because you're effectively guessing 1/8 of the software
  • build one programmer board,
  • buy one EPROM programmer to program the programming EPROM (and buy an EPROM of matching type, which could be a challenge in its own rights today; or you build an EPROM emulator…)
  • buy or acquire one non-broken microcontroller (i.e., not the microcontroller from a completely non-responsive board, which is almost certain to be damaged worse)
  • program that working microcontroller

Or, you throw away both boards, and replace them with a new micrococontroller board with a modern microcontroller programmed to fulfill the same job, and make damn sure to keep the source code to your firmware long-term archived.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ It's not quite clear how the bootloader mode works, but if the NOP bytes actually get executed, it would theoretically be possible to execute a different program that dumps the data out over just one pin. The method from matthieu.benoit.free.fr/pdf/How_to_read_the_MC68705U3_EPROM.pdf that uses the verify mode could also work. \$\endgroup\$ Commented Oct 24 at 10:29
  • 1
    \$\begingroup\$ @jpa I think the "bootstrap mode" (word from manual) is actually code run from internal ROM, whereas what Sean Riddle describes seems to be "non-user mode", which I guess does exactly what is described, load instructions from input pins (oh my, these were less complicated, less powerful CPUs…). You're right, an external microcontroller or FPGA or somehting could actually stream any program that way. I don't know if there's any restrictions on clocking, stalling etc – NOPs are typically rather uncritical with that. \$\endgroup\$ Commented Oct 24 at 14:10
  • 1
    \$\begingroup\$ @jpa oh nice a timing sidechannel attach long before these were a called that :) \$\endgroup\$ Commented Oct 24 at 14:14

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.