Disassemble bin file for 80c152

[Wiljan]

Hi, I have a CPU board using a Intel 80C152 MPU for a CNC machine which does not boot correctly.

So to try to find out what is the problem (and also to have a backup)  I have dumped the EPROM from the board a 27C010 Checksum 0x3941 which fits the label on the EPROM

I tried to disassemble in the DIS8051 but it fails, hope someone in here does have a better dissembler.

I have attached the dump

[lapi]

Once upon a time... I reverse engineered the FW of a scanner. I used this http://plit.de/asem-51/dis51.html disassembler. Though very basic, it does good job in raw disassembling. From there on it is all manual work. The disassembler comes in source code, but the make still works flawlessly, so if you have gcc build environment, mere "make" will produce working executable.

It requires basic Intel hex input, which can be made from the binary, for example, with objcopy like "objcopy -I binary <binaryfile> -O ihex <hexfile>. The binary here is 128 kB. This disassembler can handle only 64 kB, but so can the MCS51, so this 128 kB contains something else besides just one program address space image.

So, what I did with you binary, I ihexified it, then manually, in text editor, saved low 64 kB to one and high to another file and then disassembeld both. The outputs are in the enclosed file.

I briefly looked at the codes and both parts appear to contain valid code. In the beginning of the lower part (27c010_3941-1.asm) there is a function

L0007: ;; Wait DMA to be free
    MOV A, 93h
    ANL A, #2h
    JNZ L0012
    SJMP L0007

L0012: ;; Configure DMA channel 1
    ;; Set source address
    MOV A, 53h
    MOV 0B2h, A
    MOV A, 52h
    MOV 0B3h, A
    ;, Set destination adderess
    MOV A, 55h
    MOV 0D2h, A
    MOV A, 54h
    MOV 0D3h, A
    ;; Set length
    MOV A, 57h
    MOV 0F2h, A
    MOV A, 56h
    MOV 0F3h, A
    ;; Start DMA (do increment destination and source addresses + go)
    MOV 93h, #51h
L0014: ;; Wait for DMA to complete
    MOV A, 93h
    ANL A, #2h
    JNZ L0013
    SJMP L0014

L0013:
    RET

Which appears to do a DMA transfer. The contents of the high part (27c010_3941-2.asm) requires
more thought. To start with, the call to the end of the address space (L0003) requires some
explanation, that someone else might be able to find.

Anyway, happy reversing!

[nctnico]

Why would you dig around in software? If the checksum is OK then the problem is somewhere in the hardware. EPROMs are very unlikely to fail. I'd check power rails (electrolytic capacitors!), reset lines and other signals around the processor.

[Wiljan]

@ lapi than you for disassemble the bin
Very good information to know about the 64Kb limit, the board does also have a FPGA on board ATT3030

@nctnico we do have 2 MPU board with same FW EPROM with same data (CHKSUM) one is failing to be read in a EPROM programmer TL866II+... I could read it when I made a quick Arduino reader all 5V

So I have the feeling that the EPROM might be out of spec and could fail any time (it's a system from around 2000)

Those board does fit into a bigger CNC system and 1 board works fine ... on a Uart (9600, 8N1 by default) you can see different messages in Italian ... different levels of startup, (Errors) if you view the bin file you can see those like 75% down the file.

Also there are UK messages in the beginning like 15% down the file with baud rates and other settings so we want to try to understand how to use a terminal a bit deeper to find the problem.

the 2 boards does  not boot to the same message

Different levels of startup, so the idea to look on the code its to try to understand what makes it stopping ...it's not stopping at the same time on each powercycle

If we should change any code shold be the Itailian to UK, but that might be posiible by just tweeking the hex file and adjust the checksum to fit, but this not important right now.

Hope it makes sense 

[nctnico]

I guess you already swapped the EPROM from one board to the other to rule out the EPROM? If there are any I2C peripherals on the board I'd start there. It could be there is an I2C EEPROM on there with a configuration which is damaged. If it is a address/databus system I'd look at the waveforms. Levels which are half way are a tell-tale sign something is wrong. Swapping socketed chips between the working and non-working board is also an option.

Using Google translate on the Italian messages would be a good start though. They probably tell you where to start looking.

[abyrvalg]

Let's do it the other way: you post console logs and I'll tell the reasons for stopping there. It is much easier to analyze some specific points deeply than to produce a good disassembly of entire dump.

[Wiljan]

@ ntxnice , sure we have been using google translate to try to get just a bit idea on what's going on.
And yes we did swap the EPROM's and the working MCU board does boot withe the other EPROM, but I still believe it might be not acting normal due to I can't read it in my Programmer, but sure it can be the programmer failing, but it works fine with 27c512, 27c256 Eprom's

@abyrvalg, thank you for offering your help on combining the log vs code to try to get a better understanding

So the CNC machine is a BIG one and not in my workshop, I try to help a friend
The CNC does have a huge electric rack with a lot of units in
One of those unit does have a PSU board where this MCU board is a plugin board.

The PSU board we have connected as standalone in my friend's workshop and I only have a mix of boot log (many power cycles and swap around) at my hand right now but here you have some of it

Code: [Select]

//-------Log from a MCU not working correct--------

Un bonjour de PROM main

test checksum firmware
test application ram
bist OK

Accensione del 24VDC in corso

Intervento di uno degli interruttori di protezione della CNC


//----------So here nothing more happens it we powercycle the same comes again-----

//------- If we just trip the 24V very short (like 1 sec) it goes a bit futher

Un bonjour de PROM main

test checksum firmware
test application ram
bist OK

Accensione del 24VDC in corso

Intervento di uno degli interruttori di protezione della CNC

//-------This is a check of some safety switcehes in the machine--



//------Log from a MCU in a PSU we belive working correct---------


Un bonjour de PROM main

test checksum firmware
test application ram
bist OK

Accensione del 24VDC in corso

U24DC OK

Lo stato del 24V mantenuto da batteria e OK

L'accensione del 24VBAT viene effettuato

L'ultimo spegnimento e stato causato dal comando PowerOff
in seguito ad un ACLOW

Bisogna premere sul tasto TEST o mandare il comando Start
per andare nell'applicazione.

salto a HPSmain

Un bonjour de HPSmain !

Retour de Started
verifica della compatibilita tra HW e SW

Programmazione dell'alimentazione del generatore

uscita dallo stato d'emergenza

Power fail causato da uno stato d'emergenza

uscita stato d'emergenza tramite il pulsante TEST

Power fail causato da uno stato d'emergenza
Only thing I have at my workshop right now is the faulty MPU board where I did hope that I could add 5V and then find the Uart TX pin, but it seems like the board does miss some reset or so ... I  don't get any TX.

We have no low level schematics, only the interconnection on machine and a Block Schematic of the PSU

[abyrvalg]

Looks like you've posted the same log for both "not working correct" and "it goes a bit futher".

What I see in the code:

Code: [Select]

#power up 24VDC bus
print "Accensione del 24VDC in corso"
write port 0x8045=1   #this must be the 24VDC on/off bit
write port 0x8048=0x90   #some status indicator I guess, different values are written to this port on errors
    #call test 24VDC bus
    if port 0x8041.0==0:   # the main "U24DC OK" condition
        return OK
    if port 0x8042.6==0:
        print "Driver del bus di controllo delle potenze in cond. FAULT1" # 24VDC driver fault
        write port 0x8048=0x3B   #status port again?
        return ERROR
    if port 0x8043.3==0:
        print "Intervento di uno degli interruttori di protezione della CNC" # safety switches are wrong
        write port 0x8048=0x44  #status
        return ERROR
    else:
        print "Il 24V principale fuori toleranza" # 24VDC is out of range
        write port 0x8048=0x30
        return ERROR
if ERROR:
    write port 0x8045=0  #24VDC off ?
    loop endlessly
print "U24DC OK"
...

It will be hard to track those ports to physical signals I guess, FPGA and GALs will hide them inside.
Note one thing: the 27C010 is not the only memory there, the "Un bonjour de HPSmain !" message comes from a code not present in 27C010. After "salto a HPSmain" there is a call to some outside location in RAM which is preloaded via DMA from somewhere. The code mentions some SEEPROM, perhaps HPS is stored there.

[Wiljan]

@abyrvalg, sorry if I  mixed up the log, just had one 20Kb log in Teraterm. Next time I'm at my friend I will try to make new log so it's more clear.

The 8 pin chip between the 80c152 and the long connector IC203  is labeled C46CM6 and is properly a ST93C46CM6 1K 64 x 16 or 128 x 8 SERIAL MICROWIRE EEPROM if needed it could be read out, or sniffed with saleae logic analyser.

If you view the bin in the beginning there are some UK text, like " Press  "Y"  to discard new setup. Writing EEPROM "
This indicate there must be some kind of a setup menu, but I have no idea how to reach it.

Btw the Uart we use now is normal not connected in the machine, the normal operating are done on a industrial PC which will start on a later time in the boot sequence and have the HMI for the CNC.

Can you tell me to which pin on the 80c152 the software does TX?
Then I can look with a scope to see if I get any data while the board are as standalone, and then connect a 5V FTDI to read the boot.

But I think the reset should be set corectly to get the board to run without the main board

[abyrvalg]

The serial port is builtin S0, RxD pin is P3.0 (14),  TxD pin is P3.1 (15).
nRESET is pin 13, try tracking the connection, perhaps it goes straight to some connector to be controlled externally. Note that these old MCUs usually require an external pulse on nRESET, just holding it high may be not enough for start.
For UK-text menu it looks like you need to send 0D (enter) at power on (the menu handler function waits for Enter received for some time, then continues to other code).
The 93C46 is too small to hold any serious code. I suspect the HPS part is loaded over some communication interface (from that main PC?), there are texts about some download.

[Wiljan]

The Reset on the 80C152 (Pin13) is connected to 8 pin ic 7705BC pin 5 which is a reset chip looking on the VDD

https://www.ti.com/lit/ds/symlink/tl7702b.pdf?ts=1622635303781&ref_url=https%253A%252F%252Fwww.google.com%252F

Input 2 on the 7705 are connected to output pin 15 on the GAL16V8 with the red mark ... so it might act like power up sequencer or reset controller,
I don't think it might be good to force output on the GAL to release the 80C152, it might damage the GAL , alternative is to cut a trace and force

Will investigate the 0x0D next time at the main board

[nctnico]

Based on the messages it says there is a problem with the 24V supply. I'd start by tracing that back to some kind of detection circuit and compare with a working board. What can be helpful is to measure resistance on pins. A different resistance can indicate a broken chip.

[abyrvalg]

No, that error says specifically about safety interlock switches (like service access hatch switches to prevent starting the dangerous machinery while someone pokes inside). The reason why it is in 24V supply turn on function is because that's the earliest point where they could poll them I guess (it's quite standard in industrial control to have digital inputs switching between "open circuit" and 24V, so they need 24V turned on to be polled).

[Wiljan]

All switches and security are made by 24V on the base and on the 80C152 board it's only 5V logic

Actually I did find that there exist a PC board (not related with this)
https://www.ebay.com.au/itm/132908068403

I also did find out that the board do the "BITBUS" interface which is defined by Intel way back.

So the 80C152 board looks like a standard submodule, and I might be lucky to find some documentation somewhere

It might even work to buy such a board and change the EPROM ... maybe the EEPROM will be needed to be copied.

I hope to be next to the boards tomorrow.

Regarding that there should be MCU on the base board, there are not, just a lot of PSU stuf and some more TTL io and GAL's

So why the dump write somethin which are not in the EPROM I dont understand right now

[DavidAlfa]

Try guidra. It's very powerful at this.
Tried something like that months ago, but the CPU had adjustable memory mapping, and I didn't find how to do It correctly.
However a fixed memory map mcu should be lot easier.
I've tried with stm32 and PIC, it did pretty nice.

[nctnico]

The more I think about this problem the more I'm convinced there is a failure on the base board. Looking at the software is the wrong way to attack the problem. An easy way to rule out the CPU module is by swapping it between base boards.

Problems in processor modules are very rare because they are far from the I/O lines which receive all kinds of interference. I/O interfaces OTOH get the full load of whatever signals enter a board and are more likely to become damaged.

[Wiljan]

Update:
We have tries to read the other Eprom in the Programmer and it reads straight with out any problem, we also got a fresh burned Eprom and they all seems to work equally.

When we swap between 2 CPU on 1 main board the does NOT boot to same level.

When doing ohm measurement on the connector to gnd on the CPU board's most pins are about 2Mohms on the CPU booting most we have 1 pin only 350 Ohm when the other board (not booting far) does have the 2Mohm ... it would have made more sense the other way around.

We are trying to get hold on 3. CPU board but will sure try to find why we have the difference.

Regarding the main board we have a faulty SMD ULN2803 and have order some, so we cant do any real testing on that board until we get it (should come start next week)

We have seen another problem with the board  booting far ... it comes to where it say you can press the TEST button.
Pressing the Test button some realys will start clicking and check a lot further inputs on the board...
this is fine ....
But sometimes the relay's starts to make noise (sizzling) like a bad connection and now and then the relay does not click anymore ... the 24V are fine and the drive ULN2803 are fine... but they are latched from the databus send over the connector from the CPU so we have a feeling that there might be a bad connection between the boards, we will look  into that also... it all takes a lot of time and without any schematic it kind of hard.

Here is the log which goes far to the TEST (the board with the 350 ohm pin)

Code: [Select]

Un bonjour de PROM main

test checksum firmware
test application ram
bist OK

Accensione del 24VDC in corso

U24DC OK

Lo stato del 24V mantenuto da batteria e OK

L'accensione del 24VBAT viene effettuato

L'ultimo spegnimento e stato causato dal comando PowerOff
in seguito ad un ACLOW

Bisogna premere sul tasto TEST o mandare il comando Start
per andare nell'applicazione.

salto a HPSmain

Un bonjour de HPSmain !

Retour de Started
verifica della compatibilita tra HW e SW

Programmazione dell'alimentazione del generatore

uscita dallo stato d'emergenza

START_GEN attivato
CABINA aperta
uscita stato d'emergenza tramite il pulsante TEST

Power fail causato da uno stato d'emergenza

ACLOW A
Se il segnale ACLOW rimane attivo, il 24VDC Batt
viene spento al piu tardi dopo 4 minuti

Here is the log which goes short (the board with the 2Mohm pin)

Code: [Select]

Un bonjour de PROM main

test checksum firmware
test application ram
bist OK

Accensione del 24VDC in corso

Intervento di uno degli interruttori di protezione della CNC