zum System: Ich habe einen ATMEGA128 mit 16MHz Quarz zwischen XTAL1 und XTAL2. Beide gehen über je 22pF gegen GND. Der Atemega 128 ist im Auslieferzustand auf interne Clock gesetzt. zum Problem: Der µC hat mit interner Clock funktionert. Jetzt habe ich mittels folgendem Programmer: AVRISP mkII Debug host 127.0.0.1 Debug port 4462 Serial number 000200213337 Connection com.atmel.avrdbg.connection.jungousb Firmware Version 1.17 Hardware Version 1 die Fusebits auf externen Quarz gesetzt: LOW: 0xFF HIGH: 0x19 Seit dem Programmieren ist der µC nicht mehr erreichbar und ich erhalte folgende Fehlermeldung in AtmelStudio 5.1 Timestamp: 2015-05-18 11:57:21.975 Severity: INFO ComponentId: 20000 StatusCode: 0 Unable to enter programming mode. Verify device selection, interface settings, target power and connections to the target device. 11:57:21: [ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.) AN XTAL1 kann ich den Takt mit dem OZI sehen. Was habe ich falsch gemacht? und viel Wichtiger wie bekomme ich das hin das ich wieder mit dem µC arbeiten kann? Ich hoffe ihr könnt mir helfen.
Ich meine mich zu erinnern, dass es einen Zusammenhang zwischen AVR Taktrate und ISP-Rate gab. Also vielleicht mal versuchen mit einer anderen ISP-Rate auf den AVR zuzugreifen.
icke schrieb: > Ich meine mich zu erinnern, dass es einen Zusammenhang zwischen AVR > Taktrate und ISP-Rate gab. ISP-Clk * 4 < CPU-Clk Edit: Da ich weder mit dem MKII noch dem Atmel Studio 5 arbeite: Bist du sicher, dass die Fuses dort nicht invertiert geschrieben wurden? Habe gerade die invertierte Version hier eingetragen: http://www.engbedded.com/fusecalc/ Dann könntest du wieder Zugriff erlangen, in dem du einen Takt von einem anderen µC oder einem Quarzoszillator an XTAL1 einspeist.
:
Bearbeitet durch User
Der_Bär schrieb: > HIGH: 0x19 Imho sieht das so aus als ob du ExtReset abgeschaltet u. DebugWire eingeschaltet hast. Dann ist afaik kein prog. über SPI mehr möglich. Ich benutze diese Einstellung immer um über DebugWire zu debuggen. Um die Bits zurück zu setzen muss man eine Debug-Session aufmachen und diese mit "Disable debugWIRe and Close" beenden. EDIT:!!!!!!!!! Vergiss den Quatsch den ich geschrieben hab! War beim flaschen Atmega!
:
Bearbeitet durch User
Max Mustermann schrieb: > Imho sieht das so aus als ob du ExtReset abgeschaltet u. DebugWire > eingeschaltet hast. Das schloss ich aus, da laut Datenblatt keine DebugWire-Bezeichnung am Reset-Pin liegt. Habe es aber aufgrund mangelnder vorheriger Suche nicht explizit erwähnt. Dazu habe ich mal gerade das Datenblatt nach "debug" und "ocden" durchsucht. Beides führte mich zu JTAG und dessen Debugging-Möglichkeiten. Es wird nur erwähnt, dass der Reset-Pin vom Debugger überwacht wird, um externe Reset-Quellen zu erkennen. - Eine Suche nach "debugwire" war erfolglos, weil wohl nicht vorhanden. Edit: Deinen Edit während meines Posts geschrieben. :D
:
Bearbeitet durch User
Marcel Papst schrieb: > ISP-Clk * 4 < CPU-Clk Ist mir bekannt. Keine der Frequenzen geht. Marcel Papst schrieb: > Edit: > Da ich weder mit dem MKII noch dem Atmel Studio 5 arbeite: > Bist du sicher, dass die Fuses dort nicht invertiert geschrieben wurden? > Habe gerade die invertierte Version hier eingetragen: > http://www.engbedded.com/fusecalc/ Ich habe meine FUSEbits hier berechnet und bin mir ziemlich sicher, ich sie richtig geschriben habe. Zumal ich an XTAL1 den TAKT mit dem OZI messen kann. Sollte es dann nicht gehen?
Alle (A)VCC, GND und PEN richtig angeschlossen?
Nochmal alles neu aufbauen und verdrahten, dann alle Verbindungen nochmals überprüfen und dann nochmal versuchen via ISP anzusprechen.
Wenn auf extrnen Clock eingestellt wurde hat man ja die Moeglichkeit des externen Clocks. Also einen Arbitrary Funktionsgenerator, oder ein Clockgenerator Modul dran anschliessen...
Ich habe gerade gesehen das ich aus versehen das OCDENbit mit gesetzt habe. Wie kann ich das Rückgängig machen?
Genau so, wie du es gesetzt hast. Dabei wäre aber erstmal zu klären, ob definitiv zu 100% 0x19 und 0xFF als Fuses gesetzt wurden, und nicht 0xE6 und 0x00. Bei letzterem erwartet der Controller einen Takt, wie er auf Seite 320 des Datenblatts beschrieben wird. Siehe Fig. 153 und Tab. 131.
1 | 2.7V - 5.5V 4.5V bis 5.5V |
2 | Trise 1.6µs Max 0.5µs Max |
3 | Tfall 1.6µs Max 0.5µs Max |
Du sagtest, dass du den Takt an XTAL1 messen kannst. Wie sieht der aus? Wie hoch ist die Amplitude? Periodendauer? (Also stimmen die 16MHz, von denen du redest?)
:
Bearbeitet durch User
Marcel Papst schrieb: > Genau so, wie du es gesetzt hast. Dabei wäre aber erstmal zu klären, ob > definitiv zu 100% 0x19 und 0xFF als Fuses gesetzt wurden, und nicht 0xE6 > und 0x00. Ich habe im avrstudio exat diese Werte eingestellt. Bzw. Sie sind über die hacken und dropdown so entstanden. Warum sollten sie dann invertiert sein? Ich mach morgen noch einmal eine Aufnahme mit dem ozi. Der erste Blick sah Ok aus, aber wenn ich jetzt drüber nachdenken ist die Amplitude zu klein und die Frequenz auch zu klein morgen mehr. Wenn ich wirklich das ocden bit gesetzt habe sollte ein programmieren über ISP nicht mehr möglich sein. Wie kann ich dann das fusebit setzen? Bzw. Wie kann ich ocd-debbuggen?
Verfuste ATMega kann man mit einem HV Programmer retten. Z.B. mit dem Atmel STK500 Board oder mit dem Atmega fusebit doctor
Der_Bär schrieb: > Warum sollten sie dann invertiert > sein? Tabellen 117, 118, 119, Seite 287 f. 0 (programmed) - 1 (unprogrammed) Der_Bär schrieb: > Wenn ich wirklich das ocden bit gesetzt habe sollte ein programmieren > über ISP nicht mehr möglich sein. Dazu habe ich im Datenblatt nichts gefunden. Ich würde sagen, dass der ISP-Zugang davon nicht beeinträchtigt wird. Kann das jemand anderes bestätigen? Der_Bär schrieb: > Wie kann ich ocd-debbuggen? JTAG Interface, wie im Datenblatt beschrieben, sofern JTAGEN aktiviert (0) ist. Siehe Seite 250. Aber warten wir mal mal morgen ab, wenn du dir das Oszi-Bild nochmal angeschaut hast. Wie gesagt, testweise kannst du es mal mit einem externen Takt versuchen, sonst hilft wahrscheinlich nur noch HVPP zum zurücksetzen der Fuses.
Guten Morgen, mit einem anderen OZI musste ich leider feststellen an XTAL1 und XTAL2 liegen ~0,8 V an mit einem Rechteckrauschen. Ich werde jetzt mal den externen Takt versuchen.
Mit externem Takt habe ich Ihn wieder zum Laufen bekommen. Danke für eure Hilfe.
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.