Very special compile error.... software bug

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I go to a university where many students use Atmel Studio 7.0 and i have heard of many people having this problem. It is not too serious of a problem but I am curious how to fix it. I have only ever made a C executable project so i'm unaware if this occurs in other types but here it is:

 

Every time i make a change in my project files and compile or build, I get the same exact error "recipe for target 'project'.elf has failed". Then i have to compile or build once more, and it compiles / builds without fail. I can even make  change in a comment or delete one character that doesn't affect the output, and the error comes back until i build for the second time. I have a feeling that it's because i'm running atmel studio on a mac via Parallels, but I was wondering if anyone has any ideas of why this is. It seems apparent that this is a bug but maybe there is a fix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> recipe for target 'project'.elf has failed
 
This has absolutely nothing to do with the compiler. It's a problem with your builr environment, e.g. a flaw in your Makefile (input of GNU make).

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ltimber wrote:
i have to compile or build once more, and it compiles / builds without fail.

sounds like something was not "cleaned-up" properly the first time.

 

Have you shown this to your teachers?

It will be far easier for them to help you when they can sit at your computer and see exactly what you are doing, and exactly what you have on your computer, and exactly what is happening.

 

It is vastly more difficult to debug remotely - especially for complete strangers. You will need to supply a whole lot more detail...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

"recipe failed" simply means there was a build error. If I write:

#include <avr/io.h>

int main(void) {
    // no closing brace

then I might expect to see the same. This is not a valid C program and will cause an error.

 

The point about AS7 (and the Visual Studio on which it is based in general) is that it can be very poor at showing the reason for build errors. Often the infamous "Error List" will report something like this "recipe failed" thing (which as SprinterSB says comes from make, not from the compiler) but only when you switch to the "Output" tab and read through the complete output of the compiler will you see the real reason for the failure.

 

So when you have seen "recipe failed" what has the complete build output tab actually said?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm guessing that an external make file is involved.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think you guys understand. It has nothing to do with what my code contains. I've made many many projects and every time I compile, i have to do it twice.

 

Also @awneil I dont understand what you mean that you dont think something was not "cleaned-up" properly the first time. And what do you mean debugging for complete strangers?

 

​The bottom line is that i have provided all of the detail possible. The problem guaranteed has nothing to do with what i'm doing wrong / right, this is a BUG

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ltimber wrote:
​The bottom line is that i have provided all of the detail possible.

No you haven't.  Is this for an AVR, Xmega, SAM? Which device?  Are you using ASF, or GCC?

 

ltimber wrote:
The problem guaranteed has nothing to do with what i'm doing wrong / right, this is a BUG

 

As suggested show us the build output.  

 

AS Cliff has explained, Visual Studio does not give a very good explanation with the "recipe failed".  THe Build Output window does give an accurate reason for what the problem is.

 

 

Jim

 

EDIT:

Recent thread with the same error:

 

https://www.avrfreaks.net/forum/t...

 

In that thread the cause for the error was a simple boo boo.  Just as we suspect here. smiley

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Wed. Feb 28, 2018 - 02:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ltimber wrote:
 i have provided all of the detail possible

No, you haven't.

 

Specifically, you haven't provided the full build output - as requested in #4.

 

Also, #5 suggested that an external makefile may be involved.

You haven't confirmed whether that is or is not the case

 

 

Also @awneil I dont understand what you mean that you dont think something was not "cleaned-up" properly

When you build a project, the first thing it does is to delete the stuff from previous builds that's no longer required.

 

That's what I mean by "cleaning-up"

 

 

And what do you mean debugging for complete strangers?

You don't actually know anyone here, do you?

And we don't know you - so we are all "complete strangers"

 

We know nothing about you; we know nothing about your project; we know nothing about the computer (or computers?) you are using; we know nothing about how you have your computer(s) configured; we know nothing about what else may or may not be installed on your computer(s); we cannot see what you are actually doing when you get this message; we cannot see what is actually happening on your computer at the time; we cannot see what is appearing in the 'Output' window; etc; etc; etc

 

All of this makes it very much more difficult for us - as complete strangers, far away - to debug your problem.

 

But none of this applies to your teachers: they do know you; they do know about your project; they do know the computer (or computers?) you are using; they can see how you have your computer(s) configured; they can see what else may or may not be installed on your computer(s); they can see what you are actually doing when you get this message; they can see what is actually happening on your computer at the time; they can see what is appearing in the 'Output' window; etc; etc; etc

 

So, really, your teachers are best placed to help you with this.

 

The problem guaranteed has nothing to do with what i'm doing wrong / right

Almost certainly it does.

 

 

 this is a BUG

http://www.catb.org/~esr/faqs/smart-questions.html#idm46060474146768

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

ltimber wrote:
this is a BUG
yes, almost certainly a BUG in the code you have written. But until you post the build output so we can see what the compiler is complaining about no one here can help you locate what you have done wrong.

 

EDIT: just this week there was this:

 

https://www.avrfreaks.net/comment...

 

That illustrates how deficient the AS7 Error List actually is. In that case it completely failed to report the actual error even though the build output that the OP posted made it clear exactly what was wrong.

Last Edited: Wed. Feb 28, 2018 - 09:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
almost certainly a BUG in the code you have written.

 

and/or in the makefile you have written - if, indeed, it is an external makefile.

See #5.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get that when I have something stupid like a missing } in a code file. I read it as "you screwed THAT up, dummy."

 

Give us an example program that produces the error.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An important question has been raised, here, and the OP has been dancing around it, a bit.

 

Since this seems to be a relatively common occurrence at that site (university lab) and NOT common elsewhere, there is likely to be some common factor unique to this site. One of the factors common to universities are massive on-line storage systems. Another possibility is that the instructor(s) have set up a makefile for use in the class and that makefile is faulty. 

 

But, as awneil noted in message #8, nobody here can diagnose any of that WITHOUT A COPY OF THE BUILD OUTPUT. Not the error list, but the actual build output (as noted in message #9). You need not be defensive about all this. Instructors DO screw up (been there, done that). There may be something about PATH definitions for this class lab. Any number of things are possible. There ARE folks here who are much more knowledgable about such things than the Average Bear.

 

So, help us help you. A complete build output would go a long ways!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Mar 3, 2018 - 05:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I would suggest everyone stop posting until the OP comes back and replies...if the OP ever does. No sense in repeating the obvious over and over.

East Coast Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK.  I am having the same problem.

 

If I make any change, even as simple as type a space and backspace to remove it.  Press the "Stop Debugging" Button, Press the "Start Debugging" button, Get the error messagebox: "There were build errors.  Would you like to continue and run the last successful build?" Select the "No" Button, Press the "Start Debugging" Button and it runs just fine.  The only error shown is "recipe for target 'MyProject.elf' failed".

 

What information do you need to troubleshoot this?

 

More information:  I am a professional embedded system engineer and have used lots of different development systems all the way back and before the Motorola EXORciser !  I used AS7 about a year ago with this same issue on a different computer.  This is now a clean install of a new computer and I have used all defaults and created nothing more than some simple C code with no custom anything.  No makefiles created by me.  My expectation is to press the "Start Debugging" button once and it should compile if necessary, download, and then run the code.

 

I would like to resolve this and help out.  Please let me know what you need.

Last Edited: Tue. Aug 6, 2019 - 03:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

What chip are you using? Aand I am guessing you are using one of the Atmel debuggers since you are using the Stop debugging, and start debugging unless you are using the simulator maybe?

 

A fw years aso I was doing some in circuit debugging and I received an error from the Start debugging button  Could not figure it out, then a Freak said I should try cleaning the project, and then hit F7 to build it.  If I do not get any errors THEN click Start Debugging.  I followed their advice and after cleaning the project and hitting F7 the compiler spit out an error.  It took me a few minutes to fix the issue, but it would then build without errors.  I then hit Start Debugging and it all worked fine.  I have been following the BUILD FIRST and see if anything spits up BEFORE clicking Start Debugging and it has served me well.

 

Now keep in mind I do everything inside AS7.  I do not have external makefiles and such...never understood them entirely, but thats another thread of discussion. 

 

Follow the Clean Project, then Build project.  If you get an error post it here so we can figure it out.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chip: 328PB

 

Tried Clean and then Build.  Build always fails once and then run works.  The net change is now a little bit worse since I now have to click two buttons instead of one button twice.

 

Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PeterHouse wrote:
Build always fails once and then run works. 

 

ok, then:

jgmdesign wrote:
If you get an error post it here so we can figure it out.

 

so, c'mon!  POST IT!  smiley

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can it be the simple problem that you are editting the code while you are in a debug session?

 

what happens if you first stop the debug session before you make changes to the project?

 

I would expect the debug session to lock the elf file and thus the compiler/linker cannot edit it and throws an error.

At the same time the new compile run ends with the debug session being halted and then the second time around the file is released and thus can be updated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign: here is a screen shot of the error message I get.  Where is there more information?

 

meslomp: That is exactly what I am doing - editing while the code is running.  If I Stop Debugging and then edit the code I get the same results - first compile fails and second runs.

 

Screen Shot of AS7 Compile Failure

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "error list" is of no use in determining why a build failed (in fact I never really understood why Microsoft bother!) It's the "output" tab that would be more informative about what is failing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the "Output" Tab:

 

Make Minor Code Change of Space followed by backspace.

Press "Start Debugging" Button.

Click on "OK" button to clear Error MessageBox.

Contents of "Output" Tab:

 

------ Build started: Project: Universal, Configuration: Debug AVR ------
Build started.
Project "Universal.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Universal.cproj" (target "Build" depends on it):
    Task "RunCompilerTask"
        Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
        C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 8 --output-sync
        Building file: .././main.c
        Invoking: AVR/GNU C Compiler : 5.4.0
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\include"  -O0 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega328pb -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\gcc\dev\atmega328pb" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c"
        Finished building: .././main.c
        Building target: Universal.elf
        Invoking: AVR/GNU Linker : 5.4.0
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o Universal.elf  ANA.o CT.o IO.o main.o   -Wl,-Map="Universal.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega328pb -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\gcc\dev\atmega328pb"  
        Finished building target: Universal.elf
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "Universal.elf" "Universal.hex"
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "Universal.elf" "Universal.eep" || exit 0
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe: 'Universal.elf': No such file
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        Access is denied.
        make: *** [Universal.elf] Error 1
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "Universal.elf" > "Universal.lss"
\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug\Makefile(142,1): error: recipe for target 'Universal.elf' failed
    Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "Universal.cproj" -- FAILED.
Done building project "Universal.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

Click on "Start Debugging" Button.

Contents of "Output" Tab:

 

------ Build started: Project: Universal, Configuration: Debug AVR ------
Build started.
Project "Universal.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Universal.cproj" (target "Build" depends on it):
    Task "RunCompilerTask"
        Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
        C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 8 --output-sync
        make: Nothing to be done for 'all'.
    Done executing task "RunCompilerTask".
    Task "RunOutputFileVerifyTask"
                Program Memory Usage     :    1130 bytes   3.4 % Full
                Data Memory Usage         :    0 bytes   0.0 % Full
    Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "Universal.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Universal.cproj" (entry point):
Done building target "Build" in project "Universal.cproj".
Done building project "Universal.cproj".

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Are the project files stored on a network drive?  If yes, then it's possible that when Studio tries to do the build the connection is not there, and on the first(failed) attempt it wakes up the connection, and it then passes on the second try.

 

If you do have everything on a network connection try copying the directory to the local machine and reload the project and see what happens

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Absolutely NOT a windoze person but a couple of things jump out at me:

 

Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
        C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 8 --output-sync
        Building file: .././main.c
        Invoking: AVR/GNU C Compiler : 5.4.0
        '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.

That suggests that things are NOT happening where they were specified to happen. Then, later comes

   C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe: 'Universal.elf': No such file

Something serious is happening, here. And, what appears to be the final nail:

  '\\volt\d$\Project\Signal Dynamics\Universal\Code\Universal\Universal\Debug'
        CMD.EXE was started with the above path as the current directory.
        UNC paths are not supported.  Defaulting to Windows directory.
        Access is denied.

Seems to me that you have several problems. Let the system debugging begin! Microsoft has this to say about "UNC Paths" (complete with some solutions):

 

https://social.technet.microsoft...

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. Aug 7, 2019 - 08:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might be able to use "net use N: \\net\path" to make the UNC path look like a DOS path that the program could then find/use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure this issue is related to the DOS/Linux command line tools and their inability to accept UNC path names as current directories.  I know this is not a Visual Studio issue since VS has supported UNC names for a long time now.

 

What is confusing is why and how does it work the second time I give it the same command.  I have searched my system for a local cached copy with no luck.

 

Shirley (sic) there must be a way to just tell the tools to do it the second way first!!!

 

Are there any Atmel Studio developers lurking???

 

I am still willing to spend time resolving this issue even though the payback point has long passed.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not try moving your project to your local machine where Studio lives and try doing the build?  If it works on the first shot, as well as the Start Debugging  command then you know it's network drive related.

 

Go back to your original configuration and BEFORE you build do a little peek at windows explorer and see if the map drives have an X on them.  Run the build and see if it fails, then do it again and see if it passes then check windows explorer to see if the map is restored.  That will answer the issue.

 

I would have to look, but I think you can tell windows to keep a map drive connected in the power options.....

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim,

 

Every file I use is on a shared network drive.  The drive is 100% available and is not going away.

 

I will try mapping it to a drive letter just for the sake of knowing and I am pretty sure at this point it will work.

 

The problem is: A mapped drive letter is a work-around - the underlying problem needs to be resolved.  The compile ALWAYS works the second time - Why?

 

Thank you,

 

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There may be some latency in your network that Studio does not like?  It's sort of what I was mentioning in post #22. 

 

PeterHouse wrote:

Every file I use is on a shared network drive.  The drive is 100% available and is not going away.

 

Ok, fair enough, but does this issue you are having happen with every AVR project, or just this one?  If just this one, then I'll agree that there may be something else at play.  I have a local folder for my projects, and sync this folder to my NAS just so I don't have to deal with any possible network issues.  I suppose your company may have a policy that all data needs to be stored on a server but hey, just try saving the whole project to your local drive and see if the problem goes away....simple test.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does the build output compare on the 2nd time - does it still show UNC warnings (in which case that's probably just a red herring) ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CLawson,

 

No warning on 2nd Build - it just works and even shows the UNC path without complaint.

 

Both Build outputs can be found in this message: Message #21