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, I have a strange problem. I am converting an automatic build script in Perl from using direct calls to the Windows OS to invoking a51 with an '@commandfile' format because the invocation line has exceeded 500 characters. What is really weird is that with code that assembles and links with no errors with direct invocation, I am getting a fatal error "CANNOT CREATE FILE" (768) when the assembler tries to generate the object file with the commandfile method. Again, there are no errors with direct invocation. My assembler: A51 MACRO ASSEMBLER V6.02 - SN: K1F4U-60444U COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2000 I am running cmd.exe under Windows XP service pack 1. Thanks, Bob C.
Do you have spaces anywhere in any of your path and/or filenames? uVision takes care of ensuring that path- & filenames are correctly "quoted" to cope with spaces - you need to be sure that your scrip does the same! What is the full text of that error message?
Good questions. Yes, there are spaces in the path, and yes, my script surrounds the entire path name with double-quote characters ("). Here is the complete terminal output after the 'a51 @a51.cif' command is sent: A51 MACRO ASSEMBLER V6.02 - SN: K1F4U-60444U COPYRIGHT KEIL ELEKTRONIK GmbH 1987 - 2000 "C:\fw_tools\c51\bin\a51.exe" "d:\robertc_XXXX_XX_ROM_Includes\Firmware\YYYYY\patch\Tempdir\ZZZZ_abc task idle\asm\idleptch.a51" DB PR("d:\robertc_XXXX_XX_ROM_Includes\Firmware\YYYYY\patch\Tempdir\ZZZZ_abc task idle\lst\idleptch.LST") OJ("d:\robertc_XXXX_XX_ROM_Includes\Firmware\YYYYY\patch\Tempdir\ZZZZ_abc task idle\obj\idleptch.OBJ") SET(PATCHREG=11, QQQQQQQ=1, UUUUUUU=1) INCDIR("d:\robertc_XXXX_XX_ROM_Includes\Firmware\YYYYY\patch\Tempdir\ZZZZ_abc task idle") ;; A51 FATAL ERROR - FILE: "d:\robertc_XXXX_XX_ROM_Includes\Firmware\YYYYY\patch\Tempdir\ZZZZ_abc task idle\obj\idleptch.OBJ" ERROR: CAN'T CREATE FILE A51 TERMINATED. (I have changed some proprietary info, but the spacings are identical). I get this same error if there are NO spaces in the path name, however, when I look in the obj directory the object files have been generated and written to the disk. With this directory, the obj directory really is empty and the error is real. So at first glance this looks like a timing issue.
This are really old tool versions. You should consider to upgrade to the current versions. Are you sure that the folder for the OBJ file exists on your computer? Reinhard
Two observations: 1) That batch file could be a heck of a lot less wordy if you cd'ed into the directory this all takes place in, first... 2) ERROR: CAN'T CREATE FILE [...] however, when I look in the obj directory the object files have been generated and written to the disk And you're sure those are actually newly generated files, as opposed to old versions of the same files which somehow got write-protected? As to the path names themselves: the problem may not actually be the blanks, but the sheer length of these names. There are some length limitations on path names which these names may already have blown.
Thanks for the responses, Reinhard, I would if I could, have to use what the company provides Hans, Yesterday I implemented your point 1), which fixes the immediate problem. The path names are getting very large, so this is probably the right fix. What I really wanted was confirmation that I was up against a brick wall (e.g. that version of the assembler is using non-blocking I/O and/or missing callbacks) so that I didn't waste time trying to solve the insolvable. As to point 2), yes, as part of my test I removed the entire directory tree to make sure. Again thanks for the responses.
"As to the path names themselves: the problem may not actually be the blanks, but the sheer length of these names." Especially when using such very old tools! Path-length limits were, unfortunately, common in the "good" (sic) old days of MS-DOS...
I remember a version (what was it??) where the commandline invoking the linker was too long and caused all kinds of "funny stuff" Erik