We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, As we know the Keil C can generate the .SRC file for each .C file in a project, but without combining them. I need to combine all the .SRC files into one, just like what we saw in the "Deassembly" window while we are executing debugging. Anyone can help on this?
Thanks!!
John
Still impossible to know what you are attempting to do - get around the code size limitation of the evaluation version of the compiler?
The tools have way better methods for filling that flash with the machine code data - absolutely no reason to involve any .SRC files.
And a working debugger should be able to use the debugging information to translate between addresses in the processor memory and corresponding source code - that translation + description of data types is basically the goal with the debugging information.
We are developing a 8051 MCU, and we use the compiled .hex file as the test pattern to simulate our Verilog code. But we are facing a problem, if some error occurs, we can only know the code address which is being executed currently. We also want to know the original C and ASM code that causes this problem. One way to have this information is to open the "Deassembly" debugger window every time we are debugging, or we can copy the content of that window shows. However, it is inconvenient. Therefore, I am wondering is there any method can generate the file I want automatically?
Yes, the command line command "COPY" can do that.
Did you take a look at it after I suggested it the first time? It really can take multiple input files and produce a single output file.
Thanks! What I am doing currently is, select all the content shown in the "Deassembly" window, then "COPY" them to a new file. But I think it's inconvenient. I am trying to find an "automatic" way on this.
If you are going to repeat that quote, then maybe consider deassembly -> disassembly.
So why do you not think COPY can represent an automatic way to do it? You are aware that you can add custom build steps for the project?
Sorry for my fault, what I am doing is copying "disassembly" not "deassembly". Copying the entire content of the "disassembly" window requires scroll down the cursor and select all the lines, since there is not a "select all" option. Since I am lazy, I fell it's inconvenient :) If "copy" is the only way to do what I want, it's ok for me. Thanks for your help!!
COPY is a command available from the command line in Windows.
If you have multiple *.src files, then COPY can be used to concatenate the contents of them into a single file. But COPY can't be used for copy/pasting data from a window in the IDE.
You're developing an 8051 in HDL, and you can't write or find a disassembler? Seems like a validation step missing there somewhere.
Hi Per, But I need the separate .SRC files be combined as the sequence they will be executed. Maybe I can say, I need to "link" the separate files.
Hi Westonnsupermare, We are not good at the compiler tools, therefore, we thought Keil is a very good tool that helps. Could you suggest some disassembler tools?
We also want to know the original C and ASM code that causes this problem.
Your belief that the .src files are a suitable starting point to reach that goal is a classic case of jumping to conclusions. What you're searching for are absolute-address list files made by the linker. Compiler output can't help you because the compiler has no control over where in the final program the pieces of an individual source code module go. The linker controls that. And if you had spent some time investigating the capabilities of your tools before jumping to your conclusion, you would have found out how get the linker to get you the kind of listing you want.
But that's all beside the point, because what you really need is a way to connect a debugger to the 8051 core inside your FPGA. Any other approach is a huge waste of time that could only possibly be justified if you're absolutely certain that a debugger can't be made to work.
As long as you have the linker link complete object files after each other and not have the linker cut/paste individual functions and move them around in the memory space (i.e. so each *.SRC file contains a continuous memory sequence) then it's enough to supply the *.SRC files in the same order as the linker links them to the COPY command. And voila - COPY will be able to merge them in the same order as you supplied them.
Notice that the linker do care about the order of source files in the project, when it comes to processing the object files into a binary...