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?
Soweit ich weis liegt das daran, dass nur 32kb SRAM auf dem board vorhanden sind.
Habe mal nen bischen rumgegoogelt und gefragt aber leider nichts neues. Wie sieht es bei Euch aus ? Freudi
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.
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
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!
Ich denke, das die im AVR Studio ausgegraut sind ist in den XML dateien hinterlegt dazu wird man das Executable nicht anfassen müssen.
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
> Von der Pinbelegung wurde dort ein Samsung > K6R4008C1D (126kx8) draufpassen. Hmm...fast schon so, als hätte man das irgendwie gewollt...
Angehängte Dateien:
-
sram_k6r1008_pinout.gif
24 KB
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=K6R1008)
das JTAG-ICE2 hat aber ein 512Kx8 SRAM drauf. da scheints wohl doch noch etwas mehr zu brauchen. Gruß Fabian
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?
Ich denke man müsste auf jeden Fall die Firmware verändern. Den 4008 gibts vielleicht noch in Restposten.
@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
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?
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.
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...
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.
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.
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.
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/p9010_SM614008HSA10J 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?
Da das Limit in der Firmware steckt glaube ich nicht, dass ein Tausch des Speichers irgendeine Auswirkung hat.
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.
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. ;-)
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.
> 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).
>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...
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...
>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. :-)
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.
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! :-)
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.
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...
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
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
spess53 schrieb: > Du bist ja ein Frühmerker. Nach knapp 3 Jahren sollte es auch jeder mitbekommen haben ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.