Announcement: there is an English version of this forum on Hallo Ich habe mir einen Snap zugelegt (Beitrag "Billig JTAG Programmer AVR") und wollte damit ein wenig mi tMicrochip Studio Debuggen. Aber irgendwie entwickelt sich das zu einem mehrtägigen einzigen Frust? Ist das wirklich so kompliziert? Erst muß ich feststellen, daß der Snap für UDPI erst einmal umgebaut werden muß. https://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf Dann erkennt Microchip Studio zwar den Snap aber wenn ich ihn als Programmer einstellen will, sagt er, da ist Firmware 0 drauf und er hat eine neue. Aber jeder Update-versuch scheitert. Aha: https://swharden.com/blog/2022-12-09-avr-programming/#step-1-setup-mplab Also noch MPLAB X IDE installieren. Da dann die Arie mit Jumper-Kurzschluß, USB ab, ran, ab, ran. Und am Ende: Error. Jetzt hängt der im Update-Modus und die LED leuchtet nicht. Warum? Und nun? Und wieso gibt's nirgends eine brauchbare Anleitung, wo die ersten Schritte hilfreich erklärt sind? Und: wieso bekommt man den PICKit 3 nirgends mehr? Der hat doch wohl weniger Probleme.
Jürgen schrieb: > Aber irgendwie entwickelt sich das zu einem mehrtägigen einzigen Frust? Nicht aufgeben! Viele schreiben über Anfangsprobleme mit dem Snap. Z.B.: https://forum.microchip.com/s/topic/a5C3l000000Mba1EAC/t374517 Auch in diesem Forum gab es schon einige Threads zum Snap-Anfangsproblem.
Jürgen schrieb: > daß der Snap für UDPI erst einmal umgebaut werden muß Wolltest Du nicht JTAG debuggen? Mit Snap hab ich keine guten Erfahrungen. Für UPDI ideal und bezahlbar ist der nEDBG auf den Curiosity Nano Modulen.
Gerhard H. schrieb: > Mit Snap hab ich keine guten Erfahrungen. Wir wollen hier nur Erfolgsberichte sehen!
Georg M. schrieb: > Wir wollen hier nur Erfolgsberichte sehen! Ich dachte das passt besser zum Thema Ärgernis :)
Eine Teilerkenntnis: mein Laptop zum spielen ist wohl zu lahm. Deshalb gibt's timeouts. Mal sehen, habe spontan einen aktuelleren Billig-PC gekauft. Muß doch irgendwie klappen...
Jürgen schrieb: > Und: wieso bekommt man den PICKit 3 nirgends mehr? Der hat doch wohl > weniger Probleme. ... kann aber nur PICs programmieren, aber keine AVRs. China-Nachbauten bekommst Du noch problemlos. Die funktionieren meist auch. Das Original wird halt seit ca. 5 Jahren nicht mehr hergestellt. Jetzt gibts das PICKIT5 als Ersatz. So einfach ist das. fchk
Hallo, ich hatte beim Firmware Update für den Atmel ICE auch ein Problem. Ein Update funktionierte. Das zur nächsten Version nicht mehr. Wenn du das Update herunterladen kannst, stehen die Chancen gut das es ähnlich funktioniert wie bei mir. Beitrag "Re: Verkauft microchipdirect unprogrammierbare AVR16EB28?" Für den Snap wäre: https://packs.download.microchip.com/#collapse-Microchip-Snap-TP-pdsc
:
Bearbeitet durch User
Frank K. schrieb: > Jürgen schrieb: > >> Und: wieso bekommt man den PICKit 3 nirgends mehr? Der hat doch wohl >> weniger Probleme. > > ... kann aber nur PICs programmieren, aber keine AVRs. Ich meinte den 4er - sorry Veit D. schrieb: > Hallo, > > ich hatte beim Firmware Update für den Atmel ICE auch ein Problem. Ein > Update funktionierte. Das zur nächsten Version nicht mehr. Wenn du das > Update herunterladen kannst, stehen die Chancen gut das es ähnlich > funktioniert wie bei mir. > Beitrag "Re: Verkauft microchipdirect unprogrammierbare AVR16EB28?" > > Für den Snap wäre: > https://packs.download.microchip.com/#collapse-Microchip-Snap-TP-pdsc Ist das wirklich die Firmware vom Snap? Sind das nicht nur Pakcs etc. für die Unterstützung seitens der Software??? Inzwischen habe ich zumindest schon mal auf einen ATtiny mit UPDI zugreifen können. Aber bei einem mega328 auf einem Arduino Uno klappt es nicht per debugWire (der Kondensator in der Reset-Leitung ist deaktiviert). Grummel
Hallo, Wie gesagt, ich habe das für meinen ICE gemacht mit den Dateien paar Zeilen weiter oben auf der Seite. Packs ist ein Sammelbegriff. Egal ob Device Packs oder Firmware. Nach runterladen und Doppelklick landet das in der bekannten Devive Pack Übersicht. Auch von dort aus kann man das Firmware Update machen. Ist eben dann dort wie Device Packs gelistet. Oder du entpackst das usw. wie beschrieben. Alle Wege führen nach Rom. Nochmal anders erklärt. Ich hatte bei mir das Device Pack für die AVRxEA Controller in Microchip Studio installiert und konnte mit Atmel ICE dennoch nicht flashen. Erst nach dem Firmware Update wie beschrieben konnte ich den EA flashen.
Jürgen schrieb: > Aber bei einem mega328 auf einem Arduino Uno klappt es > nicht per debugWire Jürgen schrieb: > Aber irgendwie entwickelt sich das zu einem mehrtägigen einzigen Frust? > Ist das wirklich so kompliziert? Wer mit Gewalt an alten Controllern, hakligen Debug-Interfaces und unausgereiften Tools festhält muss leiden.
Jürgen schrieb: > Inzwischen habe ich zumindest schon mal auf einen ATtiny mit UPDI > zugreifen können. 🙂👍🏻 Jürgen schrieb: > Aber bei einem mega328 auf einem Arduino Uno klappt es > nicht per debugWire Aber die SPI-Verbindung funktioniert? Gerhard H. schrieb: > Wer mit Gewalt an alten Controllern, hakligen Debug-Interfaces und > unausgereiften Tools festhält muss leiden. Etwas mehr Mitgefühl, bitte!
Georg M. schrieb: > Etwas mehr Mitgefühl, bitte! Das sagte ich aus Mitgefühl. Mit offensichtlich unausgereifter Technik sollte man sich wirklich nicht lange rumärgern.
Gerhard H. schrieb: > Georg M. schrieb: >> Etwas mehr Mitgefühl, bitte! > > Das sagte ich aus Mitgefühl. > Mit offensichtlich unausgereifter Technik sollte man sich wirklich nicht > lange rumärgern. Leider kann sich nicht jeder einen Jegger leisten. Nicht Mal ein Eis (schlechter Sprachwitz). Veit D. schrieb: > Nochmal anders erklärt. > Ich hatte bei mir das Device Pack für die AVRxEA Controller in Microchip > Studio installiert und konnte mit Atmel ICE dennoch nicht flashen. Erst > nach dem Firmware Update wie beschrieben konnte ich den EA flashen. Fürs Archiv: Ich habe das Download einfach mal gestartet (Windows). Dann kam der Installer und ich habe alles installiert. Allerdings muß man die Optionen aktivieren - obwohl es die Funktion "alles installieren" gibt - die installiert sonst nur irgendeinen Teil. Mit den Haken dauert das ganze dann 'ne Viertelstunde und mehr. Mehrmaliges schauen und öffnen in IPE, IDE und Studio schien aber nirgends den Snap zu betreffen, sondern nur Software-Treiber (o.ä.) Aber ich hab's gefunden: An irgendwelchen Stellen liest man, daß DWEN sich per dW aktivieren läßt. Wäre IMHO ja auch sonnvoll. Aber nein: man muß da erst per ISP ran. Dann klappt's auch. ARGH, Haare-Rauf Irgendwann werde ich mich dann auch mal mit PICs beschäftigen - wenn mein Frust-Pegel ganz weit gesunken ist. Danke fürs "Mitgefühl" und die Möglichkeit, mich auszukotzen, um so Frust abzubauen und neue Motivation zu bekommen.
Gerhard H. schrieb: > Mit offensichtlich unausgereifter Technik sollte man sich wirklich nicht > lange rumärgern. Das hat bei "Atmel" ja schon Jahrzehnte Tradition. Wenn an der Hardware nicht gepfuscht wurde, wurden zum Ausgleich Treiber, die mit Demosoftware praepariert waren, installiert. Und vice versa...
Die aktuellen Tools sind ganz OK. Dafür schlampt Microchip wieder bei der Dokumentation.
Gerhard H. schrieb: > Wer mit Gewalt an alten Controllern, hakligen Debug-Interfaces und > unausgereiften Tools festhält muss leiden. Gerhard H. schrieb: > Mit offensichtlich unausgereifter Technik sollte man sich wirklich nicht > lange rumärgern. Da der Hersteller sein Produkt für genau diesen Anwendungsfall vermarktet, muss das auch funktionieren. Dein "selber Schuld" Spruch ist unpassend.
Jürgen schrieb: > An irgendwelchen Stellen liest man, daß DWEN > sich per dW aktivieren läßt. Wäre IMHO ja auch sonnvoll. Aber nein: man > muß da erst per ISP ran. Ja genau. Die DWEN Fuse kann man nur per ISP einschalten. Und man kann sie nur per Debug Wire wieder ausschalten. Das ist für Leute tückisch, die einen Programmieradapter ohne Debugwire haben, denn sie kommen aus dem Debug-Modus nicht mehr heraus.
Steve van de Grens schrieb: > Da der Hersteller sein Produkt für genau diesen Anwendungsfall > vermarktet, muss das auch funktionieren Na wenn man sich darauf immer verlassen könnte... Du glaubst wohl jeder Werbung. > Dein "selber Schuld" Spruch ist unpassend. Der könnte nicht besser passen. Aber jeder wie er mag.
Jürgen schrieb: > Also noch MPLAB X IDE installieren. Da dann die Arie mit > Jumper-Kurzschluß, USB ab, ran, ab, ran. Und am Ende: Error. Jetzt hängt > der im Update-Modus und die LED leuchtet nicht. > Warum? Und nun? Ich hatte das Problem ebenfalls, mit der aktuellen MPLAB X Ide 6.20 konnte ich weder unter Linux noch Windows MPLAB Snap zum Leben erwecken. Das Löschen hatte wohl funktioniert, aber mehr auch nicht. Nach langem rumgehampel, suchen, lesen habe ich dann die "alte" MPLAB IDE 6.20 (ohne X) unter Windows installiert, damit hatte ich dann Zugriff auf den Snap und konnte die Software draufbekommen. Jetzt funktioniert er endlich.....
:
Bearbeitet durch User
So allmählich wird es (auch mir) klar: Die Firmwareversion 1.0b, mit der neuere MPLAB Snap ausgeliefert werden, unterstützt keinen AVR-Modus mehr und lässt sich daher nicht mehr mit Microchip Studio verwenden. Dafür braucht man die Firmwareversion 1.0a, die vor ca. 4 Jahren noch ausgeliefert wurde. Mit einer ausreichend alten Version von MPLAB X und dem darin enthaltenen "Emergency Boot Firmware Recovery Utility" kann eine alte Firmware auf den MPLAB Snap übertragen werden. https://onlinedocs.microchip.com/pr/GUID-671CAF55-DB13-4D9A-8881-F58C984111B5-en-US-4/index.html?GUID-23D41E7C-F770-49A0-9365-D13987945F29 Alte Version von MPLAB X: https://ww1.microchip.com/downloads/en/DeviceDoc/MPLABX-v5.30-windows-installer.exe Wenn man einen anderen SAM-BA-Programmierer* hat, genügt natürlich die Firmwaredatei, die sich irgendwo in den Tiefen des fast 1 GByte großen Klumpens von MPLAB X verbirgt ... *) https://www.microchip.com/en-us/development-tool/sam-ba-in-system-programmer
Angehängte Dateien:
-
20240607_214352_resized.jpg
240 KB
Hallo "Snaper", da ich keine Lust mehr hatte das Atmel Studio nur noch in der VM zu betreiben (habe nur noch Ubuntu nativ laufen) und mein Pickit3 nach MPLAB X 6.20 nicht mehr gehen wird habe ich mich entschlossen es mal mit dem Snap zu probieren. Mit den Einschränkungen gegenüber ICE und Pickit4/5 bezüglich HV und Targetversorgung kann ich sehr gut leben. Wenn es zu alt wird oder HV-Programmierung benötigt wird muss halt mein kleiner chinesischer Freund (TL866) ran. Nachdem ich den Snap mit etwas Kelinkram bei Digikey bestellt hatte habe ich die Sache mit dem PullDown für AVRs gelesen und war etwas irritiert über so eine "Bug". Als ich den Snap dann heute bekommen habe kam die Überaschung: Microchip hat die Hardware geändert und einen Jumper für die Abschaltung des PullDown vorgesehen so das das Basteln entfällt.
Beitrag #7680247 wurde vom Autor gelöscht.
Connecting to MPLAB Snap Currently loaded versions: Application version...........02.01.26 Boot version..................01.01.55 PCB version...................2 Script version................00.07.19 Script build number...........343401fe73 Tool pack version ............2.4.1239 Target device ATmega328P found. Device Id Revision = 0x0 (A) Device Id = 0x1e950f The following memory area(s) will be read: configuration memory Read complete
Danke. Interessant; denn das bedeutet, daß auch diese Variante vom Snap noch dafür verwendet werden kann, AVRs anzusteuern. Das widerspricht dem bisherigen Erkenntnisstand, nachdem das zumindest beim Einsatz von Microchip Studio erheblichen Ärger macht. Welche Software verwendest Du jetzt?
Ich verwende Mplab X unter Ubuntu. Microchip bietet AVRGCC zum Download an. Dieser muss lediglich Mplab bekannt gemacht werden. Import von Atmel Studio Projekten und Debug per Debugwire wurde erfolgreich getestet. Das ist ja der von Microchip geplante Weg. Für mich wird er als gangbar angesehen. Mein Dragon darf jetzt weiterziehen falls jemand Interesse hat.
:
Bearbeitet durch User
C. W. schrieb: > Ich verwende Mplab X unter Ubuntu. Das Fazit scheint zu sein, daß Microchip das Microchip Studio abschaffen will (da es dafür schon seit zwei Jahren keine Updates mehr gibt, ist ja auch ein Indiz). Wenn MPLAB X nur keine so hässliche JavaBeans-Oberfläche wäre ...
Harald K. schrieb: > Wenn MPLAB X nur keine so hässliche JavaBeans-Oberfläche wäre Ist das so wichtig? Ich lege Wert darauf, dass meine Arbeitsmittel zuverlässig funktionieren und praktisch sind.
Harald K. schrieb: > Interessant; denn das bedeutet, daß auch diese Variante vom Snap noch > dafür verwendet werden kann, AVRs anzusteuern. Aber dann wäre der "PIC/AVR" Jumper doch sinnlos!
Monk schrieb: > Ist das so wichtig? Mir ja. > Ich lege Wert darauf, dass meine Arbeitsmittel > zuverlässig funktionieren und praktisch sind. Und da ist ein Editor, eine GUI, die radikal von dem abweichen, was ich jahrzehntelang gewohnt bin, ein Hemmschuh. Ich tu' mich (an anderer Stelle) ja schon schwer damit, mich an VSCode zu gewöhnen - ein Editor, der keine "virtual spaces" kennt, ist, wenn man das jahrzehntelang gewohnt war, auch ein Ärgernis. Trotz der beeindruckenden Erweiterbarkeit von VSCode ist das ein ungelöstes Problem. Für diejenigen, die nicht wissen, was "virtual spaces" sind: Man stelle sich eine Textdatei folgenden Inhaltes vor:
1 | einelängezeilemittext |
2 | kurzzeile |
Der Cursor befindet sich am Ende der ersten Zeile. Was passiert, wenn die "Cursor-nach-unten"-Taste gedrückt wird? Bewegt er sich nur nach unten, oder springt er auch nach links? Ein Editor ist wie ein paar gut eingelaufene Schuhe. Daran hat man sich gewöhnt. Deswegen sind bessere Editoren auch an die jeweiligen Bedürfnisse des Benutzers anpassbar, was eben nicht nur "key bindings" und anderes angeht.
Ich hätte übrigens noch so einen neuen Snap übrig - hier in Forum unter "Markt"
Harald K. schrieb: > Monk schrieb: >> Ist das so wichtig? > > Mir ja. Luxusproblem. Früher waren wir schon mit VT220-Terminals zufrieden gewesen. fchk
Frank K. schrieb: > Früher waren wir schon mit VT220-Terminals zufrieden > gewesen. Und? Was hat das mit der Funktionsweise eines Editors zu tun? Ob der Editor nun in einem Textfenster oder auf einem Terminal läuft, macht da keinen Unterschied. Ein Beispiel: joe (https://joe-editor.sourceforge.io/)
:
Bearbeitet durch User
So wie ich das lese ist es fast schon ein Trost, dass ich nicht der einzige bin dem es mit dem SNAP ähnlich geht. Ich entwickle schon seit über einem Jahrzehnt unter Linux. Nur das Microchip Studio werckelt noch unter Windows in einer VM. Jetzt wollte ich "auch mal" weg und nach MPLAB umziehen. Eigentlich hätte ich mir auch gerne die Compiler angeschaut.Aber selbst mit Support von Microchip (der peinlicherweise keine Ahnung hat und echt im dunkeln Stochert...) bekommen wir das SNAP (Aktuelle HW) und MPLAB X nicht zusammen ans laufen. Der Witz dabei ist das ich mit Eclipse über GDB und mit Bloom (falls das jemand kennt) das Debugging am laufen habe... Da mir die Zeit die ich verballere zu Schade ist, irgendwelche Tests für den Microchip Support zu machen, belasse ich es jetzt dabei. Werde aber auch nicht auf die XC Compiler umsteigen. Warum auch... Die sollen ihre Toolchain erstmal stabil hinbekommen. Zum Thema selbst: Ich kann in MPLAB X 6.20 mit meinem SNAP über JTAG die Fuses einstellen, Download und Read Dev. Mem tut auch. Nur das debuggen bricht er ab mit Fehler: "Script Halt failed with status Type = runScript, Script name = Halt, Status = 0x104" Falls das jemand in der Form hat und eine Lösung weiß, Super gerne :)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.