Hallo,
ich habe mehrere Arduino Uno Boards mit ATmega328p (DIP Variante).
Eines dieser Boards ist auf einmal "tot". Ich kann weder den Loopback
Test erfolgreich machen, noch etwas flashen. Egal mit welchem Tool ich
es probiert habe: Atmel Studio, avrdude, den IC im Arduino Board, im
STK600 Sockel (Routing- und Sockel-Karte RC028M-6 und DIP Socket) oder
via AVR Dragon - ich bekomme nur Fehler. Voltage auslesen ging, aber
selbst die Chip ID brachte stets schon fehler der Art "Cannot enter
ispProgrmaming Mode".
Beispiel für Versuch als der Chip im Arduino sitzt:
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
5
Copyright (c) 2007-2014 Joerg Wunsch
6
7
System wide configuration file is "/etc/avrdude.conf"
8
User configuration file is "/home/me/.avrduderc"
9
User configuration file does not exist or is not a regular file, skipping
10
11
Using Port : /dev/ttyACM0
12
Using Programmer : arduino
13
avrdude: stk500_recv(): programmer is not responding
14
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
15
avrdude: stk500_recv(): programmer is not responding
16
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
17
avrdude: stk500_recv(): programmer is not responding
18
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
19
avrdude: stk500_recv(): programmer is not responding
(Im anderen Arduino funktionieren alle getesteten Aufrufe einwandfrei).
Nun dachte ich, "Ok, vlt. hab ich den irgendwann mal geschrottet -
könnte ja mal das HighVoltage Programming versuchen! Das STK600 kann das
ja problemlos".
Alles weitere also nun mit dem ATmega328p im Sockel auf dem STK600:
Das STK600 Board war auf 3,3V gestellt, was für HV ja zu wenig war, also
flugs im Atmel Studio auf 4.5V gestellt und .... auf einmal lebte der
Chip wieder! Konnte die ChipID auslesen, Fuses einsehen usw.
Alles schien problemlos zu funktionieren. Auch das Flashen eines
existierenden Hexfiles, dass ich gerade da hatte funktioniert.
Die Fuses DWEN und SPIEN sind mit Haken versehen in der Checkbox und
haben einen grünes Hakensymbol im Atmel Studio. Heisst das jetzt, dass
DWEN AKTIV ist, oder nur möglich ist? Ich wollte testhalber mal den
Haken entfernen, aber bekam dann gleich eine Warnung, dass man DWEN nur
über deine Debugsession ändern sollte, und sich Atmel Studio darum
kümmert. Also habe ich das lieber mal gelassen. Chip war also mit einem
Program geflasht. Dann das Board wieder auf SPI umgekabelt und versucht
den Chip auszulesen.
Erneut der Fehler das keine SPI Verbindung möglich ist. Boarspannung ist
weiterhin auf 4,5V.
Was kann das sein, ist der Chip doch irgendwie hinüber?
http://www.engbedded.com/fusecalc/
Sagt, der Auslieferungsdefault ist -U lfuse:w:0x62:m -U hfuse:w:0xd9:m
-U efuse:w:0xff:m
Arduino möchte vor dem Uno Bootloader brennen folgendes setzen.
-e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
Dann wird der Bootloader gebrannt
Dann im dritten Durchgang die Lock Fuses modifiziert.
Ich habe mir die Seite angesehen und dort festgestellt, dass wie schon
vermutet DWEN NICHT gesetzt ist.
Habe den ATmega16U2 erneut mit der entsprechenden Firmware geflasht und
dann den optiboot Bootloader mittels HV Programming auf den 328p. Danach
noch die DWEN Fuse gelöscht.
Und nun tut er wieder :-D
Offenbar ist da wohl mal was mit dem Debugwire schiefgelaufen und er kam
irgendwie nicht mehr aus dem Modus raus.
Vielen Dank für diesen Hinweis.
Im Datenblatt steht ja drin, wie die Fuses ab Werk gesetzt sind und dann
ist ISP enabled.
Das Debugwire ist ne rechte Krücke. Da es den Resetpin mit benutzt, ist
somit ISP disabled.
Man muß in der Debugsession Debugwire disablen und dann sofort per ISP
Debugwire permanent ausschalten. Sonst ist es nach einem Power-On wieder
aktiv und ISP ist wieder disabled.
Was blöderes hätte man sich kaum einfallen lassen können.
Ja, mir war nur gar nicht bewusst, dass ich da mal Debugwire aktiviert
hatte, weil es eigentlich ja ein Arduino war, wo das (von Haus aus)
nicht funktionierte - was ich aber halt auch erst nach dem Versuch
festgestellt hatte. Offenbar ist aber genau sowas passiert, dass der MC
so „zwischen den Welten“ hing. Glücklicherweise war es ja dann möglich
mittels HVPP das zu beheben. Das hatte ich auch noch nicht versucht
bisher ;-)
Peter D. schrieb:> Was blöderes hätte man sich kaum einfallen lassen können.
Es soll allerdings Leute geben, die damit umgehen können. Aber für einen
Prgrammierer von altem Schrott und Korn ist das natürlich nichts. Da
lobt man sich doch den Atmega8. Der hat dieses Teufelszeug gar nicht
erst eingebaut.
Debuggen wird ohnehin vollkommen überschätzt. Ich habe mal von jemandem
gelesen, der hat beim Debuggen seiner Waschmaschine mehrfach seine
Wohnung unter Wasser gesetzt.
Markus D. schrieb:> Die Fuses DWEN und SPIEN sind mit Haken versehen
Debug Wire und ISP schließen sich gegenseitig aus. Du musst dich mit
einem Debugger verbinden und DW temporär deaktivieren. Danach (ohne die
Stromversorgung zu unterbrechen!) kannst du mit ISP Verbinden und die
Fuse dauerhaft umstellen.
Das Problem kann schnell auftreten, wenn man eine Debug-Sitzung nicht
richtig beendet.
Avrdude kann das automatisch lösen, du musst aber einen ISP
Programmieradapter benutzen, der auch Debugwire unterstützt.
Siehe
https://www.avrfreaks.net/forum/how-debugwire-dwen-fuse-unprogrammed
Stefan ⛄ F. schrieb:> Markus D. schrieb:>> Das Problem kann schnell auftreten, wenn man eine Debug-Sitzung nicht> richtig beendet.>> Avrdude kann das automatisch lösen, du musst aber einen ISP> Programmieradapter benutzen, der auch Debugwire unterstützt.>> Siehe> https://www.avrfreaks.net/forum/how-debugwire-dwen-fuse-unprogrammed
Das hatte ich mit dem JTAGICE3 versucht (über SPI), allerdings hatte ich
da grundsätzliche Probleme, dass dieser nicht richtig erkannt wurde. Ich
erhielt immer die Meldung im AVRDude dass kein JTAGICE3 mit der
erwarteten VID/PID gefunden wurde. Vlt. kam das durch ein FW Umgrade,
welches ich bei der Verwendung von Atmel Studio ausführen musste. Im
Atmel Studio hatte ich dann immer über das "Device Programming..." Menu
versucht wieder dem Chip habhaft zu werden. Vlt. hätte ich hier das
andere mal versuchen sollen...
Na ja, wieder was gelernt :-)
Zur Ursache: "Das Problem kann schnell auftreten, wenn man eine
Debug-Sitzung nicht richtig beendet." - ich vermute, dass genau dies
passiert ist.
Markus D. schrieb:> über SPI
Nein: ISP
Aber wenn DW aktiviert ist musst du einen Debugger benutzen (oder
avrdude), nicht das ISP Protokoll.
> die Meldung im AVRDude dass kein JTAGICE3 mit der> erwarteten VID/PID gefunden wurde
Hast du den libusb Treiber installiert und das übliche Problem mit der
Treibersignatur gelöst? Falls nicht, siehe:
http://stefanfrings.de/avr_tools/libusb.html
Hallo
Ich bin ein Neuling was den ARDUINO UNO angeht (habe bislang mit
AVRSTudio418 meine ATMegas programmiert mit einem AVRISP Programmer von
NIKAI Systems - fkt tadellos).
Ich habe zu Weihnachten 2019 einen ARDUINO UNO erhalten und muss mich
erst einarbeiten (klar).
Wenn ich einen NEUEN ATMega328P im ARDUINO UNO programmieren will, muß
ich ja zuerst den Bootloader brennen und dann mein Programm (z.B
Blink.ino kompilieren und dann drauf flashen).
Wenn ich den Bootloader drauf brennen will - welchen Programmer muss ich
auswählen - bei mir ist "ArduinoISP" ausgewählt. Kann diese
Voreinstellung genommen werden und der Bootloader gebrannt werden und
wird danach auch das Lockbit für BOOTRST gesetzt?
Oder muß ich den externen AVRISP am ISCP Port des ATMeega328P
anschließen und dann im Menü den "AVRISP" auswählen?
mfg
Hermann
Hermann schrieb:> Oder muß ich den externen AVRISP am ISCP Port des ATMeega328P> anschließen und dann im Menü den "AVRISP" auswählen?
Bootloader brennen, nur mit Programmer.
Auswählen musst du natürlich den, den du da verwenden möchtest.
Stefan ⛄ F. schrieb:> Markus D. schrieb:>> über SPI>> Nein: ISP>
Typo, danke!
> Aber wenn DW aktiviert ist musst du einen Debugger benutzen (oder> avrdude), nicht das ISP Protokoll.>
Kann ich nicht mit einem JTACICE3 im DW Debugmode einen Arduino über den
ISP Header debuggen? Wie müsste ich denn sonst den JTAGICE3 mit dem
Board verbinden (das es per se nicht direkt geht, weil der Arduino die
RESET Leitung kontrolliert, hatte ich inzwischen gelesen). Ganz
grundsätzlich war ich aber der Ansicht, dass DW Debugging dann auch über
einen evtl. vorhandenen ISP Sockel gehen würde?
>> die Meldung im AVRDude dass kein JTAGICE3 mit der>> erwarteten VID/PID gefunden wurde>> Hast du den libusb Treiber installiert und das übliche Problem mit der> Treibersignatur gelöst? Falls nicht, siehe:> http://stefanfrings.de/avr_tools/libusb.html
Inzwischen gefunden, gelesen und einen Treiberfilter für libusb
eingerichtet. Danke. avrdude will trotzdem nicht. Findet den Debugger
aber kann ihn nicht nutzen (hängt und bricht mit Fehler ab). Mein
letzter Stand hierzu war, dass Windows 10 avrdude nicht das
HID-Interface nutzen lässt, als das sich JTAGICE3 mit der letzten
Firmware zu erkennen gibt, und man ein Downgrade machen müsste. Unter
Linux funktioniert es problemlos.
Markus D schrieb:> weil der Arduino die RESET Leitung kontrolliert
1. Nur wenn auch USB genutzt wird, angeschlossen ist
2. Es gibt auf den UNOs eine Reset-Enable Brücke, zum durchkratzen
Ach so? Bei Nutzung von DC IN geht es auch ohne Durchkratzen der Brücke?
Dachte das wäre unabhängig von der Stromversorgung, dass die Reset
Leitung kontrolliert wird?
Markus D schrieb:> Ach so? Bei Nutzung von DC IN geht es auch ohne Durchkratzen der Brücke?> Dachte das wäre unabhängig von der Stromversorgung, dass die Reset> Leitung kontrolliert wird?
Es ist DTR des USB Serial Wandlers, welcher über einen Kerko an Reset
zieht, wenn man den Port öffnet.
Der Kerko stört!
Tipp:
Mal den UNO Schaltplan anschauen!
https://www.arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf
Markus D schrieb:> Kann ich nicht mit einem JTACICE3 im DW Debugmode einen Arduino über den> ISP Header debuggen?
Ja kannst du.
> Ganz grundsätzlich war ich aber der Ansicht, dass DW Debugging dann> auch über einen evtl. vorhandenen ISP Sockel gehen würde?
Genau genommen brauchst du nur GND und Reset (=DW). Aber in Kombination
brauchst du auch die anderen ISP Pins, um den Debug Wire einzuschalten.
Also IST Stecker ist richtig.
Hallo
Das Flashen eines neuen Bootloaders auf den ATMega328pa des Arduino Uno
hat geklappt - habe mit der Arduino IDE eine kompilierte Binärdatei (mit
BootLoader!) exportiert und diese mittels AVRStudio 4.18 und einen
externen Programmer auf einen jungfräulichen ATMega328pa gebrannt (und
die fuses entsprechend eingestellt).
Der neue ATmega328pa lässt sich nun auch mittels Arduino IDE laden =>
der BootLoader auf dem neuen Chip fkt also.
Prima soweit.
Wenn ich nun einen neuen BootLoader usw auf den ATMega16U2 laden muss,
damit ich wie gehabt mit der Arduino IDE den ATMega328pa laden kann
(weil ich z.B mit einen Programmer mittels ICSP1 was auf den ATMega16U2
dummerweise geladen habe und ich deshalb nicht mehr den ATMega328 per
MBRXD / MBTXD laden kann) - welche files muß ich laden und wo finde ich
sie?
Vielen Dank für die Hilfe im Voraus.
Herrmann schrieb:> welche files muß ich laden und wo finde ich sie?
In jeder Arduino IDE sind alle möglichen Bootloader mitgeliefert.
z.B.:
C:\arduino-1.8.10\hardware\arduino\avr\bootloaders
Hallo Arduino Fanboy D. (ufuf)
Vielen Dank für Deine Hilfe!
Ich hab' im directory arduino\hardware\arduino\avr\firmwares/atmegaxxu2
nachgesehen und bin etwas unsicher, welches *.hex file ich nehmen müßte
- in der Arduino IDE erscheint mein Arduino UNO als Arduino/Genuino uno
=> ich müßte dann wohl das file
Genuino-COMBINED-dfu-usbserial-atmega16u2-Uno-R3.hex
oder
Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
nehmen - welches??
Und würde es reichen, nur das korrekte *.hex file zu flashen oder muss
zusätzlich noch ein weiteres file geflasht werden, das die UASRT
Kommunikation zwischen beiden ATMega's steuert?
die Boardinfo:
BN: Arduino/Genuino Uno
VID: 0x2341
PID: 0x0043
SN: 8573432333035111B160
Vielen Dank
mfg
Herrmann
Hallo zusammen,
habe auch das Problem, dass im STK500 HV geht, ISP aber nicht...fuses
habe ich via HV genau so gesetzt, wie bei einem anderen fkt 328p...
Mich interessierts rein akademisch, was da noch ursächlich sein könnte?
🤔
Danke, Klaus.
