Hallo, Der JTAGICE3 unter AtmelStudio6 macht bei mir Zicken: Beim Device Signature Read bringt er: "Unable to enter programming mode.Please verify device selection, interface settings, target power and connections to the target device." Die Kommunikation zumm ATMega16 funktioniert nur, wenn ich die Option "use external reset" anklicke, das AtmelStudio merkt sich diese Option nicht, muss man jedesmal aufs Neue anklicken, wenn ich das Programm beim Debuggen stoppe, dann bricht auch die Kommunikation weg, mit Hilfe der Option "external reset" stelle ich die Verbindung wieder her aber die erneute Debug-Session bricht AtmelStudio mit einer Fehlermeldung ab: "Atmel Studio was unable to start your debug session. Please verify device selection, interface settings, target power and connections to the target device." da komm ich nur weiter wenn ich den ATMega16 neu programmiere, das ganze Verhalten ist immer reproduzierbar, mit AVRISPII hatte ich keine Probleme ein weiteres Problem ist, dass der debugger sich beim durch-steppen beim _delay_ms aufhängt bei dem Kommando: __builtin_avr_delay_cycles(__ticks_dc); Programmer: JtagIce3 (FW:3.8) AtmelStudio 6.1.2730 SP2 (Win7) Device: ATMega16L (Vdd=3.3V) 4MHz Quarz, Schaltung ist auf Steckboard aufgebaut, mit kurzen Leitungen JTAG Stecker/ ATMega16 1-TCK 24-TCK 2-GND GND 3-TDO 26-TDO 4-VTREF 3.3V 5-TMS 25-TMS 6-nSRST 9-RESET(10k/Vdd) 7- - 8- - 9-TDI 27-TDI 10-GND GND Fuses: High: 0x19 Low: 0xCC OCDEN (x) das Atmel-Studio merkt sich nicht diese Einstellung, muss ich jedesmal neu anklicken JTAGEN (x) SPIEN (x) BOOTSZ(1024W_1C00) SUT_CKSEL(EXTMEDFXTALRES_258CK_4MS) (mit internem Oszillator hatte ich die gleichen Probleme) sind das alles bekannte Probleme ? Gruss, Andreas
Andreas R. schrieb: > Der JTAGICE3 unter AtmelStudio6 macht bei mir Zicken: > Beim Device Signature Read bringt er: > "Unable to enter programming mode.Please verify device selection, > interface settings, target power and connections to the target device." JTAG-Takt zu hoch? Zum Programmieren kann der beliebig schnell sein, aber Debuggen kann man nur, wenn er kleiner als F_CPU/4 ist. > Die Kommunikation zumm ATMega16 funktioniert nur, > wenn ich die Option "use external reset" anklicke, Geht dein Programm irgendwie in einen SLEEP? Daraus kann der normale JTAG-Reset ihn nicht befreien, da braucht man den Externreset. > da komm ich nur weiter wenn ich den ATMega16 neu programmiere, > das ganze Verhalten ist immer reproduzierbar, mit AVRISPII hatte ich > keine Probleme Naja, mit dem kannst du aber auch nicht debuggen, das ist eine ganz andere Liga. :-) Rein programmieren könntest du sicher auch mit dem JTAGICE3 ohne Probleme. > ein weiteres Problem ist, dass der debugger sich beim durch-steppen beim > _delay_ms aufhängt bei dem Kommando: > __builtin_avr_delay_cycles(__ticks_dc); Nö, das braucht nur ewig. Er muss sich maschinenbefehlsweise durch die Schleife hangeln, bis der PC einen Wert erreicht, der hinter der Schleife (und damit auf der nächsten C-Code-Zeile) liegt. Wenn du zwischendurch die Zählerregister der Schleife auf knapp über 0 setzt, beendet sie sich dann ganz schnell. ;-) Entweder gar keine Delays benutzen ;), oder sie zum Debuggen per #ifdef rausnehmen, ansonsten dann lieber mit "Run to cursor" oder sowas drüber hinweg gehen, sodass die Schleifen in Echtzeit laufen können. > OCDEN (x) das Atmel-Studio merkt sich nicht diese Einstellung, muss ich > jedesmal neu anklicken Ich nehm' zwar kein Atmel Studio, aber das würde mich wundern: diese Fuse setzen sie seit Jahr und Tag selbst, wenn man eine Debugsitzung startet, und löschen sie aber vermutlich hinterher genauso penetrant wieder. Aber das ist ja auch OK, wenn man nicht debuggt, muss man die auch nicht haben (kostet nur Strom, weil der Oszillator nicht ausgehen kann dann beim SLEEP).
Danke Jörg, das hat die meisten Fragen beantwortet Jörg Wunsch schrieb: > Andreas R. schrieb: > > JTAG-Takt zu hoch? CPU Takt: 4MHz Programmiertakt: 1MHz, Debugger: 500kHz (also 1/8 vom CPU Takt) >> Die Kommunikation zumm ATMega16 funktioniert nur, >> wenn ich die Option "use external reset" anklicke, > Geht dein Programm irgendwie in einen SLEEP? Daraus kann der normale > JTAG-Reset ihn nicht befreien, da braucht man den Externreset. weiter hinten im Ablauf geht es schon in den Sleep-Mode, aber bis dahin hab ich nicht durchgesteppt
Jörg Wunsch schrieb: >> OCDEN (x) das Atmel-Studio merkt sich nicht diese Einstellung, muss ich >> jedesmal neu anklicken > > Ich nehm' zwar kein Atmel Studio, aber das würde mich wundern: diese > Fuse setzen sie seit Jahr und Tag selbst, wenn man eine Debugsitzung > startet, und löschen sie aber vermutlich hinterher genauso > penetrant wieder. Aber das ist ja auch OK, wenn man nicht debuggt, > muss man die auch nicht haben (kostet nur Strom, weil der Oszillator > nicht ausgehen kann dann beim SLEEP). Es sieht wirklich so aus als ob das AtmelStudio die OCDEN Fuse nach dem Ende der Debug Sitzung löscht, vor der nächsten Sitzung muss man die wieder anklicken und die Fuses neu programmieren, echt lästig..
Andreas R. schrieb: > Programmiertakt: 1MHz, > Debugger: 500kHz (also 1/8 vom CPU Takt) Sollte passen. Programmiertakt darf auch viel höher sein. > weiter hinten im Ablauf geht es schon in den Sleep-Mode, aber bis dahin > hab ich nicht durchgesteppt Ab da, wo er frei läuft, wird der aber erreicht. Meiner Erfahrung nach (nicht nur mit dem JTAGICE3) ist es zuweilen besser, wenn man fürs Debuggen die SLEEPs rauswirft. Andreas R. schrieb: > vor der nächsten Sitzung muss man die wieder anklicken und die Fuses neu > programmieren Das wiederum ist seltsam, das haben sie früher wirklich immer von allein gemacht (und selbst AVaRICE hat sich das so abgeguckt).
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.