I've faced to a problem with a PIC Micro controller.
I have a micro-controller programmed by me long time ago and I lost the relevant source code and the schematic diagrams. Now I need to invert the value of a port. I can do this using some NOT gates but it is a big hassle to do so. or alternatively I will need to write the whole program back.
I don't expect to see the code back in PIC C or MikroC. Having an understandable assembly code would be sufficient.
So do anyone has any experience on a good HEX decompiler that I can use for this purpose? Any comments based on your experience? :)
EDIT : Device PIC 16F84A
Decompilation is unlikely to be a practical solution, and it is even less likely that a tool for your specific compiler and instruction set combination even exists.
Disassembly however is straightforward, though whether you will be able to make sense of the resulting code is a different matter since no comments or symbols are preserved in the HEX file; if you have the original object code it may render the disassembly more readable. There are many PIC disassemblers available, just Google it; I can't direct you at any specific one because there are a number of PIC families with different instruction sets, and you did not specify.
A simple approach to disassembly would be to simply load your HEX file into MPLAB and select View->Disassembly Listing, then right-click the windows and select "Output to File". This output may need some massaging for it to be suitable for input to an assembler.
I know this is an old post, but I have recently encountered a similar problem and didn't find a very complete answer online. I lost my MPLAB X IDE project due to hard drive failure, luckily I had already programmed a device with a working version of the code.
Recover the .hex
Follow the steps below to recover the .hex information from a programmed device:
Use MPLAB X IDE and your PIC programmer (I used PICkit3) to read the .hex file from the programmed device:
Start a new project for your device.
In "Project Properties" select your programmer.
Right click on the project folder and select "Set as Main Project".
Click on the arrow next to the "Read Device Memory Main Project" and select "Read Device Memory to File". Reading device memory to .hex file
Disassemble the .hex
You can view the disassembly in MPLAB X IDE, but you cannot edit or save it (or at least I couldn't figure out how to) and it is very cryptic. I found the easiest, no strings attached, disassembler to be the one packaged with gputils, it is called gpdasm. To download and install, visit the gputils page here:
https://gputils.sourceforge.io/
Now open a command prompt and navigate to the folder where your .hex file is located. Generate an assembly source file from the .hex with the following command:
gpdasm -p p16f84a -csno hexfile.hex > asmfile.dis
With the -c -s -n and -o options, this generates quite a good listing which is very near to being able to be assembled as is. Obviously the variable names and labels cannot be recovered, but at least subroutines are identified which makes things a lot easier. Hope this helps someone in the future.
There is a list of PIC disassemblers at the official PICList technical reference.
Many people never use a stand-alone disassembler, but prefer to use the disassembler inside their favorite PIC simulator.
http://piclist.com/techref/microchip/dissassemblers.htm
http://piclist.com/techref/microchip/simulators.htm
You should be able to load the hex file into the MPLAB IDE and view the assembly code from there as well as run it and step through the code in the simulater if I am not mistaken.
You can also use it to read the code from a device if it is not code protected.
Related
I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.
We're using Greenhills Multi IDE and Greenhills Debug Probe to program and debug our target system (a Coldfire based, bare metal system). Currently I flash the target using the IDE debugger GUI, but I would prefer to use a command line interface to do it.
The documentation is fairly sketchy, and only gives a very simple example. As far as I can tell I should be able to use grun with gflash to do this, but I'm having a hard time figuring out which GUI fields map to which grun options. Anyone with any experience of this?
Basically I need to be able to specify (see image above):
Flash device (this one I've got figured out I think)
Base address
Image file (we use raw images)
Offset in flash
Alternate RAM base
Alternate flash utility
Possibly also alternate MBS script
Any tips, tricks, or pointers to better documentation than the standard GHS one? Would be much appreciated!
Is below screenshot from debugger command reference is of any help? You can use it to download your source on HW. I will be able to share more details is this helps. Or you can share your solution if you had already found it.
I used mpadmin for this purpose.
mpadmin -update <IP-addr_of_your-probe | -usb> firmware.frm
Well my problem stated when i had my vhdl code up and running on my Spartan-3a but needed to send and receive data from it to the pc,
I need my vhdl code , so i went for a microplaze structure , problem is I cant understand how will my vhdl code and microblaze co-exist at the same time because every time i program fpga with SDK it deletes my vhdl off the fpga and vise versa with ISE, I dont want to use custom peripherals except if this is the only solution.
Some people just tell me to just use microblaze hdl files produced by EDK, OK but theny aren't I using an unprogrrammed MicroBlaze???
And do i need to go through all of this just to be able to communicate with my vhdl code through pc(NO I CANT USE R232 since i need a speed of 56Mbit/sec)
So here is what i don't understand:
1-IF you implemented microblaze through hardware(HDL from edk to ISE) , isnt it then an un-proggrammed processor?
2-PEOPLE TELL ME i can let microblaze and my vhdl code see each other through GPIO , again how will i implement GPIO and how to connect it to both microblaze and my vhdl code , and how to program microblaze while it in hardware in this situation.
Please any help , its kinda a mess.
It is not that difficult, but unfortunately Xilinx documentation is not that clear.
What you need to do after you are done with your Microblaze code and you feel comfortable with it, is to create a new project in ISE or the one you already had, then add a new file to the project, but instead of adding a VHDL or Verilog file, you must add the system file from EDK.
After you added your XPS project into ISE, you need to do some manual work in order to make things work for you.
Here are a list of things that needs to be done:
You have to create a UCF file that includes all the constraints from EDK
You have to make sure that you have enough space inside your FPGA for both the EDK and
your own code
Synthesize and implement your design using the project in ISE.
Program your FPGA from the bit file generated by ISE
In order to communicate between the MB and your own code, you can do it in many different ways, the easiest way is to use the GPIO block from your MB, then connect those signals to your own code on your top level wrapper.
You maybe able to find some useful information on the lab document and lab material from the following Xilinx page:
enter linkXilinx EDK interface class description here
Accessing the GPIO is pretty simple, you can use the information on this page to get you started:
Reading DIP Switch with MicroBlaze
You may also find this document and related files very useful, it is not for your board, but it covers the exact same thing you are asking for:
Avnet MB tutorial document
I hope this is clear enough.
Good news, my c64 ist still running after lots of years spending time on my attic..
But what I always wanted to know is:
How can I automatically load & run a program from a floppy disk that is already inserted
when I switch on the c64?
Some auto-running command like load "*",8,1 would be adequate...
Regards
MoC
You write that a command that you type in, like LOAD"*",8,1 would be adequate. Can I assume, then, that the only problem with that particular command is that it only loads, but doesn't automatically run, the program? If so, you have a number of solutions:
If it's a machine language program, then you should type LOAD"<FILENAME>",8,1: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
If it's a BASIC program, type LOAD"<FILENAME>",8: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
It is possible to write a BASIC program such that it automatically runs when you load it with LOAD"<FILENAME>",8,1. To do so, first add the following line to the beginning of your program:
0 POKE770,131:POKE771,164
Then issue the following commands to save the program:
PRINT"{CLR}":POKE770,113:POKE771,168:POKE43,0;POKE44,3:POKE157,0:SAVE"<FILENAME>",8
This is not possible without some custom cartridge.
One way to fix this would be getting the Retro Replay cartridge and hacking your own code for it.
I doubt there is a way to do it; you would need a cartridge which handles this case and I don't think one like that exists.
A better and more suitable solution is EasyFlash actually. Retro Replay is commonly used with its own ROM. Since it is a very useful cartridge by default ROM, I would never flash another ROM to it. Also it is more expensive than EasyFlash if you don't have any of those cartridges.
At the moment, I have Prince Of Persia (!) ROM written to my EasyFlash and when I open my c64, it autoruns just like you asked for.
Not 100% relevant, but C128 can autoboot disks in C128 mode. For example Ultima V (which has musics on C128 but not on C64 or C128 in C64 mode) autoboots.
As for cartridges, I'd recommend 1541 Ultimate 2. It can also run games from module rom images (although Prince of Persia doesn't work for me for some reason, perhaps software issue?), but you also get rather good floppy emulator (which also makes it easier to transfer stuff to real disks), REU, tape interface (if you order it) etc.
If you are working with a ML program, there are several methods. If you aren't worried about ever returning to normal READY prompt without a RESET, you can have a small loader that loads into the stack ($0100-$01FF) The loader would just load the next section of code, then jump to it. It would start at $0102 and needs to be as small as possible. Many times, the next piece to load is only 2 characters, so the file name can be placed at $0100 & $0101. Then all you need to do is set LFS, SETNAM, LOAD, then JMP to it. Fill the rest of the stack area with $01. It is also rather safe to only save $0100-$010d so that the entire program will fit on a single disk block.
One issue with this, is that it clears out past stack entries (so, your program will need to reset the stack pointer back to the top.) If your program tries to do a normal RTS out of itself, random things can occur. If you want to exit the program, you'll need to jmp to the reset vector ($FFFC by default,) to do so.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.