Servus, ich versuche einen ATMega128 mit einem AVR Dragon über ISP zu flashen. Der Mikrocontroller befindet sich auf einem MR-C3024 Board von einem Robonova (http://www.robonova.de/store/product.php?productid=16147). Dazu habe ich dann ein Anschlusskabel vom Dragon zum Board gebastelt. Das ganze lief lange Zeit auch einwandfrei und ließ sich problemlos flashen. Seit dem letzten Anschließen kommt beim flashen allerdings immer folgende Fehlermeldung: Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.) Beim lesen der Device Signature im Device Programming kommt folgender Fehler: Unable to enter programming mode. Please verify device selection, interface settings, target power and connections to the target device. Der ISP Takt ist unverändert bei 250kHz (der Mikrocontroller läuft mit 7,nochwas MHz) und das Kabel habe ich auch überprüft. Der Roboter arbeitet einzeln einwandfrei das letzte Programm ab und der AVR Dragon wird vom PC auch problemlos erkannt. So auf den ersten Blick scheinen beide also noch zu funktionieren. Hat jemand eine Idee, warum das Ganze jetzt plötzlich nicht mehr funktioniert?
Ich hatte es mal, dass beim programmieren mit einem Adapterkabel irgendwelcher Muell beim flashen mit reingekommen ist. Avrdude hat mir das mit einem verify error mitgeteilt. Danach ging nichts mehr mit ISP. Mit HV Programming die fuses wieder gerade gebogen und die Welt war in Ordnung. ju
> Dazu habe ich dann ein Anschlusskabel vom Dragon zum Board gebastelt.
Wie sieht selbiges denn aus?
Ist es wirklich auch die gleiche Platine, wo es schon mal gelaufen ist?
@Gubbel Habe mich dem letzt auch ISP und Jtag ausversehen abgeschaltet, da bleibt nur HV-Programmierung um die Fuses wieder zu setzen. Must halt einen 40poligen Sockel und Stiftleisten einlöten auf dem Dragon. Wie im Figur 11 verbinden und HVPP Programmieren wählen im Programmer. http://www.atmel.no/webdoc/avrdragon/avrdragon.SCKT3100A3.html Bissel gefummel aber hat geholfen.
Angehängte Dateien:
-
IMG_20121222_151522.jpg
1,8 MB
Erstmal vielen Dank für eure Antworten. Ich habe mal ein Bild von dem ganzen Aufbau angehängt. Wie funktioniert die HV Programmierung denn mit externen Boards? "To avoid damaging the Target Board, the AVR Dragon or both, it is recommended to only use HVSP mode on devices placed in the 28/40 pin DIP socket on the AVR Prototype area on the AVR Dragon." "Extreme care should be taken if using HVSP mode to program an AVR device on an external target. The HVSP lines do not have level converters, so it is important that the target board is powered by the AVR Dragon VCC header, and not using another power supply. In addition the AVR Dragon will apply 12V to the reset pin, so it is important that the target board is designed to handle 12V on this line." (http://www.atmel.no/webdoc/avrdragon/avrdragon.hvsp_description.html) Der Roboter und der Dragon gehören der Fachhochschule, von daher klingt das erstmal sehr abschreckend. Michael_ schrieb: > Ist es wirklich auch die gleiche Platine, wo es schon mal gelaufen ist? Ja, gleiche Platine, gleiches Kabel, da wurde nichts verändert. Funktioniert JTAG denn möglicherweise noch oder wird das immer mit ISP zusammen abgeschaltet.
>HV Programmierung denn mit externen Boards?
Lass das mal lieber sein, weil du dir das Board oder sogar den Dragon
zerschiessen kannst.
Also wenn du dir sicher bist das Fusebit SPIEN nicht angerührt zu haben
prüf noch mal dein Anschlusskabel.
HVPP würde ich nur machen wenn der Chip nicht aufgelötet ist und in
deinem fall ein Spezialadapter bräuchtest um den dann auf dem Dragon zu
stöpseln.
>Hat jemand eine Idee, warum das Ganze jetzt plötzlich nicht mehr >funktioniert? Kabelbruch? Kommt recht haufig vor wenn das ISP Kabel relativ viel bewegt oder gesteckt wird. Das bricht dann irgendwann am Pfostenverbinder. Man kann sich übrigends nicht per ISP das ISP wegfusen.
Klaus schrieb: > Fusebit SPIEN nicht angerührt Da habe ich auf jeden Fall nicht rumgespielt. Klaus schrieb: > prüf noch mal dein Anschlusskabel holger schrieb: > Kabelbruch? Ich habe das Kabel gerade nochmal ein zweites mal durchgemessen. Zwischen Dragon und Board gibt es einwandfreien Kontakt. Daran scheint es nicht zu liegen. Ich stehe hier völlig aufm Schlauch. Ideen?
Hast du mit dem Debugger von Atmel Studio auf der Zielhardware debuggt und nicht sauber beendet? D.h. ist evtl. noch die DWEN-Fuse gesetzt? In diesem Fall musst du noch einmal den Debugger anwerfen ( nur anwerfen, nicht losrennen lassen) und sauber beenden. Der entsprechende Befehl im Menü des Atmel Studios heißt sinngemäß "Debuggen beenden und DebugWire zurücksetzen"
Debuggen über ISP geht nicht beim Dragon. Wenn ich auf Start Debugging and Break klicke, kommt die Fehlermeldung, dass es nicht unterstützt wird. Debuggen beenden bleibt dann auch ausgegraut.
hmm, deine Fehlerbeschreibung hört sich dennoch an wie DWEN oder SPIEN verfused. Es gib hier einige Artikel zu diesem Thema. Hast du da schon geguckt? Beitrag "SPIen gelöscht durch AVR Dragon mittels debugWIRE ?" http://www.mikrocontroller.net/articles/DebugWIRE
Prinzipiell ja. Man kann jedoch das JTAG-Interface auch stilllegen (über die JTAGEN-Fuse). Atmel empfiehlt, das zu tun, wenn kein JTAG verwedendet werden soll. In dem Fall wird JTAG auch nicht funktionieren. Kommt auf nen Versuch an. Gerade nochmal Manual geguckt: ATmega128 hat kein DWEN-Fuse. D.h. damit könnte dann nur noch SPIEN rückgesetzt sein, das wiederum geht aber nicht über das SPI, damit man sich nicht selbst aussperrt. Wie hast du dir denn den SPI-Adapter gebaut? 6 Stecker auf die entsprechenden Pins des C3024 Board? Dann kannst du auf dieselbe Machart die JTAG-Pins anstöpseln. Wie hast du Reset angeschlossen? Das wird lt. Schematic vom Board nicht auf einen Pfostenstecker geführt? Andere Fehlerursachen könnten noch sein - zu geringe Spannung auf dem Zielsystem ( weniger als 2.7 V ) - Andere Komponenten, die die MOSI- MISO- oder SCK-Leitung treiben
katastrophenheinz schrieb: > Andere Fehlerursachen könnten noch sein > - zu geringe Spannung auf dem Zielsystem ( weniger als 2.7 V ) > - Andere Komponenten, die die MOSI- MISO- oder SCK-Leitung treiben Du bist da im Irrtum. Deshalb hatte ich weiter oben gefragt, ob es auf diesem Board schon funktioniert hatte. Der 128 wird nicht über MOSI/MISO programmiert. Rest steht im Datenblatt.
katastrophenheinz schrieb: > Gerade nochmal Manual geguckt: ATmega128 hat kein DWEN-Fuse. D.h. > damit könnte dann nur noch SPIEN rückgesetzt sein, das wiederum geht > aber nicht über das SPI, damit man sich nicht selbst aussperrt. D.h. verfused kann er eigentlich nicht sein? katastrophenheinz schrieb: > 6 Stecker auf die > entsprechenden Pins des C3024 Board? Dann kannst du auf dieselbe Machart > die JTAG-Pins anstöpseln. Ja genau, das werde ich versuchen. katastrophenheinz schrieb: > Wie hast du Reset angeschlossen? Neben dem µC ist ein Kontakt vorgesehen, da habe ich einen Pfostenstecker angelötet. katastrophenheinz schrieb: > zu geringe Spannung auf dem Zielsystem ( weniger als 2.7 V ) Das Board wird von einem seperaten Netzteil versorgt. Die Targetspannung wird ja auch problemlos erkannt (4,9V). Michael_ schrieb: > katastrophenheinz schrieb: >> Andere Fehlerursachen könnten noch sein >> - zu geringe Spannung auf dem Zielsystem ( weniger als 2.7 V ) >> - Andere Komponenten, die die MOSI- MISO- oder SCK-Leitung treiben > > Du bist da im Irrtum. Deshalb hatte ich weiter oben gefragt, ob es auf > diesem Board schon funktioniert hatte. > Der 128 wird nicht über MOSI/MISO programmiert. Rest steht im > Datenblatt. Ja, statt MOSI/MISO benutzt der µC Rx/Tx. Ich wüsste aber nicht was da plötzlich in die Quere kommen sollte. Mein Programm spielt da nicht rum. Beim flashen zuckt der Roboter auch immer mit allen Servos, auf den Ausgängen scheint also ein zufälliger Puls generiert zu werden. Nach so etwa 1 Sekunde resettet er sich dann wieder von selbst und das Programm läuft wieder. Vielleicht hilft das ja noch für die Fehlersuche.
dann wiederhole ich die frage von g457: Wie sieht denn dein selbstgebauter ISP-Adapter aus?
Weiter oben hatte ich schonmal ein Bild gepostet (http://www.mikrocontroller.net/attachment/163805/IMG_20121222_151522.jpg). Pinbelegung ist folgende: ISP -> CR3024 MISO -> TX (PE1) VTG -> VCC SCK -> SCK (PB1) MOSI -> RX (PE0) RESET -> RESET GND -> GND Halt einfach die entsprechenden 6 Pins verbunden.
> D.h. verfused kann er eigentlich nicht sein? lt. Atmel Datenblatt nicht. Gibt es noch andere Lasten oder Treiber an/auf den Leitungen von PE1, PE0 und PB1 die ggf die Signale vom ISP verfälschen? Wie ist die Kapazität des Elkos C4 ( lt. Datenblatt am Reset-Pin) ? Vielleicht zum Programmieren mal abklemmen oder durch einen kleineren ersetzen Wenn du damit nicht weiterkommst, dann würde ich es über den JTAG-Adapter versuchen. Oder von einem Kumpel einen anderen Programmierer ausleihen.
Der Quarz schwingt? Trotzdem schon mal mit kleineren Geschwindigkeiten als 250KHz probiert? Gruß Jobst
katastrophenheinz schrieb: > Gibt es noch andere Lasten oder Treiber an/auf den Leitungen von PE1, > PE0 und PB1 die ggf die Signale vom ISP verfälschen? Nein, ich denke nicht. katastrophenheinz schrieb: > Wie ist die Kapazität des Elkos C4 ( lt. Datenblatt am Reset-Pin) ? > Vielleicht zum Programmieren mal abklemmen oder durch einen kleineren > ersetzen Laut Schaltplan (http://davidbuckley.net/DB/RoboNova/RoboNova_files/C3024.jpg) sinds 10mF. Da das nicht mein Board ist, möchte ich da aber erstmal nicht dran rumlöten. Jobst M. schrieb: > Der Quarz schwingt? Ja sicher, der Roboter läuft ja mit dem alten Programm einwandfrei. Jobst M. schrieb: > Trotzdem schon mal mit kleineren Geschwindigkeiten als 250KHz probiert? Ja, hilft auch nichts. So, ich habe jetzt JTAG mal ausprobiert. Funktioniert leider genauso wenig: [ERROR] JTAGID not valid. Debugger command enterProgMode failed., ModuleName: TCF (TCF command: Device:startSession failed.) bzw. Unable to enter programming mode. Please verify device selection, interface settings, target power and connections to the target device. -------------------- Wild zappeln tut der Roboter allerdings nur wenn die Reset-Leitung angeschlossen ist (ist bei JTAG wohl optional). Das Problem scheint also irgendwie mit diesem Reset zu tun zu haben. Das debugWire läuft ja wohl auch darüber. Aber gibt es debugWire bei dem µC überhaupt? Im Datenblatt ist dazu nichts zu finden.
>> Wie ist die Kapazität des Elkos C4 ( lt. Datenblatt am Reset-Pin) ? >> Vielleicht zum Programmieren mal abklemmen oder durch einen kleineren >> ersetzen >Laut Schaltplan >(http://davidbuckley.net/DB/RoboNova/RoboNova_files/C3024.jpg) sinds >10mF. Der Kondensator ist viel zu groß. Löt den mal aus. >Aber gibt es debugWire bei dem µC überhaupt? Beim ATMega128 gibt es das nicht.
Gubbel schrieb: > MISO -> TX (PE1) > VTG -> VCC > SCK -> SCK (PB1) > MOSI -> RX (PE0) > RESET -> RESET > GND -> GND > > Halt einfach die entsprechenden 6 Pins verbunden. Aber falsch. TX und RX sind nicht die richtigen Anschlüsse. Benutze MISO und MOSI! Gruß Jobst
Jobst M. schrieb: > Gubbel schrieb: >> MISO -> TX (PE1) >> VTG -> VCC >> SCK -> SCK (PB1) >> MOSI -> RX (PE0) >> RESET -> RESET >> GND -> GND >> >> Halt einfach die entsprechenden 6 Pins verbunden. > > Aber falsch. TX und RX sind nicht die richtigen Anschlüsse. Benutze MISO > und MOSI! > > > Gruß > > Jobst Nein, beim Atmega128 sind es TX/RX. Wurde weiter oben ja auch schon geschrieben. holger schrieb: > Der Kondensator ist viel zu groß. Löt den mal aus. Ist er das denn wirklich? Ich meine, das ist ja keine daheim gebastelte Schaltung. Da wird sich doch sicherlich jemand was bei gedacht haben oder nicht? An dem Kondensator hat sich ja eigentlich auch nichts getan und es lief vorher immer einwandfrei. Ich würde nur gerne den Grund verstehen bevor ich da dran rumfummel.
Gubbel schrieb: > Nein, beim Atmega128 sind es TX/RX. Wurde weiter oben ja auch schon > geschrieben. Eieiei... stimmt ja :-/ Du hast RX und TX nicht vertauscht? RX wird ja auf dem Board als ETX und TX als ERX benannt ... Gubbel schrieb: >> Der Kondensator ist viel zu groß. Löt den mal aus. > Ist er das denn wirklich? Ich meine, das ist ja keine daheim gebastelte > Schaltung. Da wird sich doch sicherlich jemand was bei gedacht haben > oder nicht? An dem Kondensator hat sich ja eigentlich auch nichts getan > und es lief vorher immer einwandfrei. > Ich würde nur gerne den Grund verstehen bevor ich da dran rumfummel. Sind das denn wirklich 10mF (das wäre ein riesen Klopper an Elko) Edit: Wieso ist das eigentlich der einzige Kondensator, bei dem ein Wert dabei steht? Gruß Jobst
Hast du Reset Taster am Board? du kannst versuchen den µC in reset halten und gleichzeitig flashen und gucken ob es geht, shaue mal hier: Beitrag "Re: AVRISPmkII blink orange!!" katastrophenheinz: > Wie ist die Kapazität des Elkos C4 ( lt. Datenblatt am Reset-Pin) ? > Vielleicht zum Programmieren mal abklemmen oder durch einen kleineren > ersetzen holger schrieb: > Der Kondensator ist viel zu groß. Löt den mal aus. Das kann die Lösung sein. Ab hier lesen: Beitrag "Re: AVRISPmkII blink orange!!" Gruß
Hast du noch einen weiteren, fabrikfrischen atmel controller bei dir rumliegen? Um auszuschließen, daß das dragon-board ( bzw die pc-software dahinter ) die fehlerquelle ist: Den fabrikfrischen Controller auf einem Breadboard (oder fliegend verdrahtet) mit Vcc und GND versorgen, die 4 ISP-Pins anschließen, ISP-Frequenz kleiner < 250kHz und Signatur auslesen. Wichtig ist, daß der Controller ( die Fuses ) im Auslieferungszustand ist, d.h. interner Oszillator und CKDIV8 gesetzt, SPIEN gesezt und DWEN nicht. Wenn Signatur auslesen dann auch deine obige Fehlermeldung produziert, dann liegt der Fehler wahrscheinlich im Dragon ( bzw. in der PC-Software dahinter ). (Wenn kein fabrikfrischer Controller in der Bastelkiste: ein ganz normaler Arduino oder irgendwas anderes mit ISP-Adapter tuts auch) Hast du weiterhin schon mal probiert, beim Programmieren über ISP die ISP-Frequenz auf <sehr niedrig> einzustellen. Ich bin mir nicht sicher, wie sich das aufs Timing der Reset-Leitung auswirkt, aber vielleicht bringt das auch beim Runterziehen der Reset-Leitung mehr Zeit, um C4 zu entladen. Falls das alles keine weiteren Erkenntnisse bringt, dann würde ich tätsächlich als nächstes den C4 auslöten.
katastrophenheinz schrieb: > dann würde ich > tätsächlich als nächstes den C4 auslöten. Ich würde erst mal gucken, was für einen Wert der tatsächlich hat. 10mF (=10.000µF) kann ich mir nicht vorstellen! Gruß Jobst
Angehängte Dateien:
-
2012-12-28_13.23.08.jpg
360 KB
Martin e. C. schrieb: > Hast du Reset Taster am Board? du kannst versuchen den µC in reset > halten und gleichzeitig flashen und gucken ob es geht, Einen Taster nicht, nur ein Lötauge (siehe Bild unten rechts). Ich hab einfach ein Kabel nach GND angesteckt. Beim Flashen kommt allerdings der selbe Fehler wie vorher, sowohl über ISP als auch JTAG. Nur Zappeln tut er nicht. Zum Kondensator, auf dem Bild ist er drauf. Mit einer 10 ist er auch beschriftet, aber ob das jetzt mF oder wohl eher µF sind weiß ich nicht. Er ist so etwa 4x4mm² in der Grundfläche. Aber wenn ich Reset dauerhaft auf GND halte, sollte der Kondensator doch eigentlich keine Rolle mehr spielen? katastrophenheinz schrieb: > Hast du noch einen weiteren, fabrikfrischen atmel controller bei dir > rumliegen? Ich hab noch einen AVR32 auf einem EVK1100 Testboard, da ist zumindestens JTAG als Schnittstelle herausgeführt. Das werde ich als nächstes mal ausprobieren.
Als zusaetzliche Fehlerquelle.. eine Gleichtaktspannung zwischen Programmierer, resp PC und dem Board, speziell wenn da noch anderes Zeug dran haengt.
Problem gefunden! Am IC waren waren 2 Beinchen verbunden, PEN und RX. Habs gerichtet und es funktioniert wieder einwandfrei. Danke für eure Hilfe.
Thread beobachten
Seitenaufteilung abschalten
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.