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.
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!
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
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?
Wenn auf extrnen Clock eingestellt wurde hat man ja die Moeglichkeit des
externen Clocks. Also einen Arbitrary Funktionsgenerator, oder ein
Clockgenerator Modul dran anschliessen...
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?)
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?
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.
