This is a repeat of previous post corrected for 8051 toolset. I can no longer use uv3 to generate an "HLL" (High Level Language) type file to run in a Metalink XF 8051 emulator. I must use "mixed" or "code" listings in the XF. The XF says "No source files available" after loading the executable. This feature has worked reliably for several months after initially failing & then magically curing itself. This latest anomaly began after I "saved as" one of the 4 source files in the project group in uV3. Also, the BL-51 linker sometimes generates an executable file of the type "Adobe Download Manager" which the emulator can usually identify and load. Other times there appears to be no target file created even as the linker says it has built the target. I am running this software under Windows XP. Is there some fundamental incompatibility with this OS & uV3? I also have difficulty in setting up "books" files in the IDE. It seems unable to find them even though their paths appear correct. This situation is extremely frustrating and disappointing. I ran the original Intel ASM-51 dpendably for 21 years until the platform on which it ran became totally unsupportable.
We did not change anything on the output format of the C51 Version 8 compiler. Therefore I recommend that you contact MetaLINK and send them an linker output file that you cannot correctly load. You can modify/correct the book paths using the dialog Project - Components, Enviornment, and Books, Books. http://www.keil.com/support/man/docs/uv3/uv3_dg_prjbooks.htm
It's not the compiler that I am using but the A51 assembler & BL51 linker.
Continuing... Is the "Adobe Download Manager" the correct type of file as the executable? The linker does not always generate this file.
Again, we did no change any output format with the Assembler. So you should still contact MetaLINK and ask if you are using current software for the emulator. The Linker output file has by default no extension (some people give *.ABS. It does not relate to Adobe products at all.
"Is the 'Adobe Download Manager' the correct type of file" This is just a name that your Windows Explorer has associated with the File type; you need to check the actual extension in the filename; eg, .abs, .obj, etc... In Windows Explorer, You should go to 'Folder Options', then the 'View' tab, then ensure that 'Hide extensions for known file types' is not checked.
"I can no longer use uv3 to generate an 'HLL' (High Level Language) type file to run in a Metalink XF 8051 emulator." "It's not the compiler that I am using but the A51 assembler" But assembler is not a high-level language!
Of course it's not but the Metalink emulator can load & display the relocateable assembler source code as written in the Keil A-51. This "HLL" format is easiest to use for initial emulation. Now,when queried, the Metalink says "No source code available" even though it can be viewed in "mixed mode" which is a combination of source code & assembled code. It should also be available alone in HLL without the assembled code & it has been for the last 4 months of frequent emulator use. It stopped appearing after I tried to "save as" a source file from uV3. My copy of uV3 exhibits many anomalies in writing & accessing Windows XP files. Anyone else experiencing this?
We are not aware of any generic problems with Windows XP. Please contact support to make sure that the installation is correct.
It seems you are talking about a new installation and one guess would be that the sources are not avilable because after your installation some specification go replaced by a default or some other changes. Thia could result in the Metalink looking for lov.. sources in all the wrong places. Erik
Avoid spaces in path and file names!
Good idea about spaces causing the problem. The tool is obviously looking for the source files somewhere. If you knew where, you could possibility identify why it was not finding them in the correct location. For example, 'executable' or 'absolute' files which contain relative paths to source files sometimes cause troubles for debugger tools. Spaces in the filenames can also confuse them as Andy said. To figure out where the tool is looking for the files, take a look at the Filemon utility over on the SysInternals site. Maybe you can draw some conclusions from the information that this tool will give you. http://www.sysinternals.com/Utilities/Filemon.html Good luck.
There are no spaces in any of my file names. The emulator uses the absolute product of the BL-51 linker which should contain the source code when the "debug" selection is chosen in the assembler menu. This selection is in effect, at least the box is checked. The source code was available for several months on a reliable basis. Now the configuration window in the emulator reads "No source available" for each of the linked modules comprising the absoulute executable module. The "mixed mode" selection does work & displays symbols along with disassembled code. However some operands containing symbolic expressions are not displayed as original source code but as numerical result of the expressions. I need the full symbolic display NOW! Can anyone refer me to a reliable basic relocatable assembler that can handle classic 8051 as well as Atmel 89C51ED2?
Are you sure that this is a problem of the Keil Assembler? Did you load it into the uVision simulator. Does this work OK?
"There are no spaces in any of my file names." It's not just file names - ensure that there are no spaces anywhere in the path (ie, including folder names; eg, "My Documents", or "Program Files") "the absolute product of the BL-51 linker which should contain the source code" No, it doesn't actually contain the source code; what it contains is references to the source code. I'm not sure if these would be absolute (fully-qualified paths) or relative... "Can anyone refer me to a reliable basic relocatable assembler that can handle classic 8051 as well as Atmel 89C51ED2?" The instruction set is the same; therefore any assembler should do - that's the beauty of the 8051 "family". But what makes you so sure that it's the assembler that's at fault? How are you sure that it's not the Linker, the debugger, or something else? As Reinhard says, have you tried this with the uVision simulator and/or debugger? If it works with uVision, this must indicate that the build tools (Assembler, Linker, etc) are working correctly; so you need to look at the 3rd-party stuff... "The source code was available for several months on a reliable basis" Do you have backups of this. so you can go back and see what's changed?