AVM DRAGON 32k Begrenzug aufheben

Soweit ich weis liegt das daran, dass nur 32kb SRAM auf dem board 
vorhanden sind.

Nein, es hies es wäre nur per software eingegrenzt

Begrenzt durch welche Software? AVR-Studio oder die Firmware des Dragon?
Wie auch immer, für beides würde Reverse Engineering bestimmt zu einer 
Lösung führen. Ich besitze aber leider kein Dragon ;-)

Also der Typ deutete auf das board. er meinte es ist hier drin 
Softwarebegrenzt.
Sprich also Firmware.  Das AVR-Studio ist offen. Es gibt kein 
Unterschied was dran hängt.

Wenn auf dem Dragon nur 32K RAM drauf sind, und dieser für Emulation und 
Debugging genutzt wird, dann muss die Firmware auch auf 32K begrenzt 
sein, sonst funktionierts nicht.

Was hat das größe Bruder für Speicher?

Ich denke, das die im AVR Studio ausgegraut sind ist in den XML dateien 
hinterlegt dazu wird man das Executable nicht anfassen müssen.

das wäre doch fast ein Versuch wert

das JTAG-ICE2 hat aber ein 512Kx8 SRAM drauf. da scheints wohl doch noch 
etwas mehr zu brauchen.

Gruß
Fabian

@Simon: klar, das Jtag-Ice2 ist z.b. auch zum Debuggen der UC3-Core 
AVR32 uC geeignet...vieleicht braucht es fürs Dragon ja wirklich nicht 
so viel sram, aber einfach auf Verdacht nen Chip umlöten deswegen?
Wäre natürlich schick, aber mein ICE2 kommt montag per UPS, dann hat 
sich die Frage für mich erübrigt ;-)

Gruß
Fabian

Rudolph wrote:

> Geht da garnichts? Nicht einmal mit Code-Beschränkung auf 32 KB?

Letzteres geht zumindest mit AVaRICE und GDB.  Man kann dort auf
der Kommandozeile behaupten, es wäre ein konkret benannter AVR
vorhanden, dann ignoriert AVaRICE die JTAG-ID.  Geht natürlich aus
der Dose raus nur, wenn es ein kleineres Mitglied der Familie gibt,
das sich ansonsten genauso verhält.  Ich hatte das mal mit einem
ATmega6490 probiert und behauptet, es sei ein '3290.  Ob die 'CAN128
und 'CAN32 gleichermaßen kompatibel sind, weiß ich nicht.

Ansonsten könntest du dir im AVaRICE immer noch im Sourcecode
behelfen, indem du einen Konfiguration für etwas wie einen
AT90CAN128_32 anlegst und den dann erzwingst.

Die Limitierung macht sich im Dragon offenbar daran fest,
welche ROM-Größe man dem Dragon im device descriptor mit auf die
Reise gibt.  Wenn dieser Wert 32 KiB übersteigt, lehnt der Dragon
alle Befehle ab, die etwas mit dem Debugging zu tun haben.

AVR Studio wirst du vermutlich in dem Zusammenhang aber vergessen
können.

Rudolph wrote:

> Aber das AVR-Studio brauche ich schon da ich zunächst einmal nur mit den
> Port-Pins spielen wollte um die Hardware zu testen.

Da sehe ich zwar keinen ursächlichen Zusammenhang, aber wie schon
geschrieben, AVR Studio wirst du kaum überreden können, mit einem
anderen Prozessor als dem vorhandenen zu arbeiten.

Trotzdem weiß ich noch nicht, wofür du dafür zwingend ein AVR Studio
brauchst...  OK, da der GDB (noch) nichts von den IO-Registern weiß,
muss man das dort über die Speicheradressen machen, aber ansonsten
geht das auch.

Außerdem kannst du natürlich stattdessen allemal auch eine Mini-App
schreiben, die mit den Pins wackelt.

Mein Eindruck ist, dass das Limit in erster Linie dazu dient, die
Atmel-interne Konkurrenz zwischen dem preiswerten Dragon und dem
vergleichsweise teuren JTAG ICE mkII in Grenzen zu halten.

> Denn damit das Programm anläuft muss ich die Programmier-Session beenden
> oder den JTAG abziehen - super.

Huh?  Da machst du irgendwas flasch.  Bei uns sind die JTAGge immer und
den ganzen Tag lang dran, warum sollte man die je abziehen müssen?
Wenn man aus dem ICE ,,ausgeloggt'' ist, hängt sein JTAG-Interface
einfach komplett in der Luft.

Nein, wenn man JTAG hat, benutzt man freiwillig kein ISP mehr.  JTAG
ist etwa viermal schneller, und es braucht keinen funktionierenden
CPU-Takt (hilfreich, wenn man sich mal ,,verfuset'' hat).

Rudolph wrote:

> Aber per JTAG wird bei bestehender Verbindung der Reset-Pin offenbar
> die ganze Zeit über runtergezogen, das ist mit dem AVR-ISP MK-II
> aber nicht so.

Nein, der Reset-Pin wird normalerweise gar nicht benutzt.  JTAG kann
die CPU von selbst anhalten. ;-)

> Im Studio das Programmier-Fenster schliessen -> Programm läuft.

Ach so, 'ne AVR-Studio-Macke.  Nimm avrdude zum programmieren, oder
das Kommandozeilentool vom AVR Studio (jtagmkii.exe oder so ähnlich).
Die rattern einmal durch, und melden sich wieder ab.

> Was auch ich auch blöd finde ist, dass man nicht einfach das
> Debugging starten kann solange man im Programmier-Modus ist.

Mit dem AVR Studio kannst du aber dafür programmieren, solange du im
Debug-Modus bist...

Rudolph wrote:

> Den Reset braucht man doch, um per JTAG flashen zu können, oder
> nicht?

Nur, wenn die Applikation das JTD-Bit setzt (JTAG disable).  Dann kann
man mit einem externen Reset erzwingen, dass das JTAG-Interface
unmittelbar nach dem Reset die Steuerung bekommt, bevor die
Applikation noch eine Chance hat, JTD zu setzen.

>> Mit dem AVR Studio kannst du aber dafür programmieren, solange du
>> im Debug-Modus bist...

> Eben nicht, die beiden Modi schliessen sich gegenseitig aus.

Nö.

> Naja, AVR-Studio-Macke, schon trefflich formuliert. :-)

Die Macke ist (und abgesehen, dass ich dafür ein Windows bräuchte, um
es zu nutzen, diese und ähnliche Macken machen das Teil für mich
einfach unbedienbar), dass im Debugmodus nicht das normale
Programmiertool benutzt werden kann, sondern dass dann der Debugger
von AVR Studio selbst den Download anwirft.  Normalerweise macht er
das immer dann ,,von allein'', wenn sich die Datei geändert hat.  Aber
ich glaube, man kann's auch irgendwo mit der Hand anwerfen.

Jörg Wunsch wrote:
> Rudolph wrote:
>
>> Den Reset braucht man doch, um per JTAG flashen zu können, oder
>> nicht?
>
> Nur, wenn die Applikation das JTD-Bit setzt (JTAG disable).  Dann kann
> man mit einem externen Reset erzwingen, dass das JTAG-Interface
> unmittelbar nach dem Reset die Steuerung bekommt, bevor die
> Applikation noch eine Chance hat, JTD zu setzen.

wird das Flag oder die Fuses gemeint?

>
>>> Mit dem AVR Studio kannst du aber dafür programmieren, solange du
>>> im Debug-Modus bist...
>
>> Eben nicht, die beiden Modi schliessen sich gegenseitig aus.
>
> Nö.
>
>> Naja, AVR-Studio-Macke, schon trefflich formuliert. :-)
>
> Die Macke ist (und abgesehen, dass ich dafür ein Windows bräuchte, um
> es zu nutzen, diese und ähnliche Macken machen das Teil für mich
> einfach unbedienbar), dass im Debugmodus nicht das normale
> Programmiertool benutzt werden kann, sondern dass dann der Debugger
> von AVR Studio selbst den Download anwirft.  Normalerweise macht er
> das immer dann ,,von allein'', wenn sich die Datei geändert hat.  Aber
> ich glaube, man kann's auch irgendwo mit der Hand anwerfen.

wie ich das letzte mal mit jtag debuggt habe hat er nach dem ändern des 
Quellcodes nach gefragt ob er ihn neu übersetzten soll und hochladen 
soll.

Marco Schwan wrote:

>> Nur, wenn die Applikation das JTD-Bit setzt (JTAG disable).  Dann kann
>> man mit einem externen Reset erzwingen, dass das JTAG-Interface
>> unmittelbar nach dem Reset die Steuerung bekommt, bevor die
>> Applikation noch eine Chance hat, JTD zu setzen.
>
> wird das Flag oder die Fuses gemeint?

Das Flag.  Die Fuse ist endgültig, und klemmt das JTAG-Interface
unwiderruflich (*) ab.

(*) OK, mit einer anderen Programmiermethode als JTAG widerruflich,
aber eben nicht mehr via JTAG selbst.

So, das 512KB-RAM ist heute angekommen, ich habe es vorhin aufgelötet.
Der Dragon läuft noch/wieder.  ;-)
Er kann seine neuen Möglichkeiten aber noch nicht nutzen.

AVR Studio spielt zuerst nicht mit. Beim dem Auswahldialog "Select 
device and debug platform" muß ja noch kein Debugger angeschlossen sein. 
Selbst wenn dessen Firmware es erkennen und melden würde wüßte AVR 
Studio noch nichts davon. Die größeren Targets sind also grau.

Als nächsten Versuch habe ich im Verzeichnis Partdescriptionfiles die 
Datei avrdragonparts.cac mit dem Inhalt von jtagmkIIparts.cac ersetzt. 
Dann erlaubt AVR Studio zunächst die Auswahl von größeren Targets, die 
sind nicht mehr ausgegraut. Beim Versuch den Debugger zu starten kommt 
aber doch eine Fehlerbox, "Device ATmega644 not supported on AVR Dragon 
in this version of AVR Studio 4". Danach ist frecherweise die Datei 
avrdragonparts.cac neu erzeugt, hat wieder den originalen Inhalt!

So einfach ist das also nicht. Wer noch Tipps zum hacken hat, immer her 
damit!

PS: ich mache das alles nur aus Spaß, habe noch einen JtagICE mk2.

Naja, die Cache-Files werden sicherlich aus den XML-Files erzeugt,
du müsstest also das entsprechende XML-File um einen "AVR Dragon"-
Tag erweitern.

Aber du kannst mir glauben, dass all das allein nicht reicht.  Der
entscheidende Punkt für den Dragon ist, was du im device descriptor
als Flash-Größe rüberreichst.  Wenn das mehr als 32 KiB sind, dann
verweigert er dir einige Befehle, die für das Debuggen essenziell
sind, für das reine Programmieren via JTAG aber nicht gebraucht
werden.

Was du natürlich machen kannst ist, eine ATmega644-XML-Datei so
modifizieren, dass sie nur 32 KiB Flash-ROM vorgibt zu kennen.
(Die originale Datei so lange zur Seite legen.)  Damit solltest du
dann innerhalb der 32 KiB wirklich debuggen können.  Ich hab's
dazumals mal unter AVaRICE mit einem ATmega6490 vs. ATmega3290
getan, also einfach mittels Kommandozeilen-Option einen Override
auf ATmega3290 erzwungen (AVaRICE ignoriert dann die JTAG ID).  Das
hat funktioniert.  Bei AVR Studio kannst du nur den Override nicht
durchdrücken, daher musst du das XML ändern.

Ja, das File avrdragonparts.cac wird aus den XML-Files neu erzeugt, 
soviel habe ich gestern auch noch rausgefunden. (Kann man mit 
Sysinternals FileMon sehen.) Wenn man die Flash-Größe im XML künstlich 
reduziert kann man in der Tat den größeren Chip auswählen und debuggen, 
habe ich gerade getestet.

Aber das ist ja nicht Thema des Threads hier.   ;-)
Die Frage ist, wo steckt die Begrenzung, wie patche ich sie hoch, für 
einen Dragon mit mehr RAM. Ist auch dessen Firmware betroffen, oder ist 
die schlau bzw. unbeteiligt genug?

Ich habe in AvrTargetDragon.dll nach 0x00008000 gesucht, kommt leider 47 
mal vor. Da muß wohl ein Win32-Debugger ran. Die Schlüsselworte aus den 
XML-Dateien (PROG_FLASH, ulFlashSize) finde ich sowohl in der DLL als 
auch in AVRDragon.exe, die Arbeitsteilung ist mir noch nicht klar. 
Benutzt AVR Studio wohlmöglich auch AVRDragon.exe? Habe ich als String 
dort nicht gefunden. Den Namen der DLL übrigens auch nicht.

Die DLL scheint ein COM-Objekt zu sein, das Interface sieht danach aus. 
(Kann man mit Dependency Walker sehen.) Die ist im System registriert 
und AVR Studio kann sie über die GUID 
{57A6CB60-3F5E-4d50-9DEB-D827AA1C71FB} statt Namen ansprechen. Dies aber 
nur am Rande.

Ferner habe ich die Zugriffe von AVR Studio auf die Registry belauscht, 
ob dort irgendwo 0x00008000 vorkommt. War nicht der Fall.

Die Beschränkung steckt also wohl hart codiert in der DLL, auf die 
sollten wir uns fokussieren.

Jörg Hohensohn wrote:

> Wenn man die Flash-Größe im XML künstlich reduziert kann man in der
> Tat den größeren Chip auswählen und debuggen, habe ich gerade
> getestet.

Das bestätigt meine Erwartung.

> Aber das ist ja nicht Thema des Threads hier.   ;-)

Naja, es hatten zumindest schon andere danach gefragt.  Wenn's gerade
nur einen AT90CAN128 gab, man aber mit dem Dragon trotzdem debuggen
will, könnte man sich damit zumindest bis 32 KiB behelfen.  OK, kein
ganz so gutes Beispiel, da man den 'CAN128 noch mit einem JTAG ICE mkI
Clone debuggen kann... aber Nachfragen nach sowas gab's schon.

> Die Frage ist, wo steckt die Begrenzung, wie patche ich sie hoch,
> für einen Dragon mit mehr RAM. Ist auch dessen Firmware betroffen,
> oder ist die schlau bzw. unbeteiligt genug?

Mach's doch mal andersrum.  Du bist Firmwareingenieur bei Atmel, und
sollst den AVR Dragon so implementieren, dass er zwar von Hobbyisten
benutzt werden kann, aber dennoch die ,,dicken Fische'', die ja
letztlich auch gut ihr Geld machen, noch ein JTAG ICE mkII kaufen
müssen, bei dem du wenigstens ein paar Groschen verdienst (am Dragon
verdient sicher niemand nennenswert).  Wo würdest du den Test
ansetzen, im Dragon selbst oder in der Frontendsoftware?  Das Frontend
könnte ja jemand einfach durch ein anderes austauschen...

> Ich habe in AvrTargetDragon.dll nach 0x00008000 gesucht, ...

Das hättest du dir nach dem genauen Lesen meiner Mails eigentlich
sparen können.  Ich schrieb doch, dass ich das mit AVaRICE alles schon
mal ausprobiert habe, und ich hab dir auch geschrieben, was der Dragon
dann macht, wenn man versucht, die Grenze zu umgehen.  Damit ist
eigentlich sonnenklar, dass du AvrTargetDragon.dll nicht weiter
angucken musst.

> sowohl in der DLL als
> auch in AVRDragon.exe, die Arbeitsteilung ist mir noch nicht klar.

Letzteres ist ein reines Programmierwerkzeug, so wie stk500.exe,
jtagicemkii.exe usw.  Man könnte auch alles in ein .exe reinpacken und
mit der gleichen Kommandozeile arbeiten. ;-)  Ach, dann könnte man das
Executable auch einfach avrdude.exe nennen. :-))

> Die Beschränkung steckt also wohl hart codiert in der DLL, auf die
> sollten wir uns fokussieren.

Aber nur, wenn du sie nicht finden willst. ;-)  Ansonsten musst du dir
die Firmware ansehen...  Das fängt damit an, dass das zweimal Firmware
(für beide Controller) in einer Datei sind, die noch dazu irgendwie
verschlüsselt ist.  Das Reengineering der Firmware dürfte selbst mit
EU-Recht nicht wirklich gut zu rechtfertigen sein, es sei denn, du
hast irgendeins der propagierten Dragon-Features, das du so nicht
benutzen könntest.

Hallo Namensvetter, danke für den Input.

Um die Sache etwas weiterzuspinnen:

>> Die Frage ist, wo steckt die Begrenzung, wie patche ich sie hoch,
>> für einen Dragon mit mehr RAM. Ist auch dessen Firmware betroffen,
>> oder ist die schlau bzw. unbeteiligt genug?
>
> Mach's doch mal andersrum.  Du bist Firmwareingenieur bei Atmel, und
> sollst den AVR Dragon so implementieren, dass er zwar von Hobbyisten
> benutzt werden kann, aber dennoch die ,,dicken Fische'', die ja
> letztlich auch gut ihr Geld machen, noch ein JTAG ICE mkII kaufen
> müssen, bei dem du wenigstens ein paar Groschen verdienst (am Dragon
> verdient sicher niemand nennenswert).  Wo würdest du den Test
> ansetzen, im Dragon selbst oder in der Frontendsoftware?  Das Frontend
> könnte ja jemand einfach durch ein anderes austauschen...

Ist es sicher, daß das die Absicht war? Immerhin hat der Dragon im 
Auslieferungszustand nur ein Viertel des RAMs, somit hielt ich die 
Beschränkung nicht für künstlich. Und er hat einen Footprint für ein 
größeres, was ich nun bestückt habe.
Keine Ahnung, was die mit diesem RAM machen, vielleicht steht ja mehr 
drin als nur ein Speicherabbild. Ist auch so ein ungewöhnlich schnelles.

>> Ich habe in AvrTargetDragon.dll nach 0x00008000 gesucht, ...
>
> Das hättest du dir nach dem genauen Lesen meiner Mails eigentlich
> sparen können.  Ich schrieb doch, dass ich das mit AVaRICE alles schon
> mal ausprobiert habe, und ich hab dir auch geschrieben, was der Dragon
> dann macht, wenn man versucht, die Grenze zu umgehen.  Damit ist
> eigentlich sonnenklar, dass du AvrTargetDragon.dll nicht weiter
> angucken musst.

OK, hatte ich nicht genau verstanden. Es ist aber bestimmt auch eine 
Abfrage in der DLL. Vielleicht auch nur dort, wenn wir Glück haben:

Dein Experiment mit AVaRICE finde ich interessant. Das würde ich mit dem 
speichererweiterten Dragon gern wiederholen, ob der sich auch so 
verhält. Kannst du mir beschreiben, was ich machen muß? Ich kenne 
AVaRICE noch nicht.

> Ach, dann könnte man das  Executable auch einfach avrdude.exe nennen. :-))

Haha!

> Aber nur, wenn du sie nicht finden willst. ;-)  Ansonsten musst du dir
> die Firmware ansehen...  Das fängt damit an, dass das zweimal Firmware
> (für beide Controller) in einer Datei sind, die noch dazu irgendwie
> verschlüsselt ist.

Sah mir nicht besonders verschlüsselt aus, ich meinte dort Strings etc. 
gesehen zu haben. Ist vielleicht nur die Organisationsinfo um die 
eigentliche Firmware.

Aber eins nach dem anderen, das AVaRICE-Experiment scheint mir den 
meisten Erkenntnisgewinn zu versprechen.

Jörg Hohensohn wrote:

(Firmwarelimitierung des AVR Dragon)

> Ist es sicher, daß das die Absicht war?

Ja, ziemlich.

> Immerhin hat der Dragon im
> Auslieferungszustand nur ein Viertel des RAMs, ...

Mehr braucht er für die 32 KiB eben nicht.

> Keine Ahnung, was die mit diesem RAM machen, ...

Meiner Meinung nach ist das so'ne Art tag RAM.  Damit merken sie sich,
zu welcher ROM-Adresse welche Zeilennummer im Programm gehört bzw. an
welcher ROM-Adresse eine neue Zeile des Quellprogramms beginnt.

> Es ist aber bestimmt auch eine Abfrage in der DLL.

Kann sein, aber ist eigentlich nicht notwendig.  Selbst wenn, kannste
ja zumindest erst einmal über AVaRICE und GDB arbeiten, dann hättest
du eine Baustelle (AVR Studio) nach hinten geschoben.

> Dein Experiment mit AVaRICE finde ich interessant. Das würde ich mit
> dem speichererweiterten Dragon gern wiederholen, ob der sich auch so
> verhält. Kannst du mir beschreiben, was ich machen muß? Ich kenne
> AVaRICE noch nicht.

avarice --jtag usb --debug --dragon :1212

Dann den AVR-GDB starten:

avr-gdb myapp.elf
...
(gdb) target remote :1212

Danach gucken, ob du sowas wie einen single step (Kommando "step" oder
einfach "s") machen kannst.

Falls du WinAVR hast, kann es sein, dass du die mitgelieferte
libusb0.dll wegwerfen musst und stattdessen den Treiber komplett neu
aus dem libusb-win32-Projekt von sourceforge.net installieren.  Ich
habe so in Erinnerung, dass WinAVR's einfaches Reinkopieren der DLL
nicht genügt, dass die libusb-win32 wirklich auf den USB zugreifen
kann und dort Geräte findet.

Wie sich der Fehler genau manifestiert hat, habe ich nicht mehr in
Erinnerung.  Kann sein, dass das single-step-Kommando gar nicht
akzeptiert worden ist, oder das Auslesen des PC.  Jedenfalls hat der
Dragon bei irgendwelchen Dingen geblockt, die typisch für Debugging
sind und für einen reinen JTAG- oder debugWire-Download nicht benutzt
werden.  Der hat dann einfach eine 0x80 als response (RSP_FAIL)
gebracht.

>> ...  Das fängt damit an, dass das zweimal Firmware (für beide
>> Controller) in einer Datei sind, die noch dazu irgendwie
>> verschlüsselt ist.

> Sah mir nicht besonders verschlüsselt aus, ich meinte dort Strings
> etc.  gesehen zu haben. Ist vielleicht nur die Organisationsinfo um
> die eigentliche Firmware.

Ja, das scheint nur die Organisation zu sein.  Wenn ich das richtig
einschätze, beginnt die Firmware auf Offset 0x600, und das, was dort
steht, bekommt man nicht einfach so disassembliert:

1

$ avr-objdump -D -m avr5 -b binary foo | head -30

2

3

foo:     file format binary

4

5

Disassembly of section .data:

6

7

00000000 <.data>:

8

       0:       22 8a           std     Z+18, r2        ; 0x12

9

       2:       11 6c           ori     r17, 0xC1       ; 193

10

       4:       32 1b           sub     r19, r18

11

       6:       5f 87           std     Y+15, r21       ; 0x0f

12

       8:       68 0f           add     r22, r24

13

       a:       0f 44           sbci    r16, 0x4F       ; 79

14

       c:       aa ac           ldd     r10, Y+58       ; 0x3a

15

       e:       57 67           ori     r21, 0x77       ; 119

16

      10:       ee f7           brtc    .-6             ; 0x0xc

17

      12:       29 b9           out     0x09, r18       ; 9

18

      14:       30 f0           brcs    .+12            ; 0x0x22

19

      16:       63 bd           out     0x23, r22       ; 35

20

      18:       8d 26           eor     r8, r29

21

      1a:       28 fa           .word   0xfa28  ; ????

22

      1c:       a4 42           sbci    r26, 0x24       ; 36

23

      1e:       42 c6           rjmp    .+3204          ; 0x0xca4

24

      20:       83 74           andi    r24, 0x43       ; 67

25

      22:       5a 0c           add     r5, r10

26

      24:       e2 98           cbi     0x1c, 2 ; 28

27

      26:       05 27           eor     r16, r21

28

      28:       4a d7           rcall   .+3732          ; 0x0xebe

29

      2a:       d4 f2           brlt    .-76            ; 0x0xffffffe0

30

      2c:       fa 9e           mul     r15, r26

31

      2e:       67 95           ror     r22

32

...

Selbst die STK500-Firmware (diese beliebten .ebn-Dateien) ist ja
verschlüsselt -- obwohl man dessen Firmware an allen Ecken und Enden
mitsniffen kann beim Download.  Beim Dragon würde ich ihnen schon
zutrauen, dass sie den DES- oder AES-Bootloader aus ihren eigenen
Appnotes auch benutzen. ;-)

Hallo Jörg,

>> Immerhin hat der Dragon im
>> Auslieferungszustand nur ein Viertel des RAMs, ...
>
> Mehr braucht er für die 32 KiB eben nicht.

Keine Ahnung, er könnte auch 4 Byte pro Target-Byte brauchen.

Ich habe jetzt das AVaRICE-Experiment mit dem aufgerüsteten Dragon 
gemacht. Resultat leider negativ, um es vorweg zu nehmen.

Deiner Beschreibung konnte ich gut folgen, die war prima.

AVaRICE habe ich unter Linux übersetzt. Nicht ganz so einfach, denn 
unter Linux läuft bei mir nur der Fileserver, der ist nicht wirklich zum 
Entwickeln aufgesetzt. Hat aber letztendlich auf Anhieb funktioniert.

Den Debugger habe ich von WinAVR genommen, dann remote auf die 
Linux-Box. Ein kleines LED-Blinkprogramm habe ich einmal für den 
Mega162, ein anderes Mal für den Mega644 compiliert.

Mit dem Mega162-Elf klappt das gdb-debugging (coole Sache habt ihr da 
gebaut!), beim Mega644 kriege ich schon beim "target remote 
linuxbox:1212" einen Fehler "Remote communication error: Software caused 
connection abort."
Auf der Linux-Seite sagt avarice zuletzt "cannot read program counter", 
response is 0xA0:

1

command[0x07, 1]: 07

2

recv: 0x1b

3

recv: 0x0f

4

recv: 0x00

5

recv: 0x01

6

recv: 0x00

7

recv: 0x00

8

recv: 0x00

9

recv: 0x0e

10

sDATA: reading 1 bytes

11

read:  a0

12

recv: 0xc2

13

recv: 0x92

14

CRC OK

15

Got message seqno 15 (command_sequence == 15)

16

response: A0

17

cannot read program counter

Eine kleine Chance besteht noch: Der Dragon hat ein paar unbestückte 
Positionen für SMD-Widerstände, was aber auch Lötbrücken sein könnten. 
Vielleicht erfährt er so, ob er mit kleinem oder großem Speicher 
bestückt ist...

Nachtrag zu obiger "Chance":

Ich habe drei Widerstandspaare gefunden, die definitiv "Jumper" sind, 
unterhalb des ATmega2560. Dort sind 2 Spalten mit 3 Reihen Widerständen, 
von denen nur jeweils der linke oder rechte bestückt ist.

Durch Bestückung links oder rechts wird eingestellt, ob an den Portpins 
PF0 bis PF2 vom ATmega2560 low oder high anliegt, Pulldown oder Pullup.

Hier sind also 3 Bit für irgendwelche Konfiguration möglich. Vielleicht 
löte ich heute abend da mal Drähte für "Override" an und probiere die 8 
Möglichkeiten durch. (OK, es verbleiben nur noch 7.)
Zu den anderen leeren Widerstandspositionen habe ich noch nichts 
rausgefunden.

Beobachter wrote:

> Unabhängig davon wäre ein HW-Vergleich zwischen dem Dragon und dem
> JTAG-MKII interessant.(Ich kann es leider nicht tun, da ich nur den
> Dragon besitze). Gut möglich, daß der Dragon "nur" ein kastrierter
> JTAG-MKII ist, oder?

Die Software fürs JTAG-Debugging ist kastriert, damit man die JTAG
ICEs überhaupt noch verscherbeln kann.

Die Hardware ist beim Dragon dagegen aufgebohrt.  Das äußert sich
bereits darin, dass der vormalige ATmega128 für die M-MCU durch einen
ATmega2560 ersetzt worden ist.  Von den Features her sollte dir
weiterhin sofort auffallen, dass der Dragon HV-Programmierung kann,
die es sonst nur im STK500 gibt.

JTAG- und debugWire-Module sind zwar als Sourcecode offenbar vom JTAG
ICE mkII genommen worden, aber ich mache mir keine Illusionen, dass
die Leute die Benutzung als vollständiges ICE etwa durch ein paar
Widerstandsbrücken zugelassen hätten.  Ich vermute eher, dass das eine
Art Hardware-ID ist.  Sowas hatte schon das alte JTAG ICE.  Außer,
dass man sich das in einer Message ausgeben lassen konnte, hat die
aber keinen interessiert.

Die Fehlermeldung 0xa0 ist übrigens RSP_FAILED, und das Kommando zum
Auslesen des PCs ist natürlich ein typisches, das man nur zum
Debuggen, nicht aber für den Firmwaredownload via JTAG benötigt.  Ich
habe an dieser Stelle auch aufgehört zu probieren, ich vermute, dass
noch weitere Kommandos auf diese Weise geblockt worden sind.

Nun habe ich die Widerstandsbrücken ausprobiert, ich bin etwas schlauer:

Die von mir beschriebenen Brücken setzen die Hardwareversion der S_MCU, 
das zeigt AVaRICE an. Die Wertigkeit der Bits ist: oberere Reihe (MSB), 
untere, mittlere (LSB). High=rechts heißt gesetztes Bit. Sowaohl mein 
Dragon als auch der von "Beobachter" hat also die Version 6.

Leider verändert sich dadurch nichts, zumindest kann er keinen Mega644 
debuggen.

Das RAM auf dem Dragon scheint kein TAG-RAM zu sein, sondern ist 
schnöder Arbeitsspeicher, "klassisch" per externem Businterface an den 
Mega128 angeschlossen, und zwar als 32 kB. Die oberen Adressbits sind an 
Port B angeschlossen, damit kann er also Bank-Switching machen. Mit dem 
originalen RAM sind da 2 Adressbits angeschlossen, mit dem größeren RAM 
4. Ergibt also 4 bzw. 16 Bänke zu 32 kB.
Wohlmöglich ist das Timing am externen Bus mit dem Adresslatch so 
"straff", daß solch ein schnelles SRAM hilft. Zumindest im 
zero-waitstate-Fall.

Sorry Jungs, es sieht nicht gut aus.

spess53 schrieb:
> Du bist ja ein Frühmerker.

Nach knapp 3 Jahren sollte es auch jeder mitbekommen haben ;-)