Nach Neuinstallation Microchip Studio funktioniert "Build" nicht mehr.

[Daniel B. (daniel10)]

Hallo.
Ich habe ein Problem, wo ich selber nicht mehr weiter weiß.
Ich habe meinen Rechner formatiert und auf Windows 11 geupdatet und auch 
sonst alle veralteten Programme gegen deren Nachfolger ersetzt.
Nun wollte ich nach langem wieder einmal eine kleine Software schreiben, 
und nun geht das nicht mehr...
Ich habe Studio auf Partition D installiert, wie es vorher auch war.

Der Testweise ASM-Code ist der direkt nach erscheinen der 
Programmierseite:
start:
inc r16
rjmp start

Nun taucht folgende Fehlermeldung auf, nachdem ich auf "Build" klicke:

------ Build started: Project: Ventilator_Steuerung, Configuration: 
Debug AVR ------
Build started.
Project "Ventilator_Steuerung.asmproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; 
('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "D:\Microchip Studio for AVR and 
SAM\7.0\Vs\Assembler.targets" from project 
"E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\Ventilator_Steuerung.a 
smproj"  (target "Build" depends on it):
  Using "RunAssemblerTask" task from assembly "D:\Microchip Studio for 
AVR and SAM\7.0\Extensions\Application\AvrAssembler.dll".
  Task "RunAssemblerTask"
    D:\Microchip Studio for AVR and 
SAM\7.0\toolchain\avr8\avrassembler\avrasm2.exe -fI -o 
"Ventilator_Steuerung.hex"  -m "Ventilator_Steuerung.map"  -l 
"Ventilator_Steuerung.lss"  -S "Ventilator_Steuerung.tmp"  -W+ie 
-I"D:/Microchip Studio for AVR and 
SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc\" -I"D:/Microchip 
Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\include\" 
-I"D:/Microchip Studio for AVR and 
SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc"  -im168def.inc -d 
"E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\Debug\Ventilator_Steue 
rung.obj"   "E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\main.asm" 
-I "D:\Microchip Studio for AVR and 
SAM\7.0\toolchain\avr8\avrassembler\Include"
    AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)
    usage: avrasm2.exe [options] file.asm
    Type 'avrasm2 -h' for help.
    Copyright (C) 1995-2020 ATMEL Corporation
  Done executing task "RunAssemblerTask" -- FAILED.
Done building target "CoreBuild" in project 
"Ventilator_Steuerung.asmproj" -- FAILED.
Done building project "Ventilator_Steuerung.asmproj" -- FAILED.

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

Es ist dabei egal, ob ich Leerzeichen im Dateipfad habe oder diese gegen 
"_" ersetze, ich bekomme keinen Build hin...

Öffne ich nun ein bereits existierendendes Projekt, kann ich dieses 
Problemlos builden. Nur wenn ich eion komplett neues Projekt erstelle, 
geht garnichts.

Würde mich echt über Hilfe freuen. Liebe Grüße, Daniel

[Wastl (hartundweichware)]

Daniel B. schrieb:
> Würde mich echt über Hilfe freuen.

Poste dein komplettes Projekt welches nicht compilierbar
ist, als *.zip File. Vor dem Zippen noch ein "Clean".

[Daniel B. (daniel10)]

So ungefähr?
Wie schon gesagt, ist in den Projekt nichts drin, kann ja eh nicht 
gescheit Builden...
Grüße Daniel

[Wastl (hartundweichware)]

Daniel B. schrieb:
> So ungefähr?

Wie was?

Daniel B. schrieb:
> ist in den Projekt nichts drin

Im Projekt stecken jede Menge Einstellungen drin die das
Verhalten beim Build bestimmen.

[Daniel B. (daniel10)]

Wastl schrieb:
> Wie was?

Hab das Projekt in meiner ersten Frage angehängt

[Harald K. (kirnbichler)]

Abgesehen davon, daß der Installationsort ausgesprochen ungeschickt 
benannt ist -- "D:\Microchip Studio for AVR and SAM",

ist das hier der Aufruf des Assemblers, wie er dem Log zu entnehmen ist,
jedes Kommandozeilenargument auf einer neuen Zeile:

D:\Microchip Studio for AVR and SAM\7.0\toolchain\avr8\avrassembler\avrasm2.exe 
-fI 
-o
"Ventilator_Steuerung.hex"  
-m 
"Ventilator_Steuerung.map"  
-l
"Ventilator_Steuerung.lss"  
-S 
"Ventilator_Steuerung.tmp"  
-W+ie
-I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc\" 
-I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\include\"
-I"D:/Microchip Studio for AVR and SAM\7.0\Packs\Atmel\ATmega_DFP\2.4.522\avrasm\inc"  
-im168def.inc 
-d
"E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\Debug\Ventilator_Steuerung.obj"   
"E:\AVR_ASM_Projekte_06.2026\Ventilator_Steuerung\main.asm"
-I 
"D:\Microchip Studio for AVR and SAM\7.0\toolchain\avr8\avrassembler\Include"

Und damit ist der Assembler unglücklich, der will so nicht aufgerufen 
werden:

>     AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)
>     usage: avrasm2.exe [options] file.asm
>     Type 'avrasm2 -h' for help.
>     Copyright (C) 1995-2020 ATMEL Corporation

Was auffällt:

Bei drei -I-Optionen fehlt das Leerzeichen zwischen -I und dem Pfad, 
ebenso bei -i
(es geht also um die Zeilen 12 - 15)

Das erste Pfadtrennzeichen ist bei den drei -I-Optionen ohne Leerzeichen 
auch anders, als unter Windows üblich.
Ein Fehler muss das nicht sein, manche Software kommt mit / statt \ 
zurecht, aber es könnte helfen, das zu vereinheitlichen.

[Moby A. (mobynew)]

Hab mich mal angemeldet um Dich von diesem nervigen Problem zu erlösen: 
Mit der Studio-Installation ist alles in Ordnung, nicht aber mit dem 
verwendeten Device-Pack: Alles kleiner 2.3 ist nämlich verwendbar :)

[Ob S. (Firma: 1984now) (observer)]

Daniel B. schrieb:
> Wastl schrieb:
>> Wie was?
>
> Hab das Projekt in meiner ersten Frage angehängt

Also, das funktioniert bei mir ebenfalls nicht.

...und ein testweise von mir erzeugtes neues Asm-Projekt auch nicht.

Das Problem besteht ja darin, dass sich der avrasm2.exe über die 
übergebenen Parameter beschwert, allerdings ohne in's Detail zu gehen, 
was ihm daran nicht gefällt.

Muss man also erst mal herausfinden, was genau davon nicht passt. Habe 
ich getan und festgestellt: Da werden zwei "-I"-Parameter zu viel 
übergeben. Und zwar sind das die, deren Pfade auf "\" enden.

Der Witz ist dabei: Es genügt bei dem Beispielprojekt (und auch bei 
meinem Testprojekt), das target device z.B. auf einen AVR128DB64 
umzustellen, dann funktioniert alles, wie es soll. Ein ATmega (ich hab's 
mit einem 1284P versucht) funktioniert allerdings ebenfalls nicht.

Zusammenfassend: Bug im im ATMEGA_DFP-Pack. Ältere Version benutzen. Ich 
hab's mal mit 2.0.401 probiert (weil die gerade bei mir noch lokal 
rumhing), damit geht es.

[Daniel B. (daniel10)]

Hallo ihr Lieben.
Ihr habt recht mit dem Device-Pack. Hab jetzt 2.0.401 drauf und klappt 
tatsächlich. Vielen lieben Dank. Ich hoffe Microchip behebt den Fehler 
mal, weil nun ständig Updates vorgeschlagen werden beim laden von ATmega 
Projekten :-D

Auf ein Fehlerhaftes Pack wäre ich so schnell nicht gekommen. Wie hab 
ihr das festgestellt? Vorahnung aus vorherigen Problemen bei euren 
Projekten?

Grüße, Daniel :-)

[Harald K. (kirnbichler)]

Daniel B. schrieb:
> Ich hoffe Microchip behebt den Fehler mal

Da Microchip Studio schon lange nicht mehr weiterentwickelt wird und 
Microchip die Leute dazu bringen will, stattdessen MPlab zu verwenden, 
halte ich das für nicht übermäßig wahrscheinlich.

[Moby A. (mobynew)]

Es scheint zum Glück folgende Lösungsmöglichkeit zu geben (insbesondere 
für die neue AVR-LA Serie von Interesse die kein in Studio 
funktionierendes Device-Pack mehr bietet):

- die betreffende ControllerDef .inc ins Projekt aufnehmen/kopieren (im 
Solution Explorer)
- diese .inc Datei anfangs im Code inkludieren
- alle Include-Pfade in den Projekteigenschaften 
(Toolchain/AVRAssembler/General) löschen

Der Build Prozess läuft jetzt fehlerfrei durch.

Daniel B. schrieb:
> Fehlerhaftes Pack

Da wurde wohl irgendwas am Pack-Standard verändert.

[Ob S. (Firma: 1984now) (observer)]

Moby A. schrieb:

> Da wurde wohl irgendwas am Pack-Standard verändert.

Das glaube ich nicht. Wäre es so, müsste sich das ja gleichermaßen auf 
die anderen AVR8-Packs auswirken (ATtiny_DFP, AVR-Dx_DFP usw.). Tut es 
aber nicht.

Bug ist schon deutlich wahrscheinlicher. Wobei der Bug mit einiger 
Wahrscheinlichkeit im Studio selber steckt, das Pack ihn also mehr oder 
weniger nur "exploited".
Beim Vergleich der verschiedenen Versionen des ATmega_DFP habe ich 
jedenfalls keine wirklich auffälligen strukturellen Unterschiede 
feststellen können (mal abgesehen vom zusätzlichen Gedöhns für den 
XC8-Compiler), auch nicht beim Vergleich der aktuellen Version des 
ATmega_DFP mit der aktuellen Version des ATtiny_DFP.

Auffallend ist jedenfalls, dass genau nur das eine Pack betroffen ist, 
in dem es seit einer kleinen Ewigkeit keine neuen Devices mehr gab. 
Zuletzt war das wohl 2019 der Fall.

[Moby A. (mobynew)]

Ob S. schrieb:
> Wäre es so, müsste sich das ja gleichermaßen auf die anderen AVR8-Packs
> auswirken (ATtiny_DFP, AVR-Dx_DFP usw.). Tut es aber nicht.

Doch, tut es.
Sowohl die letzten Device-Packs von AVR-Dx als auch -Ex sowie alle des 
allerneuesten -LA (wie bereits erwähnt) sind ebenfalls betroffen. An 
einen Bug in Studio glaube ich bei dieser Chronologie der Ereignisse 
eher nicht. Es sind nicht irgendwelche Device-Packs, es sind die 
neuesten. Die beiden letzten Updates für ATmega übrigens von 12/25 und 
1/26. Version 2.2.509 von 12/23 funktioniert noch.

[Ob S. (Firma: 1984now) (observer)]

Moby A. schrieb:

> Doch, tut es.
> Sowohl die letzten Device-Packs von AVR-Dx als auch -Ex sowie alle des
> allerneuesten -LA (wie bereits erwähnt) sind ebenfalls betroffen.

Ooops... Hast recht.

Umso interessanter wäre es, herauszubekommen, was genau der Auslöser für 
das fehlerhafte Verhalten des Studio ist, so dass man das Problem gleich 
an der Ursache bekämpfen kann. Sprich: durch Patch der Pack-Dateien 
dafür sorgen, dass das Studio von allein wieder korrekte 
Projekttemplates generiert.

Ich habe mich daran ja schon ansatzweise, ziemlich unsystematisch und 
leider erfolglos versucht. Es muß ein wirklich winziges Detail sein, was 
mir bisher schlicht entgangen ist.

Konkret würde mich vor allem AVR-Dx interessieren. Kannst du zufällig 
genau sagen, welche Version die letzte ist, mit der es noch geht?

[Moby A. (mobynew)]

Ja. Nur das letzte 2.8.337 macht beim Dx Probleme. 2.7.321 von 2/25 
funktioniert noch.
Ohne daß ich es ausprobiert hätte tippe ich auch auf ein dysfunktionales 
letztes Update für ATtiny_DFP (2.1.484 von 4/26).

[Harald K. (kirnbichler)]

Wie sieht denn der Assembleraufruf bei den "funktionierenden" 
Devicepacks aus?

Fehlen da auch die Leerzeichen zwischen "-I" und dem damit angegebenen 
Pfad?

[Moby A. (mobynew)]

C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\avrasm2.exe -fI -o 
"AssemblerApplication4.hex"  -m "AssemblerApplication4.map"  -l 
"AssemblerApplication4.lss"  -S "AssemblerApplication4.tmp"  -W+ie 
-I"C:/Program Files 
(x86)\Atmel\Studio\7.0\Packs\Atmel\AVR-Dx_DFP\2.7.321\avrasm\inc" 
-iAVR64DD14def.inc -d 
"E:\Projekte\Current\AssemblerApplication4\Debug\AssemblerApplication4.o 
bj"   "E:\Projekte\Current\AssemblerApplication4\main.asm"  -I 
"C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

Build OK.

C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\avrasm2.exe -fI -o 
"AssemblerApplication4.hex"  -m "AssemblerApplication4.map"  -l 
"AssemblerApplication4.lss"  -S "AssemblerApplication4.tmp"  -W+ie 
-I"C:/Program Files 
(x86)\Atmel\Studio\7.0\Packs\Atmel\AVR-Dx_DFP\2.8.337\avrasm\inc\" 
-I"C:/Program Files 
(x86)\Atmel\Studio\7.0\Packs\Atmel\AVR-Dx_DFP\2.8.337\include\" 
-I"C:/Program Files 
(x86)\Atmel\Studio\7.0\Packs\Atmel\AVR-Dx_DFP\2.8.337\avrasm\inc" 
-iAVR64DD14def.inc -d 
"E:\Projekte\Current\AssemblerApplication4\Debug\AssemblerApplication4.o 
bj"   "E:\Projekte\Current\AssemblerApplication4\main.asm"  -I 
"C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

Build failed.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:
> Wie sieht denn der Assembleraufruf bei den "funktionierenden"
> Devicepacks aus?

schrieb ich schon weiter oben:

Bei den dysfunktionalen Packs werden zwei zusätzliche -I-Parameter 
übergeben. Nicht das eine fehlplazierte Leerzeichen ist dabei das 
Problem, sondern entweder die bloße Existenz dieser zwei überflüssigen 
Zeilen oder die Tatsache, dass die übergebenen Pfade im Gegensatz zu den 
ohnehin regulär übergebenen Zeilen auf "\" enden.

Jedenfalls ist das Prinzip der Lösung klar: man muss herausfinden, was 
genau das Studio veranlasst, diese zwei Zeilen überhaupt in die 
Projektkonfiguration zu schreiben. Wenn man das verhindert, spielt es 
auch keine Rolle mehr, was genau darin steht.

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Nicht das eine fehlplazierte Leerzeichen ist dabei das
> Problem, sondern entweder die bloße Existenz dieser zwei überflüssigen
> Zeilen oder die Tatsache, dass die übergebenen Pfade im Gegensatz zu den
> ohnehin regulär übergebenen Zeilen auf "\" enden.

Das lässt sich ja recht leicht herausfinden - man kann den Assembler 
auch von Hand aufrufen, im Kommandozeilenfenster, und da mit den 
Argumenten spielen.

Daß mehrere -I-Argumente ein Problem sind, halte ich für 
unwahrscheinlich, denn wie soll man sonst mehrere Pfade angeben, in 
denen nach Dateien zu suchen ist?

Also könnte es der abschließende Backslash sein.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:

> Das lässt sich ja recht leicht herausfinden - man kann den Assembler
> auch von Hand aufrufen, im Kommandozeilenfenster, und da mit den
> Argumenten spielen.

Natürlich. Genau das habe ich ja auch getan.

> Daß mehrere -I-Argumente ein Problem sind

Sicher nicht pa se. Im konkreten Fall handelt es sich aber um 
Doppelungen der zwei ohnehin übergebenen Pfade, halt nur mit dem 
Unterschied, dass hier jeweils ein Backslash am Pfadende ist.

Wie auch immer der Assembler damit umgeht (offensichtlich falsch), die 
wirkungsvollste Bekämpfung wäre jedenfalls, schon diese unnötige 
Doppelung zu verhindern.

[Moby A. (mobynew)]

Ob S. schrieb:
> Jedenfalls ist das Prinzip der Lösung klar: man muss herausfinden, was
> genau das Studio veranlasst, diese zwei Zeilen überhaupt in die
> Projektkonfiguration zu schreiben

Bei den funktionierenden Versionen ist die Parameterzeile deutlich 
kürzer (als bei obiger) und es gibt nur einen Include-Pfad. Vorgaben, 
welche die verwendete DP-Version macht.

[Ob S. (Firma: 1984now) (observer)]

Moby A. schrieb:

> Bei den funktionierenden Versionen ist die Parameterzeile deutlich
> kürzer und es gibt nur einen Include-Pfad.

Ja klar. Aber warum passiert das?

Das Verhalten muß ja irgendwie durch den Inhalt des Packs ausgelöst 
werden. D.h.: durch peniblen Vergleich der beiden von dir 
herausgesuchten Packversionen sollte sich der Auslöser identifizieren 
lassen.

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:
> Moby A. schrieb:
>
>> Bei den funktionierenden Versionen ist die Parameterzeile deutlich
>> kürzer und es gibt nur einen Include-Pfad.
>
> Ja klar. Aber warum passiert das?
>
> Das Verhalten muß ja irgendwie durch den Inhalt des Packs ausgelöst
> werden. D.h.: durch peniblen Vergleich der beiden von dir
> herausgesuchten Packversionen sollte sich der Auslöser identifizieren
> lassen.

Ich habe zumindest erst mal einen Verdächtigen: die *.pdsc-Datei des 
Packs.

An sehr vielen Stellen kommt da vor:
(alt)
<file condition="AVRASM" category="include" name="avrasm/inc"/>
vs. neu
<file condition="AVRASM" category="include" name="avrasm/inc/"/>

Wenn's das ist, gibt es wahrscheinlich noch eine zweite, analoge Stelle 
für den Verweis auf
"C:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

Die habe ich allerdings noch nicht finden können.

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:

> Ich habe zumindest erst mal einen Verdächtigen: die *.pdsc-Datei des
> Packs.
>
> An sehr vielen Stellen kommt da vor:
> (alt)
> <file condition="AVRASM" category="include" name="avrasm/inc"/>
> vs. neu
> <file condition="AVRASM" category="include" name="avrasm/inc/"/>

Das war's erstmal nicht. Auch eine entsprechend gepatchte *.pdsc ändert 
nix am Verhalten. Ach ist das mühsam...

[Moby A. (mobynew)]

Alle Include-Pfade in den Projekt-Einstellungen 
(Toolchain/AVRAssembler/General) löschen und den Pfad zur .inc ohne 
abschließendes \ neu angeben. Dann funktionierts ebenfalls.

[Ob S. (Firma: 1984now) (observer)]

Moby A. schrieb:
> Alle Include-Pfade in den Projekt-Einstellungen
> (Toolchain/AVRAssembler/General) löschen und den Pfad zur .inc ohne
> abschließendes \ neu angeben. Dann funktionierts ebenfalls.

Ja, das ist doch seit langem klar.

Wirklich schön wäre es halt, die eigentliche Ursache zu finden, die das 
Studio dazu bringt, diese falschen Projekteinstellungen überhaupt erst 
zu erzeugen. Und die erzeugt das Studio ja aus dem ganzen Gesolms im 
DevicePack.

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Ach ist das mühsam...

Sieh mal in die Datei "Ventilator_Steuerung.asmproj" rein.

Da drin steht (gleich zweimal, einmal für Debug, einmal für Release)

  <avrasm.assembler.general.AdditionalIncludeDirectories>
    <ListValues>
      <Value>%24(PackRepoDir)\Atmel\ATmega_DFP\2.4.522\avrasm\inc\</Value>
      <Value>%24(PackRepoDir)\Atmel\ATmega_DFP\2.4.522\include\</Value>
      <Value>%24(PackRepoDir)\Atmel\ATmega_DFP\2.4.522\avrasm\inc</Value>
    </ListValues>
  </avrasm.assembler.general.AdditionalIncludeDirectories>
  <avrasm.assembler.general.IncludeFile>m168def.inc</avrasm.assembler.general.IncludeFile>

[Moby A. (mobynew)]

Ob S. schrieb:
> Wirklich schön wäre es halt, die eigentliche Ursache zu finden

Viel Erfolg beim Studium der .pdsc :)
Ein Pack-Standard, welcher sich jederzeit wieder ändern kann.
Ich hab mal bei Microchip angefragt was das Ganze soll.
Die vorgestellte praktische Lösung reicht in der Zwischenzeit!