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).
