Atmega644PA lässt sich nicht debuggen

[Hemi]

Tach zusammen,

mein Atmega644PA im Testsocket macht ganz komische Sachen. Und zwar, die Fuses lassen sich problemlos auslesen und setzen, kein Problem. Auch die Signatur lässt sich auslesen.

Sobald ich aber ein Programm debuggen will, kommt er nicht über die erste Zeile im Main() drüber. Wenn ich auf F5 drücken, legt er los und langet sofort wieder auf der ersten Zeile.

Ich habe dann geschaut ob ein PullUp am /RESET-Pin vorhanden ist, nein, ist keiner da. Also habe ich +5V mit dem /RESET-Pin verbunden. Es hat jedoch nichts gebracht.

Hier das Programm:

/*
 * TestAtmega644PA.c
 *
 * Created: 29.11.2012 21:32:37
 *  Author: Heinrich
 */ 

#include <avr/io.h>
#include <avr/interrupt.h>


ISR (TIMER1_OVF_vect) {
	PORTA  ^= (1 << PA7);
	TCNT1 = 57600;
}

void init_timer1(void);

int main(void) {
	
	DDRA = 0b11111111;		// alles ausgänge
	
	init_timer1();
		
    while(1) {
		/*PORTA  ^= (1 << PA7);*/
    }
}

void init_timer1(void) {
	
	TCCR1B = (1 << CS12);
	TIMSK1 = (1 << TOIE1);
	
	TCNT1 = 57600;
	
	sei();
}

Also einfacher geht es echt nicht. Er kommt wie gesagt nicht über DDRA drüber.

Wenn ich das gleiche Programm auf den Atmega644 in meinem anderen Board flashe, funktiniert alles 1A.

Ideen?

Achso, Debugger ist ein Dragon und die IDE ist AtmelStudio 6.

Danke & Grüße
Heinrich

 

[Hemi]

Hallo Leute,

hat keiner eine Idee?

Grüße
Heinrich

 

[LotadaC]

Es geht um Hardware-Debugging via JTAG oder debugWire oder sowas?
Damit hab ich keine Erfahrungen - sind da nicht irgendwelche Fuses zu setzen?

Oder geht es um Software-Debugging im Simulator? Dann ist wiederum C nicht meine Sprache.
Allerdings vermute ich, daß die leere Schleife "while(1){}" komplett wegoptimiert wird - kannst Du da mal ein NOP oder sowas einbauen? nein, das macht eigentlich keinen Sinn - dann würde es in dem anderen Board ja dasselbe sein...

 

[Hemi]

Hi,

ja, es geht um Hardware-Debugging mit einem AVR Dragon über JTAG.

Die Fuses sind wie folgt gesetzt:



Also, ich meine die Fuses sind richtig gesetzt.

Im Socket steckt ein 10MHz Quarz. Die F_CPU ist über "Project properties" -> "Toolchain" -> "Symbols" -> "F_CPU=10000000UL"

Danke & Grüße
Heinrich

 

[dino03]

Hallo Heinrich,

ich hab leider auch noch nichts mit JTAG oder DebugWire gemacht.
Ich kann also auch nicht weiterhelfen

Gruß
Dino

 

[Hemi]

Hallo zusammen,

ich habe gestern noch etwas rumgesucht und ich meine, dass die MCU sich ständig resettet. Es ist zum Beispiel auch nicht jedes Mal möglich eine Debugging-Session zu starten. Also absolut komisch das Ganze.
Der Sockel wird am USB-Port angeschlossen und wenn ich die Fuses auslese und so, kann ich ja auch die Spannung vom Target auslesen, da steht 5,1v aber das dürfte nicht das Problem sein, hoffe ich zumindest. Einen Widerstand am /Reset-Pin hat das Ding auch bekommen, das hat die Situation aber auf keinster Weise verändert. So ein Mist aber auch.

Ich habe eine LED über Timer blinken lassen und habe dann die Periodendauer gemessen mit dem LA, sie sollte 1s sein und es stimmt auch. Sprich ISR löst sauber aus.

Sehr komisch das Ganze.

Ich nehme mal heute Abend eine andere MCU zum testen und schaue was da los ist. Vielleicht hat ja die MCU eins weg.

Grüße
Heinrich

 

[LotadaC]

Auch wenns Dir bei Deinem Problem nicht weiterhilft, versuch ich mal, Dein Programm zu verstehen:
-Du inkludierst irgendwelche CodeTeile, die was mit den I/O-Registern (welches Controllers?) und der Interruptvektortabelle zu tun haben.
-Durch die folgende ISR (TIMER1_OVF_vect){code} wird einerseits der enthaltene Code der ISR festgelegt, andererseits der Timer-1-Überlauf-Interruptvektor mit einem Sprung dahin versehen, korrekt?
-PORTA wird zum Ausgang
-Danach rufst Du eine Subroutine auf, in der der Timer 1 initialisiert wird, und die Interrupts global freigegeben werden (warum eigentlich hier?).
Timerinit ist:
--WGM=0 (Waveform Generation Mode 0), also normaler single slope, Überlauf bei MAX=TOP=2^16=0xFFFF=65536 dec
--beide Output Compare Pins sind normale I/Os (OC-Mode=0)
--Als Takt wird der MCU Takt durch 256 geteilt (Prescaler) - ab dem Moment läuft der Timer (ab 0) los
--Der Überlauf-Interrupt wird freigegeben
--danach schneidest du die ersten 57600 Schritte ab (das wiederholst Du später in der TOV-ISR)
--zuletzt wie gesagt die globale Interruptfreigabe
-dann sollte das Programm in eine leere Endlosschleife laufen...
wenn der Timer überläuft, wird:
-PORTA.7 mit 1 ver-XOR-t - effektiv also das eine Bit getoggelt
-anschließend wieder die ersten 57600 Timertakte abgeschnitten

Unterm Strich hast Du also den Timer (in der ISR in Software) auf in etwa 7935 Takte begrenzt; bei jedem Überlauf Toggelt die LED. Das wäre bei 1MHz Takt ca(!) alle 2 Sekunden. Warum so umständlich?
-Du kannst den Timer auch in Hardware auf 7935 Takte begrenzen - dann läuft er automatisch über (CTC). Entweder über das ICR (WGM=12), oder über das OCR1A (WGM=4).
-Das verXORren macht im Hintergrund:
--I/O-Register (PORTA) aus dem I/O-Space in ein Rechenregister laden (1 Taktzyklus)
--Da es kein EOR mit Immediate gibt, muß die Bitmaske (10000000bin) in ein anderes Register geladen werden (1 Taktzyklus)
--das EOR (1 Taktzyklus)
--Ergebnis zurück in den I/O-Space kopieren (1 Taktzyklus)
Außerdem müssen die verwendeten beiden Register gerettet und wiederhergestellt werden (zusammen 8 Taktzyklen)
Da EOR das SREG manipuliert, ist auch dieses zu retten (und wiederherzustellen) (zusammen 6 Takte)
(zusätzlich bisher noch der Reload des Timers, aber da hatte ich ja schon was geschrieben)
Insgesamt also in der ISR 18 Takte (zuzüglich Ein- und Austritt)
Du kannst den Pin aber auch toggeln, indem Du eine 1 in das korrespondierende PIN-Register-Bit schreibst. Da die entsprechenden Register im "priveligiertem" I/O-Space bis 0x1F liegen, lautet die ASM Instruktion dafür:
SBI PINA,PINA7 (1 Taktzyklus).
Da keine Register, und auch nicht das SREG manipuliert werden, käme nur noch der ISR-Ein- und -Austritt hinzu.

Alternativ könnte man statt PORTA.7 auch einen der PWM-Pins nehmen, und den entsprechenden COM=1 (Compare Output Mode) setzen. Dann toggelt der beim Compare-Match (was man bei WGM=4 mit OCR1A ja zum festlegen des Überlaufs verwendet). Das geschieht dann komplett im Hintergrund, es muß nicht mal ein Interrupt ausgelöst werden. Dann kannst Du auch die MCU schlafen schicken (in den Idle-Mode).

Aber wie gesagt - das hat nichts mit Deinem Problem zu tun...

 

[Hemi]

Das Programm hat mit Realität nichts zu tun. Es ist einfach nur ein Test, ob alles sauber läuft, nicht mehr und nicht weniger.

Die sei() kann man genau so in die main() packen, es spielt keine Rolle in dem Fall. Wenn man aber mehrere Sachen mit Interrupts konfiguriert sollte man es lieber in die main() packen nachdem man alles initialisiert hat, hier ist es eal.

Die Zuweisung TCNT1 = XYZ ist das Vorladen. Ab dem Wert XYZ zählt der Timer hoch und wenn er den oberen Wert erreicht, fliegt die ISR und er landet in der ISR drin, wo er die LED umschaltet und den Preload setzt. Dann geht es weiter.

Die MCU läuft mit 14,7456MHz.

Wie man es macht ist absolut egal, es gibt immer mehrere Wege, die zum gleichen Ziel führen. Ob es jetzt 8 oder 800 Takte dauert, spielt nur dann eine Rolle, wenn man die MCU vollständig ausreizt und das wird kaum einer hier machen. Wie gesagt, mit Realität hat das Beispiel nichts zu tun.

Grüße
Heinrich

 

[Hemi]

Hallo Leute,

ich habe es herausgefunden, was das Problem war.

Der Adapter wird über USB mit Strom versorgt. Ich habe ihn an einen der beiden DELL 2007FP angeschlossen, er stellt 2,5W pro Port zur Verfügung, also 500mA. Reicht für einen Atmega ja dicke aus, dachte ich mir. Der Dragon hängt dabei an dem anderen Port des Monitors dran. Das scheint jedoch nicht aus zu reichen.

Also habe ich in meiner Krutschkiste gewuselt und da ein 5v/2A Netzteil rausgeholt mit der Polung am Stecker wie sie der Adapter braucht. Angeschlossen und die LED fing fröhlich an zu blinken. Na das ist schon mal was. Also Drachen rangehängt, geflasht, ein Paar Breakpoints gesetzt, u.a. auch in die ISR und voller Vorfreude das Debuggen gestartet und siehe da: es tut.

Die Spannungsanzeige des Targets zeigt 5,2v an, aber das düfte kein Problem sein, der AVR verstägt ja bis zu 5,5v.

Also, wenn irgendwas komisch ist --> Stromversorgung testen.

Grüße
Heinrich

 

[Cassio]

Hallo Heinrich!

Danke, dass du uns mal wieder an deiner Erfahrung teilhaben lässt und wir bei ähnlich ungeklärten Phänomenen einfach mal die Eingangsspannung prüfen sollten.

Manchmal ist der Auslöser eines Fehlers auch wirklich zu simpel, um ihn in Betracht zu ziehen.


Grüße und viel Spaß mit deinem "Drachen".
Cassio

 

[macGyver]

hallo!

ich hoffe ich darf mich hier mal einfach so einmischen

ich hab auch ein problem mit meinem avr dragon, und einem atmega644.

mein dragon ist ganz neu und ich wollte einfach mal das debuggen über jtag versuchen

ich habe also folgendes programm geschrieben:

#include <avr/io.h>
#define F_CPU 8000000
#include <util/delay.h>

int main(void)
{
DDRD=0xFF;
while(1)
{
PORTD |= (1<<PD6);
//_delay_ms(100);
PORTD &= ~(1<<PD6);
//_delay_ms(100);
}
}

die delays sind auskommentiert da ich mich sonst beim "durchsteppen" des programms vermutlich in einer schleife voller nops verirren würde

das flashen des µC und auslesen der fuses funktioniert problemlos und die betriebsspannung ist auch stabil.

wenn ich jetzt auf den button "start debugging and break" klicke (avr studio 5.1) sollte doch ein kleiner gelber pfeil am linken rand auftauchen...
siehe folgendes video http://www.youtube.com/watch?annota...&feature=iv&src_vid=yJo29VMXt90&v=plJf0r7IcWc
ab 8:55

bei mir passiert jedoch rein garnichts...
der avr arbeitet sein programm ab, led leuchtet mit halber leuchtkraft auf, -> weil schnelles blinken läuft also normal

am dragon blinkt die 2 farbige led grün (bedeutet doch dass er im debugging mode ist oder?)

ich kenn mich nicht mehr aus -.- hat jemand eine idee was ich falsch mache? vlt ist nur etwas falsch eingestellt?
bitte um hilfe!

lg macgyver

 

[Hemi]

Hi macgyver,

auf was steht der Parameter "Optimization"? Es sollte auf None (-O0) stehen, dann sollte es funktionieren.

Grüße
Heinrich

 

[Rolf.H]

Ich habe dann geschaut ob ein PullUp am /RESET-Pin vorhanden ist, nein, ist keiner da. Also habe ich +5V mit dem /RESET-Pin verbunden. Es hat jedoch nichts gebracht.

Sorry, daß ich mich mal als Anfänger einklinke...aber macht man denn sowas?
Die Versorgung direkt am Reset-Pin, das hab ich noch nie getan, immer über ca. 10K!

Grüße

Rolf

 

[LotadaC]

Der 644(PA) hat, wie alle größeren AVR, einen separaten !Reset-Pin. Dieser Pin ist low-aktiv ("!"), dh ein lo-Pegel (Wert und Mindestdauer siehe Datenblatt) löst den Reset aus.
Insbesondere muß der Pin für den "normalen" Betrieb also einen höheren Wert als die Reset-Schwelle haben. Üblicherweise hat er also denselben Pegel wie die Versorgungsspannung. (Man könnte (!) ihn also auch direkt auf Vcc legen).
Andererseits muß der Programmer/Debugger in der Lage sein, den AVR in den Reset zu zwingen, den Pin also gegen Vcc auf Gnd zu ziehen. Wenn da jetzt gar kein Pullup zwischen ist, der Pin also direkt auf Vcc liegt, schließt der Programmer/Debugger also die Stromversorgung kurz. Dann bricht entweder die Stromversorgung komplett ein, oder (was wahrscheinlicher ist) der Programmer/Debugger verträgt den Strom nicht, und verabschiedet sich.
Was macht denn so ein Pullup eigentlich?
Er zieht einerseits den Pin auf den Hi-Pegel ("up"), ok.
Aber er ist eben auch eine Strombegrenzung - wird das Signal also extern heruntergezogen (und zwar über einen deutlich kleineren (bzw gar keinen) Widerstand, begrenzt der Pullup den Strom aus der Versorgungsspannung - diese bricht hinter dem Pullup quasi ein. Damit liegt der Pin also auf einem niedrigeren Pegel, als die Versorgungsspannung (ohne daß ganz Vcc einbricht).

Je kleiner der Pullup, desto mehr Strom muß der Programmer/Debugger ziehen, um den Pegel runterzubekommen.
Je größer der Pullup, desto geringere "Störströme" reichen aus, um einen unbeabsichtigten Reset (im Normalbetrieb) auszulösen.

Der Reset Pin hat selbst laut Datenblatt einen integrierten Pullup von 30 bis 60 kOhm. Inwiefer sich die "PUD" darauf auswirkt, hab ich nicht nachgesehen. Deswegen kommt man mit offenem Reset-Pin aus - das wird dann aber störanfällig, insbesondere, wenn da jetzt noch längere Leitungen drankommen (Stecker für den Programmer etc...)

Ich möchte aber nochmals darauf hinweisen, daß hier das Problem war, daß der Drachen (über USB) den nötigen Strom des targets nicht liefern konnte, und offensichtlich die Ganze Spannungsversorgung einbrach, was einem Power-On-Reset gleichkam. Immer wieder.

 

[Hemi]

Hi Rolf,

glaube ist etwas falsch rüber gekommen, Natürlich ist /RESET über einen 10k PullUp mit +5v verbunden, nicht direkt. Sonst kann der Dragon den /RESET nicht mehr auf low ziehen.

Grüße
Heinrich

 

[macGyver]

hallo hemi!

danke für die Antwort!

ich bin noch ziemlich unerfahren im avr studio, könntest du mir noch sagen wo ich diesen parameter umstellen muss?


lg macgyver

 

[Hemi]

Hi MacGyver,

ich habe leider kein AVR Studio 5.1 zur Hand, sondern nur Atmel Studio 6. Und da geht es wie folgt: Rechtsklick auf Projekt --> Properties --> unter "AVR/GNU C Compiler" gibt es einen Eintrag "Optimization". Und da kannst Du dann Optimierungslevel einstellen. Stell es mal auf -O0 und probier dann nochmal.

Grüße
Heinrich

 

[macGyver]

hallo hemi!

ich habs mittlerweile schon gefunden trotzdem danke!!

ist im avr studio 5.1 eigentlich auch so

alt+F7 (projekteinstellungen) -> toolchain -> debuglevel auf "none" und am besten JTAG clock ganz runterdrehen (im bereich "tool" einzustellen)

vielleicht ist es für jemand anderes später einmal hilfreich

leider ist das ganze ein wenig langsam... naja bei einer clockfreq. von 35 kHz

bei höheren Frequenzen funktioniert das ganze nur leider nicht so recht :/