Dragon vs. JTAGICE 3

Hallo zusammen,

ich arbeite Momentan an einem Projekt auf einem atmega645, programmiert über den Dragon (weil sehr günstig).

Langsam geht mein Speicher aus und ich überlege auf den atmega1284 umzusteigen, da ich eh nicht so viele i/o s brauche.

Bei der Recherche hab ich dann entdeckt das der Dragon On-Chip Debugging nur bis 32kB Flash unterstützt. Debuggen tu ich aber schon seit geraumer Zeit damit, nur leider nicht in Echtzeit (on the run), Einblick in die Register erhalte ich nur wenn ich die Ausführung pausiere.
Verstehe ich das richtig, das ich mit einem JTAGICE3, der die 32kB Beschränkung nicht hat, tatsächlich in Echtzeit debuggen könnte, sprich die Register ständig am PC angezeigt werden? Dann wäre es ja auch möglich Breakpoints auf Variablen zu setzen, nicht nur fix im Programmablauf verankerte, oder? AVR Studio bietet zwar diese Funktion an, aber ich kann sie (mit dem Dragon?) nicht nutzen.

Danke schon mal im Vorraus

Hi,

ja mit dem JTAG ist "richtiges" debuggen möglich soweit ich weiß, sprich du kannst richtig im laufenden Betrieb debuggen. Und von einer Beschränkung habe ich bisher nichts gehört (außer bei den Breakpoints).

Die Beschränkung von 32kBytes beim AVR-Dragon gab es tatsächlich in den Anfangstagen um es vom teureren JTAGICE MKII ab zu grenzen. Diese Beschränkung wurde aber in der aktuellen Firmware des Dragons aufgehoben und besteht im aktuellen AVR Studio 4.xx bzw AVR Studio 6 nicht mehr und soweit ich das sehen kann, wird der ATmega1284 vom Dragon voll unterstützt.

Bezüglich des updates der Register, während ein Programm auf dem Target läuft, kenne ich bisher von keinem JTAG Debugger. Das kann auch der JTAGICE 3 nicht. Um Register zu sehen, mußt Du das Programm anhalten oder im Einzelschittbetrieb ablaufen lassen...

Liebe Grüße,
Jürgen

Wie siehts dann mit diesen "maskierten Breakpoints" aus? Geht das irgendwie das ich z.B. das Programm anhalte sobald sich eine Variable verändert, unabhängig von der Stelle im Code?

Welche Schnittstelle würde echtes Echtzeit-Debuggen ermöglichen? Ich hab das bis jetzt nur auf der Uni einmal gesehen, mit einem TI µC und einem Sündteuren Debugger.

Also auf Änderungen einer Variable kannst Du schon einen Breakepoint unabhängig vom Code setzen.

Ja, die Echtzeitdebugger sind richtig teuer. Das bietet aber Atmel nicht an. Damit hatte ich früher mal in Verbindung mit NEC µC zu tun. Allerdings waren das richtig große Kisten mit einem speziellen "bounded out" µC drin. Für jede Variante musste man ein neues Board kaufen und für jedes Package ein neuen "Schnorchel"... :( Und dann hatte man, gerade bei den 100pinnern ständig mit Kontaktproblemen zu kämpfen... Also ich habe Echtzeitdebugging noch nicht vermisst, zumal das bei 100MHz+ Taktfrequenz gar nicht mehr sinnvoll ist... So schnell kannste eh nicht kuggen, wie die Dinger rennen...

Ich arbeite jetzt schon über 10 Jahre mit AVR's und den entsprechenden Debuggern und muss soweit feststellen, dass diese ziemlich gut arbeiten und ich konnte sogar einmal einen Defekt in einem AVR damit nachvollziehen... Die Tools sind eigentlich zuverlässig, wenn sie auch die ein oder andere Funktion nicht besitzen und auch die eine oder andere Macke haben...

Was für ein TI µC war das? MSP430?

Liebe Grüße,Jürgen

Wie genau setze ich so einen Breakpoint? Geht das auch mit dem Dragon?

Teilweise wäre es schon sinnvoll das ganze in Echzeit zu sehen, ich habe ein paar Probleme mit Funkempfang, wenn da das Programm mitten im Ablauf unterbreche kriege ich nicht das ganze Signal rein, wenn ich das ganze Signal abwarte und was schief läuft ist es verdammt schwer herauszufinden wo und was nicht geklappt hat.

Wenns kein echtzeit Debugging gibt, was kann denn dann der ICE3 gegenüber dem Dragon besser das der 4-5 Fache Preis gerechtfertigt ist?

Müsste ein MSP430 gewesen sein, weiß aber leider nicht was für ein Debugger da verwendet wurde. Hat mich aber enorm beeindruckt weil es schon einige Möglichkeiten eröffnen kann.

mfg PMO

Nun, einen Breakepoint setzt Du im Atmel Studio 6 an eine Position im Code, in dessen Fokus sich Deine Variable befindet und dann kannst Du dem eine Condition, wie z.B. i==5 geben. Wenn dann i==5 dann hält die Ausführung an der stelle des Brakepoints.

Also einen Dragon nimmste nur einmal mit zum Kunden, dann kannste den wegschmeißen... Das JTAGICE 3 ist auf jeden Fall robuster für den Einsatz unterwegs bzw. für den professionellen Einsatz. Der Dragon eignet sich nur für den Labortisch und ist z.B. auch nicht als Fertigungsprogrammer von Atmel zugelassen. Und für den professionellen Einsatz sind 300 Euronen auch kein Thema... Und dann gibt es noch die Besonderheiten, wie PDI und Spannungsbereich herunter bis 1,5 V, die der Dragon nicht bietet...

Falls Du günstiger an einen JTAGICE 3 kommen möchtest, melde Dich einfach bei Atmel on Tour an... Da kriegste meist ein Demoboard und ein JTAGICE 3 samt Mittagessen für wesentlich weniger EUROs... Dazu gibt es dann auch jede Menge Infos und Handons...

Liebe Grüße,
Jürgen

Danke erst mal für die Antwort!

Aber das ist nicht ganz das was ich meine. Wenn ich eine Kondition irgendwo in den Code einbaue und dort einen Breakpoint setze, hab ich ja eine fixe Position an dem das Programm hält. Das die Variable sich ändert weiß ich ja, aber ich möchte wissen WO im Code die (globale) Variable verändert wird. Und das kann an sehr vielen Stellen passieren.

Step-by-Step ist auch keine Alternative, da, wie gesagt, einige der Funktionen sehr Zeitkritisch sind und jede Pause die Funktion zu nichte macht.

Deiner Beschreibung entnehme ich auch, das ich mir den ICE sparen kann, hat für mich keinen zusätzlichen Nutzen ;)

thx anyway, spare ich zumindest Geld wenn schon nicht Zeit

Ich dachte da eher an eine zentrale Position für den Breakepoint, wie z.B. der Scheduler von Deinem RTOS, der immer durchlaufen wird. Damit erreichst Du eine globale Überwachung einer Variable und kannst anhand des aufrufenden Thread zurückverfolgen, wo die Variable zuletzt geändert wurde... Was damit natürlich nicht geht, ist, wenn Du die Variable zusätzlich im Interrupt manipulierst... Das sollte aber eigentlich vermieden werden und möglichst über das Messaging vom RTOS abgewickelt werden...

Falls Du kein RTOS verwendest, dann hast Du bestimmt eine Endlosschleife oder ähnliches, in dem Du den Breakepoint setzen könntest...

Was für einen Funk hast Du denn in Deiner Applikation? ISM 433MHZ oder 868MHz oder irgendwas wie Bluetooth, Z-Wave oder ähnliches?

Liebe Grüße,
Jürgen

Ich hab eine Statemachine, also while schleife die immer wieder durchlaufen wird. (Ich nehm an RTOS ist was anderes, da kenn ich mich aber nicht so gut aus, hast du da vlt. einen Link zu was Vernünftigem mit Atmel Bezug? Wiki gibt da nicht so viel her mit dem ich was anfangen kann).

Wenn ich den Breakpoint in der Hauptschleife setze, weiß ich trotzdem nicht wo die Variable verändert wird. (Da wäre eine "Zurück" Funktion Praktisch ;-)

Als Funk hab ich einen 868Mhz Empfänger der über einen Interrupt abgehandelt wird. Als konkretes Problem hab ich momentan Folgendes: Manchmal, wenn der µC längere Zeit im Stand-By Powersave mode ist, reagiert er nicht mehr auf die Funksignale. Leider tritt das relativ selten auf, und ich habs noch nicht geschafft die Ursache zu finden. Da wäre es praktisch wenn ich alle damit verbunden Variablen überwachen könnte um zu sehen ob sich irgendwann eine Verändert ohne das es beabsichtigt ist. Jede einzelne per Breakpoints überall im Code zu überprüfen verhindert den eigentlichen Funkempfang und ist auch sehr Zeitaufwendig.

Wäre praktisch gewesen, aber dann muss ich halt so weiter suchen.

Du kannst Dir ja mal das http://www.freertos.org mal anschauen...

Wenn Du Variablen im Interrupt und in Deiner normalen Schleife manipulierst, musst Du unbedingt dafür sorgen, dass die Manipulation in Deiner Schleife atomic ist... Das heißt konkret, jede Manipulation einer Variable, die auch im Interrupt verwendet wird, darf nicht durch einen Interrupt unterbrechbar sein. Das erreichst Du, indem Du alle Interrupts vor der Bearbeitung sperrst und anschließend wieder frei gibst...
Ich habe das auch schon vergessen und mich hinterher über merkwürdiges Verhalten gewundert... :(

Liebe Grüße,
Jürgen