mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVM DRAGON 32k Begrenzug aufheben


Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
es gibt ja nun ein billig-jtag von Atmel.

Er kann alle Atmels programmieren. Das Emulieren bzw debuggen ist auf 32 
k beschrängt.
Von atmel Mitarbeiter weis ich dass dies nur per Software begrenzt wurde 
und aufhebar ist.
Er meinte es dürfte eigentlich kein Problem sein dieses aufzuheben. Er 
sei sich deren sogar sicher dass das bald mal von irgend jemand gemacht 
wird.

Weis da jemand schon was von einer Firmwäre odr wie man dies vollbringen 
könnte?

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

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

Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, es hies es wäre nur per software eingegrenzt

Autor: Freudi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mal nen bischen rumgegoogelt und gefragt aber leider nichts neues. 
Wie sieht es bei Euch aus ?

Freudi

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hat das größe Bruder für Speicher?

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei dem RENESAS RC8 Boad war der Debugger immer mit in der App. drin

Suche in den Files nach Size oder STACK . Das steht im Compiler/Linker
Skript.  Startup usw

Autor: Simon Lehmayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die größeren Controller sind in AVR-Studio im Dragon-Debug alle 
ausgegraut! Da muss man das Studio auch noch patchen.
Und das DebugWire-Protokoll ist leider nicht öffentlich... Wenn jemand 
da was hätte, wäre interessant!

Autor: Christian U. (z0m3ie)
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Die hardwareseitige Begrenzung lässt sich meinesachtens relativ leicht
beheben: Auf meinem Dragon ist ein Samsung K6R1008C1D verbaut. Wer sich 
die Lp ansieht wird bemerken, daß rechts und links neben dem Ram noch
Pins vorhanden sind. Von der Pinbelegung wurde dort ein Samsung
K6R4008C1D (126kx8) draufpassen.

MfG Spess

Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das wäre doch fast ein Versuch wert

Autor: cguru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Von der Pinbelegung wurde dort ein Samsung
> K6R4008C1D (126kx8) draufpassen.

Hmm...fast schon so, als hätte man das irgendwie gewollt...

Autor: cguru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zudem führen von den Pads Leiterbahnen weg...

Autor: Simon Lehmayr (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Pins hab ich auch schon bemerkt :-)
Das RAM ist bei mir ein Samsung K6R1008C1D-KI10 mit 128Kx8 Bit (also 
128kByte) 5V, 10ns! Und nu? Wo aktiviere ich das für 128kB-AVRs?
(http://www.datasheetarchive.com/search.php?s=60&q=...)

Autor: Simon Lehmayr (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das 4008 ist ein 512x8 Bit SRAM mit 512kByte!

Autor: Fabian B. (fabs)
Datum:

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

Gruß
Fabian

Autor: Simon Lehmayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist das JTAG2 für zukünftige Aufgaben vorbereitet worden?
Der 4008 und der 1008 sind, so wie das Dragon-Board es vorsieht, 
pinkompatibel... Samsung hat dummerweise diese SRAM-Serien abgekündigt.
Selbst wenn ich jetzt den Chip tausche, kann ich trotzdem nichts damit 
anfangen, oder?

Autor: cguru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke man müsste auf jeden Fall die Firmware verändern. Den 4008 
gibts vielleicht noch in Restposten.

Autor: Simon Lehmayr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Cypress gibt es ein Gleichteil, den CY7C1049D.

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Ich bin auch gerade über diese beknackte Begrenzung gestolpert.

Mit den 32KB habe ich ja erstmal keinen Klemmer.
Macht nur keinen Spass, dass der AT90CAN128 den ich verwenden möchte 
grundsätzlich nicht mit dem Dragon debugbar ist.

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dank erstmal.

Aber das AVR-Studio brauche ich schon da ich zunächst einmal nur mit den 
Port-Pins spielen wollte um die Hardware zu testen.
Die 90CAN32 sind geordert aber vor Montag wird das nichts...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, alles was ich im ersten Schritt machen möchte ist:

---
int main(void)
{
 while(1);
}
---

Dann Debugging starten und per JTAG ein paar Pins wackeln lassen, so 
rein statisch um erstmal die Platine zu überprüfen und ein paar Pegel zu 
messen.

Da interessieren mich die 32 KB herzlich wenig, es muss nur überhaupt 
funktionieren.
Und das die grösseren Steine auch mit Code-Begrenzung nicht 
funktionieren finde ich doch sehr schwach.
Zumal die Entscheidung das zu tun offenbar rein politisch ist. :-(

Na wenigstens kann ich per JTAG flashen, dem Board habe ich nämlich 
überhaupt keinen ISP spendiert.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde in meinen Dragon durchaus mal probehalber ein größeres RAM 
einlöten. Vielleicht erkennt er es ja automatisch, oder nach Umsetzen 
von 2 Lötbrücken dort in der Nähe...  </wuensch_mode>

Ein passendes RAM habe ich hier zu kaufen gefunden:
http://darisusgmbh.de/shop/product_info.php/info/p...

Der Preis ist in Ordnung. Ich hatte recht hohe Versandkosten in 
Erinnerung, habe mich aber wohl verguckt.
Will noch jemand auf Verdacht so ein RAM, oder andere Teile von dort?

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das Limit in der Firmware steckt glaube ich nicht, dass ein Tausch 
des Speichers irgendeine Auswirkung hat.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Immerhin ist der Footprint für mehr vorbereitet...
Schaun' wir mal, ich habe das RAM jetzt bestellt.
Für Tipps zum Firmware-patchen bin ich dann ggf. dankbar.  ;-)

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knirsch

Ich habe gerade gut eine Stunde damit verbracht herauszufinden,
warum mein minimales Test-Programm die LED's an meinem 90CAN128 nicht 
zum leuchten bringt.

Mein Board hat nur einen JTAG-Anschluss und keinen ISP, war wohl ein 
Fehler.
Denn damit das Programm anläuft muss ich die Programmier-Session beenden 
oder den JTAG abziehen - super.

Morgen bekomme ich 90CAN32, bin ja mal gespannt, ob das mit denen 
funktioniert.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn man aus dem ICE ,,ausgeloggt'' ist, hängt sein JTAG-Interface
>einfach komplett in der Luft.

Na, das habe ich doch geschrieben, ich muss entweder die 
Programmier-Session beenden, mich also ausloggen oder aber das Kabel 
abziehen.

Und mit dem 90CAN32 ist es jetzt das gleich Spiel, solange der Dragon 
zum Programmieren per JTAG mit dem Controller verbunden ist läuft das 
Programm nicht an.

Mit dem ISP lasse ich normalerweise die Verbindung einfach stehen.

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.

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

Blöd.

Wenigstens kann ich den 90CAN32 mit dem Dragon debuggen. :-)

Was auch ich auch blöd finde ist, dass man nicht einfach das Debugging 
starten kann solange man im Programmier-Modus ist.
Wenn die Software schon so schlau ist das zu merken, sollte sie auch 
gefälligst den Programmier-Modus selbst beenden können, finde ich.

Aber naja, das Programmieren muss ich ja jetzt sowieso immer beenden...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rudolph (Gast)
Datum:

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

Äh, habe ich das im Datenblatt falsch interpretiert?
Den Reset braucht man doch, um per JTAG flashen zu können, oder nicht?

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

Igitt, Kommando-Zeile. :-)

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

Eben nicht, die beiden Modi schliessen sich gegenseitig aus.
Naja, AVR-Studio-Macke, schon trefflich formuliert. :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
$ avr-objdump -D -m avr5 -b binary foo | head -30

foo:     file format binary

Disassembly of section .data:

00000000 <.data>:
       0:       22 8a           std     Z+18, r2        ; 0x12
       2:       11 6c           ori     r17, 0xC1       ; 193
       4:       32 1b           sub     r19, r18
       6:       5f 87           std     Y+15, r21       ; 0x0f
       8:       68 0f           add     r22, r24
       a:       0f 44           sbci    r16, 0x4F       ; 79
       c:       aa ac           ldd     r10, Y+58       ; 0x3a
       e:       57 67           ori     r21, 0x77       ; 119
      10:       ee f7           brtc    .-6             ; 0x0xc
      12:       29 b9           out     0x09, r18       ; 9
      14:       30 f0           brcs    .+12            ; 0x0x22
      16:       63 bd           out     0x23, r22       ; 35
      18:       8d 26           eor     r8, r29
      1a:       28 fa           .word   0xfa28  ; ????
      1c:       a4 42           sbci    r26, 0x24       ; 36
      1e:       42 c6           rjmp    .+3204          ; 0x0xca4
      20:       83 74           andi    r24, 0x43       ; 67
      22:       5a 0c           add     r5, r10
      24:       e2 98           cbi     0x1c, 2 ; 28
      26:       05 27           eor     r16, r21
      28:       4a d7           rcall   .+3732          ; 0x0xebe
      2a:       d4 f2           brlt    .-76            ; 0x0xffffffe0
      2c:       fa 9e           mul     r15, r26
      2e:       67 95           ror     r22
...

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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
command[0x07, 1]: 07
recv: 0x1b
recv: 0x0f
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xc2
recv: 0x92
CRC OK
Got message seqno 15 (command_sequence == 15)
response: A0
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...

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant wäre, ob die Bestückung überall gleich ist.
(Bei allen folgenden Positionsangaben hatte ich die USB-Schnittstelle 
links).

Die von Dir angesprochenen R-Spalten, von oben nach unten:
Links: frei, bestückt, frei; Rechts: bestückt, frei, bestückt.

Freie Pads finde ich zusätzlich:
unterhalb der LEDs - zwei Spalten, von oben nach unten:
Links: bestückt, frei; Rechts: bestückt, frei, bestückt.

unterhalb des RAM-ICs, auf dessen linker Seite, wieder zwei Spalten a 
drei Widerstände, vor oben nach unten:
Links: Spalte komplett bestückt; Rechts: frei, frei, bestückt.

Desweiteren gibt es bei mir noch zwei freie Pads im Bereich des 
Spannungsreglers, was mir allerdings für dieses Thema ziemlich unwichtig 
erscheint.


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 Firmware-Uploader scheinen zumindest verwandt 
zu sein (der ISP-MKII gehört auch dazu). Der logische Aufbau der 
Firmware-Dateien (Endung ".dat") erscheint im Hex-Editor für alle drei 
sehr ähnlich. Da die Firmware(s) aber verschlüsselt zu sein scheinen, 
halte ich diesen Weg für eine Sackgasse.


RAM-Größe hin oder her, wenn man überlegt, daß der alte JTAG gar keinen 
RAM hatte (oder irre ich mich da?) und trotzdem die großen ATMegas 
debuggen kann, dann muß das mit dem Dragon auch irgendwie gehen... ;-)

Ich drücke Dir die Daumen, Jörg! :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist zwar ein wenig OT aber da ich das hier aufgebracht habe...

Nachdem ich heute endlich mal die Reset-Leitung am JTAG aufgekratzt habe 
läuft die Software gleich nach dem Flashen auch an, macht schonmal ein 
"Problem" weniger. Prima.

Meine beiden per SPI angebundenen 8-Kanal DAC's tun auch, jetzt bleibt 
mir nur, das CAN-Modul mal zu erforschen...

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Beschränkung ist mit AVRStudio 4.18 "heimlich" aufgehoben worden 
(auf den Atmel-Seiten steht sie immer noch, sichelrich, damit überhaupt 
irgendwer den JTAG ICE mkII noch kauft)

http://www.mikrocontroller.net/articles/AVR-Dragon

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Die Beschränkung ist mit AVRStudio 4.18 "heimlich" aufgehoben worden...

Du bist ja ein Frühmerker.

>(auf den Atmel-Seiten steht sie immer noch, sichelrich, damit überhaupt
>irgendwer den JTAG ICE mkII noch kauft)

Blödsinn. Das JTAG ICE mkII ist immer noch eine andere Liga als der 
Dragon.

MfG Spess

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Du bist ja ein Frühmerker.

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.