Moin, einfach gefragt kann man einen ATMEGA644 auch ohne Quarz Programmieren? Früher ging das im Galep. Aber den einen vor mir bekomme ich nicht Programmiert. Ist als ob er nicht existiert oder nicht antwortet. Grüße aus dem Schwarzwald
GALEP5 software version 2.6.48 supportet den Chip. Wenn du den Galep hast, kannst du den chip damit auch programmieren. Normalerweise sollte sich der galep um die clocks kümmern.
Gast
#5623847
Marco K. schrieb: > einfach gefragt kann man einen ATMEGA644 auch ohne Quarz Programmieren? Mit ISP sollte das funktionieren. Im Auslieferungszustand laufen die µC mit internem R/C. So lange du die Fuses nicht auf externen Quarz umstellst, hast du Zugriff auf den µC. Mit externem Takt funktioniert das auch.
Danke Hugo genau das wollte ich wissen.
Einen CPU-Takt brauchen die AVRs nur bei ISP. Er muß dann 4* höher sein, als der ISP-Takt. Im Programmer werden sie aber im parallelen Modus programmiert, also ohne Takt. Marco K. schrieb: > Aber den einen vor mir bekomme ich nicht Programmiert. > Ist als ob er nicht existiert oder nicht antwortet. Was antwortet er denn auf das Signatur lesen?
Genau das bekomme ich zurück.
Habe jetzt 4 defekte das kann doch eigentlich nicht sein?
Programmer funktioniert aber an anderen 644 nur die 4 wollen nicht.
avrdude.exe: stk500v2_command(): command failed
avrdude.exe: stk500v2_program_enable(): bad AVRISPmkII connection
status: Unknown status 0x00
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to
override
this check.
avrdude.exe done. Thank you.
Gast
#5623920
Hm. Es ist unwahrscheinlich, dass fabrikfrische Chips defekt sind. Sind sie denn fabrikfrisch? Bzw. gerade vom Händler gekommen? Pins verbogen? Irgendeinen Unterschied zwischen den Chips oder in der Schaltung muss es ja geben. Gib am besten mal mehr Details an, bitte. Schaltung. Anschluss (ISP?, direkt im GALEP-Sockel?, etc.), Stromversorgung, Produktionsdatum, Aufrufparameter und alles, was Dir sonst noch so einfällt.
Es geht um ein Produckt das in Serie gefertigt wird. Jetz sind von 120 Platinen 4 wo sich der Atmel nicht Programmieren lässt. 644 SMD programmierung via ISP mit AVRISP mkII. Habe beim Liferanten den 644 Tauschen lassen aber der Fehler bleibt. Daher dachte ich der Quarz könnte der Fehler sein. Aber da beim programmieren ja keiner benötigt wird verstehe ich überhaupt nichts mehr.
Ist dei ISP-Takt auch niedrig genug? Siehe: Peter D. schrieb: > Einen CPU-Takt brauchen die AVRs nur bei ISP. Er muß dann 4* höher sein, > als der ISP-Takt. Marco K. schrieb: > Habe beim Liferanten den 644 Tauschen lassen aber der Fehler bleibt. > Daher dachte ich der Quarz könnte der Fehler sein. > Aber da beim programmieren ja keiner benötigt wird verstehe ich > überhaupt nichts mehr. Das verstehe ich nicht. Wenn da ein Quarz drauf ist, wird er doch wohl benutzt!? Beim Programmieren wird immer genau der CPU-Takt benutzt, der über die Fuses eingestellt ist.
Gast
#5623946
Marco K. schrieb: > Es geht um ein Produckt das in Serie gefertigt wird. > Jetz sind von 120 Platinen 4 wo sich der Atmel nicht Programmieren > lässt. Was einen Fehler auf der Platine vermuten lässt. Möglicherweise eine Zinnbrücke oder ein Riß in einer Leiterbahn. > 644 SMD programmierung via ISP mit AVRISP mkII. > Habe beim Liferanten den 644 Tauschen lassen aber der Fehler bleibt. Also, ist der Fehler von der Platine abhängig; jedenfalls eher als von dem AVR bzw. seinem Produktionsdatum. Könnte man aber trotzdem mal vergleichen. > Daher dachte ich der Quarz könnte der Fehler sein. Das kann eigentlich nicht sein, denn da der AVR im Auslieferungszustand auf dem internen RC-Oszillator steht, spielt die "Anwesenheit" des Quarzes erst einmal keine Rolle. > Aber da beim programmieren ja keiner benötigt wird verstehe ich > überhaupt nichts mehr. Eben. Mehr Details sind nötig, falls sich die Platinen nicht als Fehlerhaft erweisen.
Eine Fehlerquelle können auch fehlende Pullups am /CS von weiteren ICs am SPI-Bus sein.
So noch ein paar Fakten: Platine mit Multimeter nachgemessen vom ISP bis zum Pin durchgang und kein Schluss untereinander oder gegen VCC/GND. Mit Oszi kann ich am Quarz nichts messen, kommt nichts raus. Bei der Initial Programmierung setzt er die Fuses und bricht dann ab. Ab da kann ich ihn überhaupt nicht mehr ansprechen. Spricht also doch für einen def. Quarz? Und die Bit-Frequenz habe ich jetzt auf 8,457kHz runter getaktet.
Pullups habe ich keine drin, noch nie.
Hi, könnte es eventuell etwas mit der AVRDUDE-Version zu tun haben? Zitat: "... Avrdude- Versionen Die ursprünglich verwendete avrdude-Version 5.6 hat (wohl nur unter Windows) eine ärgerliche Macke: der Parameter -i , mit dem man die Kommunikation mit dem AVR verlangsamen kann, funktioniert nicht. Daher gab es Probleme, wenn der Attiny auf niedrige Taktraten geflasht wurde (16 kHz oder 32 kHz). Er war dann anschließend nicht mehr ansprechbar, weil die ISP-Taktrate höher als ein Viertel der AVR-Taktrate war. Mit der beigefügten Version 5.10 funktioniert der Parameter -i, und mit "-i 1000" lassen sich auch AVRs "wieder einfangen", die auf 4 KHz (32 kHz- Uhrenquarz plus Vorteiler 1/8) geflasht wurden..."/Zitat http://www.elektronik-labor.de/AVR/AVRdude.html Gibt es die Möglichkeit das STK500-Board zu verwenden? Da kann man zwischen verschiedenen ATMEGA644 auswählen. Welcher ist's den genau? 644A, 644P, 644PA? ciao gustav
Gast
#5623972
Marco K. schrieb: > So noch ein paar Fakten: > Platine mit Multimeter nachgemessen vom ISP bis zum Pin durchgang und > kein Schluss untereinander oder gegen VCC/GND. Naja. Da gibt es noch mehr Möglichkeiten. Stromversorgung. Defekte oder fehlende Bauteile. Etcpp. Alles nachkontrollieren. > Mit Oszi kann ich am Quarz nichts messen, kommt nichts raus. > Bei der Initial Programmierung setzt er die Fuses und bricht dann ab. > Ab da kann ich ihn überhaupt nicht mehr ansprechen. > Spricht also doch für einen def. Quarz? Hm. Das hättest Du mal von Anfang an sagen sollen. (Wir hassen Salamitaktik :-) ). Wenn ich das recht verstehe, dann funktioniert die Programmierug einmal wohl; wenn die Fuses neu gesetzt werden. Richtig? Dann, beim zweiten Mal nicht mehr. Richtig? Wie werden die Fuses beim ersten Mal gesetzt? Warum überhaupt, diese zweischrittige Prozess? Nun, wenn das 196 Mal geklappt hat und viermal nicht, dann bleibt die Vermutung, dass irgendein Bauteil fehlt, falsch ist oder abweichende Werte hat. Ebenso der Rest der Schaltung. Siehe oben. Da wohl beim ersten Mal, die Taktquelle geändert wird, steigt die Wahrscheinlichkeit, dass der Quarz falsch, fehlerhaft ist oder abweichenden Wert hat. Ebenso wird irgendein elektrischer Fehler in der Takterzeugung etwas wahrscheinlicher. > Und die Bit-Frequenz habe ich jetzt auf 8,457kHz runter getaktet. Schön.
Gast
#5623974
Marco K. schrieb: > Pullups habe ich keine drin, noch nie. Es darum, ob welche drin sein sollten.
Theor schrieb: >> Mit Oszi kann ich am Quarz nichts messen, kommt nichts raus. >> Bei der Initial Programmierung setzt er die Fuses und bricht dann ab. >> Ab da kann ich ihn überhaupt nicht mehr ansprechen. >> Spricht also doch für einen def. Quarz? Nö. Das spricht deutlich: Falsch gesetzte Fuses. Das passiert einem öfters, weil Fuses ja active low gesetzt werden. Außerdem verwechselt man gerne "ExtOSC" mit "Ext Crystal" - nur letzteres funktioniert mit einem Quarzkristall. Gib mal Deine Werte in Fusecalc ein: http://www.engbedded.com/fusecalc/
Hallo,
der Atmel wird mittels Script geflascht, da kann ich keine Falschen
Parameter setzen. Die erkenntniss das die Initialprogrammierung
funktioniert bis zu dem Punkt wo dann das eigentliche Programm (im
selben schritt) rein soll hatte ich erst beim Letzten erkannt da das
ziemlich schnell geht.
Vom Prinzip her ist fast nichts an dem Atmel dran.
Ist ein RS232 Datenlogger auf SD-Karten.
hier mal der Anfang vom Skript:
AvrDude = "C:\WinAVR\bin\avrdude.exe"
AvrDudeConf = "C:\WinAVR\bin\avrdude.conf"
HexFile = "ATM644_SD.HEX"
' Variablen (fix)
'**********************************
Private WshShell
Private objFSO
Private sOptionsProg
Private sOptionsFuses
Private sRun
Private nRet
Private sMsg
Private nError
sOptionsFuses = " -C " & AvrDudeConf & " -p m644 -P usb -c avrispmkII
-u -U efuse:w:0xFF:m -U hfuse:w:0xD9:m -U lfuse:w:0xEF:m"
sOptionsProg = " -C " & AvrDudeConf & " -p m644 -P usb -c avrispmkII -U
flash:w:" & HexFile & ":a"
'#####################################################################
Set WshShell = WScript.CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Angehängte Dateien:
-
ATMEL.png
(300 KB)
Marco K. schrieb: > Vom Prinzip her ist fast nichts an dem Atmel dran. Leider auch keine Abblock Kondensatoren, jedenfalls sehe ich keine im Schaltplan Ausschnitt. Man kann auch Fehler im Layout haben, die das Anlaufen des Quarzes verhindern. Welchen Quatz verwendest Du (Datenblatt)?
Gast
#5624032
Marco K. schrieb: > Mit Oszi kann ich am Quarz nichts messen, kommt nichts raus. Das Signal, was aus dem Quarz raus kommt, machst du mit der Belastung durch die Messstrippe leicht kaputt. Wenn, dann solltest am Ausgang vom Oszillator (XTAL2) messen.
Die Kondensatoren sind drin aber in einem anderen Teil des Planes. Bei einer funktionierenden Platine kann ich den Quarz messen mit dem DSO5012A von Agilent. Schöne 16MHz vom Geyer KX-12B Quarz.
Marco K. schrieb: > Bei der Initial Programmierung setzt er die Fuses und bricht dann ab. > Ab da kann ich ihn überhaupt nicht mehr ansprechen. Das schon im ersten Post und Du hättest uns ne ganze Menge Zeit gespart. Wenn der ISP-Takt zu hoch ist, kann es passieren, daß die Fuses auf Mumpitz gesetzt wurden. Man kann dann versuchen mit einem langsamen externen Takt (100kHz) und langsamem ISP-Takt den MC wieder anzusprechen (Signatur lesen) und dann die Fuses zurück setzen.
Den Tackt habe ich zwischen 8kHz und bis zu 150kHz versucht. Es kommt einfach nichts zurück.
Peter D. schrieb: > Man kann dann versuchen mit einem langsamen externen Takt (100kHz) und > langsamem ISP-Takt den MC wieder anzusprechen Hi, so meinter @Peda das wohl: Den Schieberegler nach links. ciao gustav
Angehängte Dateien:
-
STK500_Clock_adjust.jpg
(30 KB)
Ein immer wieder gern vorkommender Fehler ist eine Falschbestückung der Kondensatoren am Quarz. Bei SMD Bauteilen ist es dann oft nicht einmal sichtbar.
Gast
#5624148
Georg G. schrieb: > Ein immer wieder gern vorkommender Fehler ist eine > Falschbestückung der > Kondensatoren am Quarz. Bei SMD Bauteilen ist es dann oft nicht einmal > sichtbar. Nicht mal, wenn der Quarz schwingt? ;-) Marco K. schrieb: > Bei einer funktionierenden Platine kann ich den Quarz messen mit dem > DSO5012A von Agilent. > Schöne 16MHz vom Geyer KX-12B Quarz.
Gast
#5624221
- Verbindungs- oder Kontaktproblem im Bereich des Quarzes (durchmessen) - Defekt oder Fehlbestückung bei Quarz oder C17/C18 Meldet sich der ATmega644, wenn an XTAL2 ein Takt mit z.B. 1 MHz zugeführt wird? Gruß aus dem Schwarzwald
Hugo E. schrieb: > Nicht mal, wenn der Quarz schwingt? ;-) Wie du selbst bemerkt hast, hat er den Quarz nur bei einer i.O. Platine arbeiten sehen. Bei den n.i.O. Platinen ist Ruhe, deshalb hat er ja den Felsen selbst im Verdacht.
Gast
#5624282
@Georg G.: Hast Recht. Denkfehler :-)
Gast
#5624289
S. Landolt schrieb: > Meldet sich der ATmega644, wenn an XTAL2 ein Takt mit z.B. 1 MHz > zugeführt wird? Am Ausgang des Oszillators ein externes Signal einzuspeisen, dürfte keine so gute Idee sein. (DS Kap. 2.2.9 XTAL2 Output from the inverting Oscillator amplifier)
Gast
#5624292
Ausprobieren, Wolfgang, bei mir funktioniert es. Es soll ja auch kein regulärer Betriebszustand werden, sondern nur dazu dienen, den Fehler herauszufinden.
Gast
#5624296
S. Landolt schrieb: > Ausprobieren, Wolfgang, bei mir funktioniert es. > Es soll ja auch kein regulärer Betriebszustand werden, sondern nur dazu > dienen, den Fehler herauszufinden. Wolfgang hat Recht. Auch offiziell soll der Takt an XTAL1 eingespeist werden, steht auch so im Datenblatt... XTAL1: Eingang XTAL2: Ausgang
Gast
#5624297
S. Landolt schrieb: > Ausprobieren, Wolfgang, bei mir funktioniert es. Klar, wenn der Taktgenerator kräftig genug ist, überfährt er die Ausgangsstufe vom Oszillator. Aber es sollte doch nichts dagegen sprechen, den externen Takt am Eingang anzuschließen, ohne den Ausgang zu vergewaltigen?
Gast
#5624303
"Vergewaltigen"? Merkwürdiger Ausdruck für unser Metier. Aber vielleicht können wir uns darauf einigen, dass man beides, XTAL1 und 2, versuchen sollte.
Gast
#5624314
S. Landolt schrieb: > Aber vielleicht können wir uns darauf einigen, dass man beides, XTAL1 > und 2, versuchen sollte. Zumindest weiss man dann hinterher, woran der Oszillator gestorben sein könnte - auch ein Gewinn. ;-)
Gast
#5624315
S. Landolt schrieb: > "Vergewaltigen"? Merkwürdiger Ausdruck für unser Metier. Passt schon, der Ausdruck. Wenn du zwei Ausgänge aufeinander schaltest mit der Hoffnung, daß der stärkere gewinnt...
Gast
#5624317
Der Oszillator stirbt nicht. Hintergrund für den Versuch mit XTAL2: es könnte ja z.B. C17 fälschlicherweise mit 100 nF bestückt worden sein. (Wo ist eigentlich der erste Schwarzwälder, hat der sich ins Wochenende verabschiedet?)
Gast
#5624323
S. Landolt schrieb: > Hintergrund für den Versuch mit XTAL2: es könnte ja z.B. C17 > fälschlicherweise mit 100 nF bestückt worden sein. Das ließe sich mit hoher Wahrscheinlichkeit ausschließen, wenn man wüsste, ob die Platinen vom Automaten bestückt wurden oder einzeln in Heimarbeit gelötet wurden. Ein Blick auf eine funktionierende Platine könnte auch klären, ob es einen äußerlichen Unterschied zwischen den hoffentlich vorhandenen Abblockkondensatoren und den Quarzlastkondensatoren gibt.
Gast
#5624326
Bei Automatenbestückung passieren es keine Fehler? Aber okay, warten wir also, bis sich Marco K. zurückmeldet.
Gast
#5624566
Peter D. schrieb: > Einen CPU-Takt brauchen die AVRs nur bei ISP. Nein, einen "CPU-Takt" brauchen die AVRs zum Programmieren garnicht. Wenn, wäre es sowieso nur ein "MCU-Takt" und nein, auch den brauchen sie nicht. Die MCU steht beim Programmieren nämlich unabänderlich im Reset. Aus sehr naheliegenden Gründen... Was sie hingegen brauchen, ist ein IO-Takt. Und das liegt daran, dass halt die Programmierlogik genau damit betrieben wird (was wiederum daran liegt, dass bei den meisten (allen?) Devices Teile der regulär sowieso vorhandenen Peripherie beim ISP-Programmieren einfach "umgenutzt" werden. Bei Megas die ISP-Hardware, bei Tinys das USI. Spannend finde ich den Tiny13, der sich zwar per ISP programmieren läßt, aber nichtmal ein reguläres USI besitzt. Welcher Idiot hat da eine halbe handvoll Gatter gespart und den sowiese kaum für irgendwas nützlichen Tiny13 auch noch das letzte halbwegs attraktive Feature geklaut? > Er muß dann 4* höher sein, > als der ISP-Takt. Jepp. "Er" ist halt nur der IO-Takt, nicht der MCU/CPU-Takt. > Im Programmer werden sie aber im parallelen Modus programmiert, also > ohne Takt. Auch beim parallele Programmieren gibt es natürlich einen Takt. Er entspricht exakt dem Takt, der sich beim seriellen Programmieren nach der 1/8-Teilung des IO-Taktes ergibt. Der Rest der Programmierengine ist nämlich absolut identisch. Die Mitnutzung der ohnehin vorhandene Hardware gibt es aber auch hier. Nämlich all die Logik, die auch im Betrieb bei Zugriffen auf Flash, Fuses und EEPROM involviert ist. Allerdings: wie auch beim (De-)Serialisierungsteil der Programmierlogik verhält sie sich bei anliegendem Reset-Signal ein wenig anders als im Normalbetrieb.
Gast
#5624623
c-hater schrieb: > Auch beim parallele Programmieren gibt es natürlich einen Takt. Er > entspricht exakt dem Takt, der sich beim seriellen Programmieren nach > der 1/8-Teilung des IO-Taktes ergibt. Das muss natürlich korrekterweise heissen: 1/32.
Gast
#5624625
c-hater schrieb: > Spannend finde ich den Tiny13, der sich zwar per ISP > programmieren läßt, aber nichtmal ein reguläres USI besitzt. Vielleicht ist es auch besser so, die USI Schnittstelle ist nämlich ätzend, um es mal salopp auszudrücken.
Wo ist denn die Resetbeschaltung?
Gast
#5624687
S. Landolt schrieb: > Bei Automatenbestückung passieren es keine Fehler? Der Automat bestückt alle Platinen der Charge gleich, es sei denn, jemand hat in den Gurt mit den 15pF Kondensatoren ein paar mit 100nF eingeschmuggelt.