Hallo, ich habe ein Problem bei der Installation von Atmel Studio 7 unter Windows 10. Wenn ich Atmel Studio 7 installiere wird im Geräte-Manager das Gerät/Treiber Jungo Connectivity atmelwindrvr mit einem Problem markiert. Der Fehlercode ist 52 (Die digitale Signatur der für dieses Gerät erforderlichen Treiber kann nicht überprüft werden). Das wäre aber nicht mein Hauptproblem könnte vllt. jedoch davon abhängen! Mein Hauptproblem ist, dass das Debuggen mit dem Simulator nicht richtig funktioniert! Die Haltepunkte (egal wo gesetzt) werden nie erreicht (Meldung beim Haltepunkt: Unable to set requested breakpoint on target. Note: The current selected device is unable to set breakpoints during runtime). Außerdem wird beim Debuggen mit Einzelschritt weder der gelbe Pfeil am linkem Rand, noch der gelbe Hintergrund angezeigt. (siehe angehängte Datei). Eine Neuinstallation brachte keinen Erfolg. Hat vielleicht jemand das gleiche Problem? Oder weiß jemand einen Workaround für dieses Problem. Es ist übrigens ein neuaufgesetztes Betriebssystem Windows 10 mit dem aktuell letztem Release! Die Forumsuche ergab bei mir leider keinen Erfolg.
Hi, Hast du die Optimierung in Projekteinstellungen aktiviert? Das ist ein Compilerflag. Ich kann leider auf dem Bild nicht sehen, ob du den simulator als Tool ausgewählt hast. Ist die Option direkt neben deinem Mikrocontroller? Ich drücke immer Debug and break Knopf. Pause und Play neben den Einstellung für Debug. Davon abgesehen sehe ich den Aufruf der Funktion nicht in der du den breakpoint gesetzt hast. Daher wird er nicht erreicht bzw. aktiv. Das scheint das Problem zu sein. Da Problem mit der Installation kam die Treibersignierung sein. Das kannst du sicher im Internet oder gar hier im Forum finden wie es ausgeschaltet wird.
:
Bearbeitet durch User
Hallo, danke erstmal für deine Antwort. Folgendes zu deinen Fragen: Die Optimierung ist deaktiviert (zu Testzwecken)! Ich erreiche auch wirklich die einzelnen Codezeilen jedoch werden diese nicht in gelb hervorgehoben!!! Ich habe als Debugger den Simulator verwendet! Bei dem Aufruf der Funktion hast du Recht, das war ein schlecht gewähltes Beispiel, da ich diese Funktion in diesem Beispielcode wirklich nicht aufrufe. Es sieht jedoch genauso aus wenn ich den Breakpoint in der main-Schleife setze, also liegt es an dem leider auch nicht!!! Wegen der Treibersignierung werde ich mich mal schlau machen, danke für den Tipp. Fällt dir vielleicht noch etwas ein was ich testen könnte???
Chucky4 schrieb: > Fällt dir vielleicht noch etwas ein was ich testen könnte??? Drück mal den Knopf Start Debugging and Break (Alt + F5). Dieser Knopf ist meistens direkt neben der Konfiguration zu finden. Der Debugger bleibt dann direkt in der ersten Zeile von deiner main-Routine stehen. Ich habe auch schon sehr lange warten müssen, bis tatsächlich einer meiner Breakpoints erreicht wurde, deswegen lasse ich den Debugger immer in die erste Zeile von main springen. Du kannst auch mal deine Compilerflags kopieren und in den Beitrag hinzufügen. Wenn du auf eine Hauptkategorie klickst, werden sie unter All Options dargestellt. Hast du deine Konfiguration auch auf Debug und nicht auf Release stehen?
:
Bearbeitet durch User
Dev P. schrieb: > Drück mal den Knopf Start Debugging and Break (Alt + F5). Das Problem ist nicht, dass ich nicht debuggen kann, sondern dass der Debugger die aktive Zeile nicht gelb hervorhebt und auch den gelben Pfeil an der linken Zeile nicht anzeigt! Dass ich debuggen kann, sehe ich anhand der Variablen die sich auch ändern wenn ich per Einzelschritt debugge! Man kann die aktive Zeile nur anhand der grauen Linien oberhalb und unterhalb erkennen! Im Beispiel zwei Bilder in dem man die Veränderung der Variable "a" sieht!!! Der Quellcode macht zwar wenig Sinn, es ist aber auch nur ein Beispiel! Das Stoppen auf einen Breakpoint funktioniert aber überhaupt nicht nur das Einzelschritt-Debuggen! Dev P. schrieb: > Du kannst auch mal deine Compilerflags kopieren und in den Beitrag > hinzufügen. Dort steht folgendes: -x c -funsigned-char -funsigned-bitfields -DDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.106\include" -O0 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g3 -Wall -mmcu=atmega128 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.106\gcc\dev\atmega128" -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" Dev P. schrieb: > Hast du deine Konfiguration auch auf Debug und nicht auf Release > stehen? Ja meine Konfiguration steht auf Debug.
Ok, ich habe gerade selbst herausgefunden wie man das Problem umgehen kann (bzw. beheben). Atmel Studio kommt anscheinend nicht mit dem Pfad klar wo die Projektdateien abgelegt sind. Wenn ich den Ordner direkt auf die Festplatte "C:\" lege und neu kompiliere und dann debugge funktioniert alles wie es soll. Das Problem muss wahrscheinlich bei meinem Benutzernamen liegen welches ein "ö" enthält. Atmel Studio kommt also wahrscheinlich nicht klar mit "ä", "ö", "ü"! Trotzdem ein Danke für die Hilfe!
Da wäre ich auch nicht darauf gekommen. Gut, dass du es gefunden hast.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.