Hallo zusammen, ich verwende das AT91SAM7S64 Board hier aus dem Shop und bin mittlerweile so weit, mit dem gcc (WinARM) Programme für RAM und ROM zuerzeugen und diese laufen zu lassen :-) Das Debuggen der im RAM Software funktioniert super, ich kann auch die Sóftware im ROM starten - soweit so gut. Was nicht funktioniert ist das Setzen von Brakepoints im Flash - soweit ich weiss sollte der EmbeddedICE Teil in diesen Kontrollern 2 HW Brakepoints haben, kann ich die mit gdb bzw. insight verwenden? Wenn ja, wie gehts das? Als JTAG Interface verwende ich übrigens das Wiggler kompl. Ding aus dem Shop und habe damit unter XP auf meinem Laptop eigentlich keine Probleme... Viele Grüße, Christoph
Hi! Ich habe auch das Board aus dem Shop + Wiggler Interface, bin aber noch nicht dazu gekommen viel damit zu machen. Mit dem GDB + ocdremote geht soweit ich weiß das Debuggen im Flash nicht. Du könntest Dir aber folgendes Sourceforge-Projekt ansehen: http://jtagarmgdbsrvr.sourceforge.net/ Ich versuche gerade das Programm auf Linux und Verwendung von PPDev umzustellen. Mit der Kombination ocdremote + gdb hatte ich bisher Probleme beim Debuggen im RAM. Vielleicht mache ich aber auch etwas beim Compilieren falsch. Könntest Du mir vielleicht mal ein kleines Beispiel-Projekt, das bei Dir läuft inkl. .ld und Makefile senden. (LED-blinken oder so etwas). email: dirk.doerr AT gmx de Viele Grüße Dirk
Gast
#264404
"Mit dem GDB + ocdremote geht soweit ich weiß das Debuggen im Flash nicht." Mit der aktuelle Version von ocdremote geht es. Es ist halt bei den 2 Hardware-Breakpoints Schluss, weil er keine Soft-Breakpoints ins Flash legen kann.
Ich hab die WinARM Beispiele so umgebaut, dass auf diesem Board sowohl im RAM als auch im ROM sauber laufen, ich muss allerdings noch etwas aufräumen und sortieren, den Code schön formatieren usw., ich versuche sie heute abend fertig zu haben, ich stell es denn hier rein, falls es noch jemanden interessiren sollte... Ich nutze die neuste Version von ocdremote, 2.14 oder so. Das mit den zwei Breakpoints seh ich auch so, nur scheint mein insight 6.4.50 diese nicht zu verwenden...
Gast
#264406
Ich nehme auch gerade mein Board in Betrieb. Die angepassten Beispiele würden mir einige Schwierigkeiten ersparen. Ich bin bisher noch nicht zum Debuggen vorgedrungen. Das ist auch eine Herausforderung. Ich wollte gerade hier recherchieren, ob das im Shop erhältliche Kabel mit dem AT91 funktionier, weil es ja offensichtlich für den Phillips gedacht ist. Das hat sich ja nun erübrigt, oder? Ich werde es also bestellen. Ein bisschen Bammel habe ich noch davor den Debugger zum Laufen zu kriegen, oder ist das alles so selbsterklärend? servus Dirk
Ich fand es bisher alles ganz ok, hab aber dennoch ein paar Abende gebraucht, bis ich soweit war. Und die Beispiele mussten definitiv angepasst werden, um im RAM zu laufen... Wenn ich jetzt noch die beiden Hardware Breakpoints setzten kann, bin ich völlig glücklich :-)
Ich hab noch einmal weiter nach hardware breakpoints gegoogled, und habe diese Seite gefunden: http://rod.info/arm.html Hier steht beschreiben, wie man die beiden HW breakpoints verwenden kann. Da sind auch ein paar Scripte angegeben, um das ganze zu vereinfachen. Ich schaue mir die Sachen heute abend an test den Kram mit meinem AT91. Wenn alles funktioniert, werd ich die (eventuell angepassten) Scripte hier reinstellen.
Gast
#264409
Ich habe es nicht mit Atmel ausprobiert, sondern mit Philips, aber die Debug-Cell ist ja die gleiche. Integration in gdb (via Eclipse) ging transparent, der auf rod.info beschriebe arg umständliche Weg per manueller Einstellung der Hardware-Breakpoints war nicht erforderlich, das hat gdb selber hinbekommen.
Das mit Eclipse klingt interessant, ich habs schon installiert und wollte mir das bald noch ansehen. Was meinst Du mit transperent? Hast Du Konfigurationsdateien zum Testen? Welchen gdb benutzt du?
Gast
#264411
http://www.olimex.com/dev/pdf/ARM%20Cross%20Development%20with%20Eclipse%20version%202.pdf Transparent heisst: gdb setzt die Hardware-Breakpoints selbst. Macht er ja sonst auch, ging bloss mit älteren ocdremote wohl nicht. Ich habe damit Flash-Debugging mit Breakpoints hinbekommen, und jenseits von 2 gesetzten Breakpoints gab's ganz passend einen Fehler.
Gast
#264412
Apropos ocdremote: Der Wiggler funktioniert erheblich besser, wenn man einen separaten alten Win9x Rechner dafür verwendet. Auf Win2K/XP geht das nicht so gut. Dort in einer Batch-Schleife ocdremote mit maximaler Speed starten, und auf dem Arbeitsrechner im Eclipse statt localhost diesen Rechner eintragen.
Hier die sourcen für ein auf dem Board (in RAM und ROM) lauffähiges Demo. Ich hab mit meinem XP Laptop übrigens bisher keinerlei Probleme mit dem Wiggler Nachbau, kann meine Win98 Rechner also noch eingestaubt lassen... Die Breakpoints script funktionieren auch, und sind gar nicht mal so umständlich - mal sehen ob mich Eclipse noch überzeugen kann :-)
Gast
#264414
Mit welchem Tempo läuft der Wiggler? Bei mir ging max S5, d.h. 80KHz, während unter Win98 die vollen 380KHz drin waren.
Ich verwende ihn mit S1, also full Speed... Nach Einstellen einer Packet length von 1024 im GDB läd er mit ca. 20kByte / s ins RAM...
Und wie schnell ist das Notebook? Was exakt für eine Software verwendest Du, um den Wiggler anzusteuern?
Gast
#264417
Hi, Danke für den Code. Bin mal gespannt, ob's bei mir läuft heute abend. Ich habe gestern das PIO Sample für mich angepasst, das war dann doch nicht so wild. Könntest du noch ein paar Stichworte geben, wie der Debugger zum laufen zu bewegen ist? Ich habe momentan aber noch kein Kabel, deshalb ist die Frage noch etwas akademisch. À propos Kabel. Ich stolpere immer wieder über den Satz: "Wiggler kompatibles Kabel...Yahoo Groups...more reliable" (na ja so ähnlich halt.) Der mir suggeriert, es gäbe bessere Schaltpläne, aber dann muss ich selber löten...
Gast
#264418
Betr. "Kabel": Die Formuliert stammt moeglicherweise von meiner
Web-Seite ("wiggler_intro"). Falls ja: ich habe dort geschrieben,
dass ich mit dem Olimex-Nachbau getestet habe, dieser funktioniert bei
mir mit gbd/ocd-remote, aber (mit W2K) nicht "in schnell". Das
Problem war hier schon mehrfach Thema. Wenn kuerzlich richtig gelesen,
scheint es unter Win9X schneller zu funktionieren. Das der simpler
aufgebaute Adapter besser funktioniert, wurde in der LPC yahoo-Group
und anderen Foren/Mailinglisten mehrfach behauptet, habe es selbst nie
ausprobiert. Die Schaltungen der "einfachen" Wiggler
('244+Transistor) sind eigentlich von der Pegelanpassung nicht besser
als das Olimex-Teil, eher im Gegenteil.
Martin Thomas
Gast
#264419
@mthomas Ja, war deine Seite. Danke für die Info. Ich werde das Kabel aus dem Shop bestellen. dirk
Gast
#264420
Hi,
Ich habe gestern Abend das UART-Beispiel mal ausprobiert.
Irgendwann habe ich korrekte Ausgaben auf meinem Hyperterm erhalten,
wenn ich den 'RESET'-Taster betätigte.
Dann habe ich immer wieder mit Abstürzen von SAM-BA, hängenbleiben von
Hyperterm und dergleichen zu tun gehabt. Ich hatte bisher immer den
Eindruck die serielle Schnittstelle arbeite einfach und problemlos und
sei somit ein Quell immerwährender Freude für jeden Programmierer.
Vieleicht liegt's auch an meinem USB-Seriell-Adapter, oder am
Hyperterm, an SAM-BA, das vermutlich TCL-TK einbindet um, was auch
immer zu machen. Ich habe dann versucht zumindest einen Ersatz für das
Hyperterm einzusetzen, da leider gar keine Zeichen.
Nachdem vorher alles so schön funktioniert hatte war das schon ein
heftiger Dämpfer.
servus
Dirk
@Christoph
Bei mir funktioniert Dein Beispiel sowohl im Flash als auch RAM gut.
Ich kann auch Debuggen.
Gruß
Dirk
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.