Disassemble bin file for 80c152 - Page 1
Forum section: electronics / general

author: Wiljan
author_rank: Regular Contributor
timestamp: June 01, 2021, 02:47:51 pm
content: 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 EPROMI tried to disassemble in the DIS8051 but it fails, hope someone in here does have a better dissembler.I have attached the dump

author: lapi
author_rank: Contributor
timestamp: June 01, 2021, 06:04:56 pm
content: Once upon a time... I reverse engineered the FW of a scanner. I used thishttp://plit.de/asem-51/dis51.htmldisassembler. 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 functionL0007: ;; Wait DMA to be freeMOV A, 93hANL A, #2hJNZ L0012SJMP L0007L0012: ;; Configure DMA channel 1;; Set source addressMOV A, 53hMOV 0B2h, AMOV A, 52hMOV 0B3h, A;, Set destination adderessMOV A, 55hMOV 0D2h, AMOV A, 54hMOV 0D3h, A;; Set lengthMOV A, 57hMOV 0F2h, AMOV A, 56hMOV 0F3h, A;; Start DMA (do increment destination and source addresses + go)MOV 93h, #51hL0014: ;; Wait for DMA to completeMOV A, 93hANL A, #2hJNZ L0013SJMP L0014L0013:RETWhich appears to do a DMA transfer. The contents of the high part (27c010_3941-2.asm) requiresmore thought. To start with, the call to the end of the address space (L0003) requires someexplanation, that someone else might be able to find.Anyway, happy reversing!

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2021, 06:50:45 pm
content: 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.

author: Wiljan
author_rank: Regular Contributor
timestamp: June 01, 2021, 07:51:02 pm
content: @ lapi than you for disassemble the binVery 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 5VSo 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 messageDifferent 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 powercycleIf 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

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2021, 08:24:31 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 01, 2021, 11:23:49 pm
content: 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.

author: Wiljan
author_rank: Regular Contributor
timestamp: June 02, 2021, 07:58:40 am
content: @ 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 understandingSo the CNC machine is a BIG one and not in my workshop, I try to help a friendThe CNC does have a huge electric rack with a lot of units inOne 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 itCode://-------Log from a MCU not working correct--------Un bonjour de PROM maintest checksum firmwaretest application rambist OKAccensione del 24VDC in corsoIntervento 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 futherUn bonjour de PROM maintest checksum firmwaretest application rambist OKAccensione del 24VDC in corsoIntervento 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 maintest checksum firmwaretest application rambist OKAccensione del 24VDC in corsoU24DC OKLo stato del 24V mantenuto da batteria e OKL'accensione del 24VBAT viene effettuatoL'ultimo spegnimento e stato causato dal comando PowerOffin seguito ad un ACLOWBisogna premere sul tasto TEST o mandare il comando Startper andare nell'applicazione.salto a HPSmainUn bonjour de HPSmain !Retour de Startedverifica della compatibilita tra HW e SWProgrammazione dell'alimentazione del generatoreuscita dallo stato d'emergenzaPower fail causato da uno stato d'emergenzauscita stato d'emergenza tramite il pulsante TESTPower fail causato da uno stato d'emergenzaOnly 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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 02, 2021, 11:04:01 am
content: 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:#power up 24VDC busprint "Accensione del 24VDC in corso"write port 0x8045=1 #this must be the 24VDC on/off bitwrite port 0x8048=0x90 #some status indicator I guess, different values are written to this port on errors#call test 24VDC busif port 0x8041.0==0: # the main "U24DC OK" conditionreturn OKif port 0x8042.6==0:print "Driver del bus di controllo delle potenze in cond. FAULT1" # 24VDC driver faultwrite port 0x8048=0x3B #status port again?return ERRORif port 0x8043.3==0:print "Intervento di uno degli interruttori di protezione della CNC" # safety switches are wrongwrite port 0x8048=0x44 #statusreturn ERRORelse:print "Il 24V principale fuori toleranza" # 24VDC is out of rangewrite port 0x8048=0x30return ERRORif ERROR:write port 0x8045=0 #24VDC off ?loop endlesslyprint "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.

author: Wiljan
author_rank: Regular Contributor
timestamp: June 02, 2021, 12:00:38 pm
content: @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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 02, 2021, 01:04:39 pm
content: 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.

author: Wiljan
author_rank: Regular Contributor
timestamp: June 02, 2021, 01:43:53 pm
content: The Reset on the 80C152 (Pin13) is connected to 8 pin ic 7705BC pin 5 which is a reset chip looking on the VDDhttps://www.ti.com/lit/ds/symlink/tl7702b.pdf?ts=1622635303781&ref_url=https%253A%252F%252Fwww.google.com%252FInput 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 forceWill investigate the 0x0D next time at the main board

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2021, 03:59:16 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 03, 2021, 08:59:39 am
content: 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).

author: Wiljan
author_rank: Regular Contributor
timestamp: June 03, 2021, 10:24:35 am
content: All switches and security are made by 24V on the base and on the 80C152 board it's only 5V logicActually I did find that there exist a PC board (not related with this)https://www.ebay.com.au/itm/132908068403I 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 somewhereIt 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'sSo why the dump write somethin which are not in the EPROM I dont understand right now

author: DavidAlfa
author_rank: Super Contributor
timestamp: June 03, 2021, 12:43:42 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: June 04, 2021, 04:17:53 pm
content: 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.

author: Wiljan
author_rank: Regular Contributor
timestamp: June 04, 2021, 08:32:10 pm
content: 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:Un bonjour de PROM maintest checksum firmwaretest application rambist OKAccensione del 24VDC in corsoU24DC OKLo stato del 24V mantenuto da batteria e OKL'accensione del 24VBAT viene effettuatoL'ultimo spegnimento e stato causato dal comando PowerOffin seguito ad un ACLOWBisogna premere sul tasto TEST o mandare il comando Startper andare nell'applicazione.salto a HPSmainUn bonjour de HPSmain !Retour de Startedverifica della compatibilita tra HW e SWProgrammazione dell'alimentazione del generatoreuscita dallo stato d'emergenzaSTART_GEN attivatoCABINA apertauscita stato d'emergenza tramite il pulsante TESTPower fail causato da uno stato d'emergenzaACLOW ASe il segnale ACLOW rimane attivo, il 24VDC Battviene spento al piu tardi dopo 4 minutiHere is the log which goes short (the board with the 2Mohm pin)Code:Un bonjour de PROM maintest checksum firmwaretest application rambist OKAccensione del 24VDC in corsoIntervento di uno degli interruttori di protezione della CNC