Help, who can reverse compile 68HC11 firmware internally? I encountered difficu

[daisizhou]

Hello everyone, thank you for browsing.I plan to rebuild this QA45 host,I drew the schematic and read by programmer the firmware.
But there was an error in the circuit diagram at the back of the manual,For example, when IC16 is labeled as LH5160HD on the circuit diagram, it has 32 pins, but the actual circuit board has LH5164 with only 28 pins，So the signal lines uPA13 and uPA14 will be lost.
The main chip of the motherboard is MC68HC11G5FN, the RAM chip is LH5164A, the ROM chip is 27C1001, and the PLD chip is 22V10Z.

The initial version of the schematic diagram is located on page 57 of the "Metron_QA-45_ - Manual. pdf" file.
The file "1Processor Board1_2023-09-05.zip" is a schematic diagram that I have redrawn and is the same as the actual image. The firmware is extracted from here

I don't have a real PCB circuit board. The circuit board in the picture was taken and provided to me by my friend.So I can't measure the authenticity of the verification signal
I have obtained the internal firmware of 27C1001 on the real motherboard. If you could reverse compile it and tell me the actual connection and wiring, I would greatly appreciate it. Thank you for your help

[daisizhou]

Can anyone help me?

[darkspr1te]

I am confused by your question,
you say IC6 but do you mean IC16 which on the diagram is 28pins and also in the picture is 28pins , Then there is the 27c1001 eeprom , this is only a storage device and it's code is read out by the cpu which you did not mention so there would be no way for someone to reverse engineer the dumped code.
Front what i can see is the diagram does match the pictures.

*edit* sorry i just noticed the motorola 68hc11 cpu, you should try loading the code into ghidra reverse engineering app and see what it decompiles


darkspr1te

[daisizhou]

Sorry, I lost a "1", it is IC16.Please see page 57 of the manual "Metron_QA-45_-_Manual"，IC16 is a 32-pin structure。
Regarding 27C1001, I mean, can you try to reverse the code? I hope to find (uPA0-uPA15), (uPD0-uPD7) and WRLCD, RDLCD, CSRAM, RWRAM, CSROM, OE, CSLCD, A17ROM, A16ROM, whether these signals It is the real p14-p22 pin position of IC15(22V10Z)

In other words,I want to know if the signals in the firmware are the same as those on the schematic I drew.

I'm not good at reversing firmware, so I hope you guys can help me, thanks

[daisizhou]

The following figure is the 22V10 firmware and 22V10 logic diagram

[eutectique]

Your attached file "Metron_QA-45_-_Manual.pdf"  is 75kB-long jpeg picture, not a pdf.

[daisizhou]

I re-uploaded it, please check

[daisizhou]

For example, please see, such as U13-MC68HC11G5 pin 57 (H0), pin 6 (A3), pin 7 (A2) they are missing.

Does the uPA5 signal come out from the 73rd pin of IC13 and connect with the 5th pin of IC16 and then connect with the 7th pin of IC14?
Does the uPA13 signal come out from the 16th pin of IC13 and connect to the 28th pin of IC14 and then connect to the 2nd pin of IC15?
Does the WRLCD signal come out from the 22nd pin of IC15 and finally connect to the 5th pin of J11?

Is the information in the firmware consistent with my actual connection line

[daisizhou]

Has anyone found a clue yet? I am anxiously waiting

[darkspr1te]

Sadly i know nothing about mc68 code at all but i do know a little about the designs.


The device marked PLA is programmable logic array, this is acting as a memory handler for the SRAM and eeprom so for example if you access 0x1000 you get eeprom , if you access 0x2000 you get sram.
The extra pins on the device marked with 28 or 32 pins has the extra pins tied to ground in turn it stops access to the upper memory in the device. so you can use a 32 pin device or a 28 pin and just tie the extra pins to gnd and 5v.
This trick is often used to fit a 32k device in 16k socket and still have the same functions you just cant access the last 16k of the chip




Beyond that i cant really say.


darkspr1te

[daisizhou]

I understand what you mean.

I hope to further confirm in the code. Only by doing so can we ensure that the physical connections and the connections within the software are one-to-one and can we be 100% certain

[DavidAlfa]

How do you think the code will reveal the connections?
You will only get assembly instructions .
Store this data there, read that, compare this...
If you have schematics, trust them, they're very simple.
Having doubts, get the board shipped to you for verification.
Of course you encountered "difficulties", what you ask is no joke, would easily take a week (or more) of work for anyone with experience to reverse it all.

[abyrvalg]

A quick disasm shows that 0x4000-0xFFFF of 27C1001 are mapped directly to 0x4000-0xFFFF. The upper half of 27C1001 contains some graphics data (font?) starting at 0x14000, no idea about it’s mapping yet. RAM appears to start at 0. Also there is some I/O port (many individual bit manipulation sequences in code) at 0x1000. What do you want to know exactly?

Edit: also your 22V10 fuse map looks strange. So many rows have connections to multiple inputs.

[daisizhou]

thanks.
What I want to know is, for example:
Does the uPA5 signal come out from the 73rd pin of IC13 and connect with the 5th pin of IC16 and then connect with the 7th pin of IC14.
Does the uPA13 signal come out from the 16th pin of IC13 and connect to the 28th pin of IC14 and then connect to the 2nd pin of IC15.
Does the WRLCD signal come out from the 22nd pin of IC15 and finally connect to the 5th pin of J11.

Simply put, is the actual circuit consistent with the firmware

[daisizhou]

Unfortunately, the actual circuit board is currently in use and cannot be provided for me to measure.
I can only obtain images, firmware, and old version schematics

[DavidAlfa]

I managed to diassemble the lower 64KB using DHC11. It's a DOS executable, so I had to use a Win98 VM to run it.
System starts at FFFE (reset vector), which loads 91F3 address. That's the program start.
Don't ask me about it, I know nothing about hc11 asssembly.

[DavidAlfa]

Code: [Select]

91F6 86 B3            ldaA #$B3
91F8 B7 10 39        staA L1039

This writes 0xB3 to register A, then copies A into 0x1039, which is the OPTION register.
Read the datasheet to understand what this means.
You have to follow all calls and branches to find out what the program does.
And you'll need a lot of reading to learn about it:

https://www.clear.rice.edu/elec201/Book/6811_asm.html
https://www.extreme01.com/school/nyustel99/ics/19_HC11_InstructionSet.pdf

[daisizhou]

This is the actual operation video used
https://youtu.be/lsbkvMo0TyE

[abyrvalg]

CPU’s uPA5 and uPA13 are definitely connected to ROM’s A5 and A13 (because of that 0x4000-0xFFFF mapping I’ve mentioned above).

I2C EEPROM is connected to H3 (SDA) and H2 (SCL) (I see typical software I2C primitives - Start at 91D7, SendByte at 9167, Stop at 91E5) - this matches your schematic.

Questions regarding GAL can’t be answered fully (with pin numbers) by looking into ROM disassembly at all. I can see that some enable or reset line of the LCD is controlled by A1 (it is set to 1 at init and never touched), cmd/data line is controlled by A0 (1-cmd, 0-data), reads/writes are definitely being decoded by GAL (the LCD is mapped to 0x1800, this should decode at least uPA11 and uPA12 lines), but without correct GAL dump I can’t say to which pin the result is output.

[daisizhou]

I am unable to determine the A16ROM and A17ROM of the ROM chip. The other signals appear to be consistent with the old schematic diagram

Is GAL's firmware useful? Can it provide clues?

[DavidAlfa]

Converted the PAL jed file into equations using JED2EQN.EXE from PALASM package.

I don't see the input equations for A17ROM (F13) / A16ROM(F14), but their outputs are used for other equations.

L004884 00000000000000000000000000000000000000000000*
L004928 00000000000000000000000000000000000000000000*
L004972 00000000000000000000000000000000000000000000*
L005016 00000000000000000000000000000000000000000000*
L005060 00000000000000000000000000000000000000000000*
L005104 00000000000000000000000000000000000000000000*
L005148 00000000000000000000000000000000000000000000*
L005192 00000000000000000000000000000000000000000000*
L005236 00000000000000000000000000000000000000000000*
L005280 00000000000000000000000000000000000000000000*
L005324 00000000000000000000000000000000000000000000*

L005368 00000000000000000000000000000000000000000000*
L005412 00000000000000000000000000000000000000000000*
L005456 00000000000000000000000000000000000000000000*
L005500 00000000000000000000000000000000000000000000*
L005544 00000000000000000000000000000000000000000000*
L005588 00000000000000000000000000000000000000000000*
L005632 00000000000000000000000000000000000000000000*
L005676 00000000000000000000000000000000000000000000*
L005720 00000000000000000000000000000000000000000000*

I really can't figure out this:
https://www.eevblog.com/forum/microcontrollers/help-who-can-reverse-compile-27c1001-firmware-internally-i-encountered-difficu/msg5046832/#msg5046832

[DavidAlfa]

(These videos can't be embedded)

Generic Array Logic Hand Disassembly of the JEDEC File (Part 1 of 2)
https://youtu.be/h_d4npbKpdY

Generic Array Logic Hand Disassembly of the JEDEC File (Part 2 of 2)
https://youtu.be/r2sXYgxVwVg



Explanation of all 0s:
https://youtu.be/h_d4npbKpdY?t=937
So they mean nothing. A16 and A17 are always "0". Only the first 64KB are used after all?
I guess they had the PAL just in case they required more memory, but was enough in the end. Or for other board versions.

[DavidAlfa]

Well, well... 

I found this PR adding HC11 support in Ghidra.
Downloaded the latest sorces, applied the patch, compiled... Works! Can be downloaded here.
You need JDK17.
Attached the project. Still need to properly map some memory areas, but it's enough to start working.
Edit: Added register names, indentify reset, main, sysInit...

[DavidAlfa]

The ROM_CS equation is a bit strange:

Code: [Select]

/f18= i3 * /i3 * f21 * /f21 * i4 * /i4 * f20 * /f20 * i5 * /i5 * f19
      * /f19 * i6 * /i6 * f18 * /f18 * i7 * /i7 * f17 * /f17 * i8 * /i8
      * f16 * /f16 * i11 * /i11 * i13 * /i13

i3 * /i3, etc, will always be 0...

[abyrvalg]

External RAM is used for sure. There are many sprintf(buf, …); OutTextXY(buf, x, y); sequences with buf located at 0x2Fxx - that must be it.