Bist du sicher, dass beim AVR nicht die externe Clock ausgewählt ist, extern aber kein Quarz-/Oszillator dran ist? Dann müsstest du der Schaltung entweder eine externe Clock geben oder aber den µController austauschen...
Hast du nicht mal eine andere µController-Schaltung, bei der du mal testen kannst, ob du Kontakt bekommst!?
Hi,
nein, so wird das nichts. Einfach bei 'Program' auf 'Erase Device' klicken.habe bei "Auto" ein Häckchen bei "Erase Device" gesetzt
Gruß m.a.r.v.i.n
Ach so.
Aber leider ändert das nichts an dem Problem: Immer noch die gleiche Fehlermeldung.
Du hast jetzt aber nur auf den letzten Post geantwortet, oder?!
Oh, sorry ich hatte dich glatt übersehen.
Also ich habe einfach die Grundschaltung ohne externen Oszillator aufgebaut:
https://www.roboternetz.de/wissen/im...ung_mitisp.gif
Wobei ich natürlich die Pinbelegung des Steckers angepasst habe.
Eigentlich sollte das doch laufen, da der AVR doch (soweit ich weiß) von der Fabrik her auf den internen Oszillator mit 1MHz eingestellt ist. Und umstellen kann ich den Controller ja erst garnicht, denn der will ja noch nichteinmal die Fuses auslesen.
Ich hab jetzt auch ein ganz neues Kabel gebastelt, aber das ändert auch nichts an dem Problem. Langsam fürchte ich, dass der AVRISP einfach defekt ist. Denn der AVR ist fabrikneu und sollte deshalb ja wenigstens erkannt werden, der ISP hat die neueste Firmware, und die Kontroll-LEDs leuchten auch beide grün.
Übrigends: Ich habe gerade einfach mal den AVR aus der Schaltung rausgenommen. Die Fehlermeldung war exakt die gleiche, wie die als der AVR noch in der Schaltung war. Das heißt für mich: Der ISP hat erst garnicht gemerkt, dass da überhaupt ein Controller angeklemmt war.
Dummerweise habe ich keinen zweiten AVR hier, sonst könnte ich ja Testen, ob der erkannt wird. Falls nein müsste nämlich - was auch meine Vermutung ist - der ISP defekt sein.
Nach langer Zeit habe ich nochmal versucht meinen ISP ans laufen zu bekommen. Diesmal mit einem neuen mega32. Die Fehlermeldung taucht nicht mehr auf, und ich kann den Controller programmieren. Jedenfalls erhalte ich folgende Meldungen:
Reading FLASH input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH .. OK!
Reading FLASH .. OK!
FLASH contents is equal to file.. OK
Leaving programming mode.. OK!
Sieht also alles nach einem erfolgreichen Vorgang aus.
Das einzige Problem, dass ich jetzt habe, ist das das oben genannte Programm nicht zu laufen scheint. Jedenfalls kann ich kein Flackern bei der LED feststellen. Ich habe dann mal nachgemessen (mit dem Multimeter, habe leider kein Oszilloskop) und nur feststellen können dass an allen Ports eine Ausgangsspannung von 3,8V anliegt. Ich hab dann auch mal versucht einen Port konstant auf 0xFF oder 0x00 zu legen, mit dem gleichen Ergebnis. Ich nehme an, dass das Programm erst garnicht gestartet wird, aber was mache ich falsch? Ist der Code nicht in Ordnung?
Hallo Gandalfx86
dein Programm schaltet sehr schnell dein Port C ein- und aus, weil du keine (Zeit)Schleife eingebaut hast. Den Wechsel wirst du mit einem Multimeter nicht erfassen können.
Natürlich müsste das Programm dann auch auf dein Controller übertragen werden können. Probiere doch auch nochmal die Fuses auszulesen um zu sehen, ob du mit den Controller kommunizieren kannst.
Gruß Gucky.
Wissen ist Macht, nichts Wissen macht nichts !
Die Kommunikation mit dem Controller läuft ohne Probleme. Nur der Controller scheint das Programm, dass ich in den Flash lade nicht zu starten. Die Einstellung der Fuses habe ich mal angehangen.
Ich habe jetzt mal dieses Programm verwendet:
Nun sollte man ja eigentlich annehmen, dass nach dem Verbinden mit dem Netzteil an den Pins von Port A und B Low-Pegel anliegen, und an Port C High-Pegel. Das Ergebnis ist aber das selbe wie vorhin: überall (nach Anzeige des Multimeters) 3,84V. Mir ist schon klar, dass ein Multimeter nicht das richtige Werkzeug dafür ist, aber da ja hier konstante Ausgangssignale anliegen sollten müsste man ja wenigstens einen Unterschied bei den B Ports und C feststellen können, was aber nicht so ist.Code:.NOLIST .INCLUDE "m32def.inc" .LIST .CSEG MAIN: LDI R16,0b11111111 OUT DDRA,R16 OUT DDRB,R16 OUT DDRC,R16 LOOP: LDI R16,0x00 OUT PORTA,R16 OUT PORTB,R16 LDI R16,0xFF OUT PORTC,R16 RJMP LOOP RJMP MAIN
Als Schaltung verwende ich im übrigen einfach die Minimalbeschaltung mit 100nF Abblockkondensator und 1K Widerstand auf einem Steckbrett aufgebaut. An der Schaltung dürfte es ja eigentlich nicht liegen.
Hallo Gandalfx86
Dein AVRISP MKII kenne ich zwar nicht aber es wird sich hierbei auch um einen ISP-Programmieradapter handel. Ich selber benutze einen selbstgebauten, den ich mit Ponyprog2000 bediene, was aber vom Programierablauf das gleiche sein dürfte.
Nur mit einem Multimeter an einem Prozessor zu messen ist zwar nicht so das gelbe vom Ei, aber vieleicht kann ich dir ein paar Tips geben, damit du die mögliche Fehlerquelle etwas einkreisen kannst.
Hierzu kannst du mit dem Multimeter an den Anschlüssen 6 (MOSI), 7 (MISO), 8 (SCK) und 9 (Reset) den Pegel jeweils gegen GND messen und merken. Während der Programmübertragung sollten sich diese Pegel verändern. Besser kann man das ganze mit LED's beobachten. Hierzu habe ich die Kathode einer LED an den jeweiligen Ausgang des Controllers und die Anode über einen 1K-Widerstand nach VCC(+5V) angeschlossen.
Nach der Programmübertragung sollte der Reset/-Pin (9) auf +5V liegen. Möglicherweise muß hier für den Normalbetrieb noch die ISP-Schnittstelle von deiner Anwendung abgezogen werden.
Sollte alles so sein könnte es an dem Controller liegen, aber der ist ja glaube ich neu. (ATMEGA32-DIP?)
Melde dich nochmal, auch wenn ich dir nicht weiterhelfen konnte.
Gruß Gucky.
Wissen ist Macht, nichts Wissen macht nichts !
ganz genauDein AVRISP MKII kenne ich zwar nicht aber es wird sich hierbei auch um einen ISP-Programmieradapter handel.
werde ich am Wochenende mal versuchen, falls ich zwischen dem Klausur-Lernen noch dazu komme(bin leider grad nicht zuhause, und kann das also nicht ausprobieren)Hierzu kannst du mit dem Multimeter an den Anschlüssen 6 (MOSI), 7 (MISO), 8 (SCK) und 9 (Reset) den Pegel jeweils gegen GND messen und merken. Während der Programmübertragung sollten sich diese Pegel verändern. Besser kann man das ganze mit LED's beobachten. Hierzu habe ich die Kathode einer LED an den jeweiligen Ausgang des Controllers und die Anode über einen 1K-Widerstand nach VCC(+5V) angeschlossen.
Nach der Programmübertragung sollte der Reset/-Pin (9) auf +5V liegen
habe ich sowieso immer gemacht, und dann von der Stromversorgung getrennt und neu verbundenMöglicherweise muß hier für den Normalbetrieb noch die ISP-Schnittstelle von deiner Anwendung abgezogen werden.
fabrikneu von Reichelt (der erste, den ich verwendet hatte war ebenfalls fabrikneu, lässt sich mit meinem ISP aber erst garnicht ansprechen)Sollte alles so sein könnte es an dem Controller liegen, aber der ist ja glaube ich neu. (ATMEGA32-DIP?)
werde ich machen; vielen Dank schonmal für die HilfeMelde dich nochmal, auch wenn ich dir nicht weiterhelfen konnte.
Wie sieht eigentlich der Flash nach den Programmieren aus? Ich hatte nämlich den Flash nach dem Programmieren mal ausgelesen, und mit der hex-Datei verglichen. Dabei kann man im oberen Teil der ausgelesenen Datei irgendwie ein paar Bruchstücke aus der Datei die vom Assembler erstellt wurde erkennen. Es kann natürlich sein dass das nur Standardcode ist der da immer steht, aber vielleicht kann man ja an der Datei sehen, ob das Programm richtig übertragen wurde. Ich habe die Dateien mal angehangen.
Berechtigungen
Zitieren
Lesezeichen