Guten Tag zusammen! Ich bin fast am verzweifeln... Ich arbeite hier z.Z. mit einem TMS320F2812 von TI. Allerdings kenne ich das Teil erst seit drei Tagen, und darum bereitet es mir auch noch diverse Schwierigkeiten. Ich programmiere das Teil mit CCStudio. Nun möchte ich gern einfach einen Pin toggeln. Wie ich die Port-Register dafür ansprechen muß weiß ich schon. Mein Problem ist aber ein ganz anderes: immer, wenn der Debugger in die Funktion "DELAY_US(xxx)" läuft scheint sich das Programm in der Datei DSP281x_DefaultIsr.c auf zu hängen. Ich weiß aber nicht was das Programm da will und erst recht nicht warum! Würde mich freuen, wenn sich jemand melden könnte, der sich mit TIs und der delay-Funktion auskennt, gern auch per ICQ (135209324). Danke, vG, Jojo P.S.: ich war mit dem Problem schon in einem anderen Forum, glaube aber hier richtiger zu sein :)
Mach doch mal ein "Minimal-Projekt" draus, das den Fehler enthält und fehlerfrei compiliert und lade es hier hoch. So ganz ohne Code wird es schwierig werden dir zu helfen...
Hi und danke für die Antwort! Das Projekt, an dem ich hier am rumdoktorn bin wird ja einwandfrei kompiliert. Ich hatte gehofft es wäre ein bekanntes Problem und einer hätte gesagt "So und so läufts". Ich muß gestehen, daß das mit dem Miniprojekt gar nicht so einfach ist, weil ich noch nicht ganz durchschaut habe, was ich wann wo "headern" und "includen" muß. Und welches die "richtige" .cmd-Datei ist hab ich auch nur durch ausprobieren rausbekommen. Darum hab ich erstmal alles geheadert und included, was da war. Ich versuchs mal in Worten zu beschreiben: wenn der Aufruf "DELAY_US(xx);" erreicht wird springt er in die Datei "DSP281x_usDelay.asm", wo steht: .def _DSP28x_usDelay .sect "ramfuncs" .global __DSP28x_usDelay _DSP28x_usDelay: SUB ACC,#1 BF _DSP28x_usDelay,GEQ ;; Loop if ACC >= 0 LRETR Ferner steht in der Datei "DSP281x_Examples": "#define DELAY_US(A) DSP28x_usDelay(((((long double) A * 1000.0L) / (long double)CPU_RATE) - 9.0L) / 5.0L)", CPU_RATE ist auch definiert. Ja, und dann verrennt er sich in der Datei "DSP281x_DefaultIsr.c". Ich bin leider (noch) kein begnadeter Programmierer, sonst könnte ich bestimmt genauere Angaben machen. Wäre trotzdem toll, wenn sich da jemand noch Gedanken drüber machen könnte... Danke, Gruß, Jojo
Ach du Himmel... es lag wohl dadran, daß ich die Datei "DSP281x_FLASH.cmd" eingebunden hatte anstatt der Datei "F2812_EzDSP_RAM_lnk.cmd". Jetzt scheint es zu funktionieren. Kann mir aber vielleicht jemand erklären warum? Ich versteh das noch nicht so ganz, wann ich welche Datei brauche. Vor allem bei den .cmd-Dateien blicke ich nicht durch. Außerdem gibt es beim Übertragen auf das Target die Warnung "No sections were found that map to Flash." und danach die Warnung, die ich in den Anhang gepackt habe. Kann mir das evtl. jemand erläutern? Würd dadrüber nämlich gern besser Bescheid wissen. Ich scheine etwas zu verwähnt vom AVR-Studio zu sein...
In der Datei DSP281x_usDelay.asm steht irgendwo
> .sect "ramfuncs"
d.h. dass der Inhalt der Datei in diese Sektion im Speicher gepackt
werden soll. Wenn du nun in DSP281x_FLASH.cmd nachsiehst wirst du keine
Sektion mit einem solchen Namen finden. In F2812_EzDSP_RAM_lnk.cmd
hingegen wird es diese Sektion geben und der Programmteil kann dort
abgelegt werden.
Die Warnung aus dem Bild kommt ebenfalls daher.
> Ich scheine etwas zu verwähnt vom AVR-Studio zu sein... Ich würde sagen das liegt nicht (nur) am CCS, sondern (auch) an der Architektur, die mit AVR's nicht wirklich vergleichbar ist. Ich habe selbst noch keine Erfahrung damit, aber meines Wissens muss sich man bei, z.B., ARM, AVR32, ... ggf. auch mit Linker-Command-Files rumschlagen.
Ah, ok, danke :) ! Aber was kann ich nun gegen die Warnung von meinem obigen Post machen? Fehlt mir da wieder ne .cmd oder so? Als ich vorher noch die "DSP281x_FLASH.cmd" anstatt der "F2812_EzDSP_RAM_lnk.cmd" eingebunden hatte kam die Meldung nicht. Beide einbinden geht allerdings nicht, weil er dann beim Kompilieren ganz viel nörgelt...
Willst du das Programm im RAM oder im Flash haben? Normalerweise müsste die Warnung kommen wenn du die DSP281x_FLASH.cmd eingebunden hast und mit der F2812_EzDSP_RAM_lnk.cmd müsste sie weg sein. Müsste ich aber morgen mal nachsehen. Beide einbinden geht natürlich nicht, weil es dann verschiedene Sektionen mit gleichem Namen gibt.
@Micha: ja, genau das scheint das Problem zu sein, der Kompiler sagt nämlich mehrfach "multiple definitions of SECTION named '.xxx' ", wenn ich beide einbinde. Ich bin mir nicht ganz sicher, in welchen Speicher das Programm soll. Wie gesagt, ich kenne mich auf den Controllern noch kaum aus. Ich möchte das nachher so haben, daß ich nur den Strom anmachen muß und dann läuft das Programm los. Die Warnung von oben "No sections were found that map to Flash." mit dem obigen daraufflogenden Fenster kommt, seitdem ich die "F2812_EzDSP_RAM_lnk.cmd" eingebunden haben. Das deutet für mich irgendwie darauf hin, daß irgendein Bereich vom Flash noch nicht definiert ist. Aber ich weiß es nicht, sonst wär ich grad nicht hier ;) ...
Naja für Entwicklung und Debugging kannst du es aus dem RAM laufen lassen, sprich dein Programm wird in das RAM kopiert und dort ausgeführt. Da das RAM aber flüchtig ist, musst du das Programm später im Flash speichern. Schau dir spra958 an und nimm am besten gleich die *.cmd-Dateien von dort. Erstell dir 2 Konfigurationen (z.B. Debug und Release) in füge beide *.cmd-Dateien ein. Bei Debug setzt du bei der *_flash.cmd das Hächen bei "Exclude from build" und bei Release setzt du es bei *_ram.cmd. Zusätzlich musst du bei Release noch die InitFlash ins RAM kopieren. Dabei hilft dir das Symbol _DEBUG (#ifndef _DEBUG memcpy... #endif). Der Rest steht in oben genanntem Dokument. Falls es bei der Flash-Version zeitliche Probleme gibt hilft dir spraau8 weiter.
OK, das Dokument kannte ich noch nicht. das werd ich mir mal zu Gemüte führen. Aber folgendes versteh ich immer noch nicht... Ich hab die *_ram.cmd ja eingebunden, damit diese delay-Funktion richtig läuft. Das war ja das Hauptthema ;) ... Ich würde ja auch auf die ram-cmd verzichten, wenn ich die delay-Funktion auch im Flash ans laufen kriege. Wie würde(s)t du/ihr da vorgehen? Soll ich die .cmd "einfach" umschreiben? Vielen Dank bisher und im voraus!
Ich würde es folgendermaßen machen bzw. habe es folgendermaßen gemacht: wie bereits geschrieben beide cmd-Files einbinden und mittels "Exclude from Build" immer eines davon "deaktivieren". Dann in der DSP281x_usDelay.asm aus dieser Zeile .sect "ramfuncs" diese .sect "secureRamFuncs" machen. Dann sollte es mit beiden spra958-cmd-Files gehen. Dann kannst du oben zwischen den Konfigurationen wählen (siehe Bild), wobei Debug -> RAM, Release -> Flash. Anlegen würde ich beide. Wenn du nur eine für das Flash anlegst, musst du jedes Mal über "Tools" -> "F28xx On-Chip..." flashen. Anders finde ich das wesentlich komfortabler.
Hi Micha (und die anderen ;) ), ich bin grad so vorgegangen, wie du es oben vorgeschlagen hast. Allerdings kam beim Kompilieren die Warnung, das "ramfuncs" irgendwo nicht spezifiziert wurde. Außerdem funktionierte die dalay-Funktion wieder nicht. Ich arbeite mich grad durch das spra958 und die Beispielprojekte. Ich befürchte ich muß das nochmal neu machen :( ... Aber irgendwie kommen da immer mehr Fragen auf. Zum beispiel, warum ich bei den Beispielprojekten manchmal nur eine Ausfwahlmöglichkeit oben bei "Debug" oder "Release" habe... Hast du vielleicht eine eMail-Adresse oder einen InstantMassenger? Vielleicht würd das die Kommunikation erleichtern. Ich fasse nochmal zusammen, was ich möchte: ich möchte für den Controller TMS320F2812 in C ein Programm schreiben, daß dann läuft, wenn ich den Strom anmache (Release und Flash?) und ich möchte die Möglichkeit haben die (oder irgendeine) delay-Funktion zu benutzen... wie gesagt, wenn ich da allein in der Lage zu wäre dann wäre ich nicht hier ;) VG
>Hi Micha (und die anderen ;) ), Die anderen? Welche anderen? Ich bin doch gar nicht schizophren... ;) >Allerdings kam beim Kompilieren die Warnung, das "ramfuncs" irgendwo >nicht spezifiziert wurde. Außerdem funktionierte die dalay-Funktion >wieder nicht. Das hängt höchstwahrscheinlich zusammen. Lies dir dazu nochmal meinen Beitrag von gestern, 16:34 durch. So etwa Zeile 3 bis Zeile 8. >Zum beispiel, warum ich bei den Beispielprojekten manchmal nur eine >Ausfwahlmöglichkeit oben bei "Debug" oder "Release" habe... Naja, bei den Beispielprojekten machen die das auch anders. Du solltest nur die beiden *.cmd-Files aus den Beispielen nehmen und nicht das ganze Projekt. Also z.B. *.nonbios_flash.cmd und *.nonbios_ram.cmd (den genauen Namen kann ich dir grad nicht sagen). Unter, ich glaube, Project -> Configuration kannst du neue Konfigurationen anlegen bzw. schon bestehende kopieren and umbenennen. Ich denke das sollte dir weiterhelfen.
Ich meinte ja die anderen, die evtl mitlesen und den Kopf schütteln ;) Klar hab ich deinen Beitrag gelesen. Und wie in meinem dann ja auch steht hab ich das dann auch umgesetzt. Daraufhin kommt dann "warning: creating output section ramfuncs without SECTIONS specification" trotz des "secureRamFuncs" in der delay und der eingebundenen F2812_noBIOS_flash.cmd. Und die delay-Funktion stürzt ab, wenn die Zeile "BF _DSP28x_usDelay, GEQ" erreicht wird. Dann gehts wie beschrieben in eine Endlosschleife in der Datei "DSP281x_DefaultIsr.c". Ist die Interrupt-Tabelle vielleicht falsch angelegt? Und wie könnte ich das beheben? Hab was gelesen von einem .reset-Vector, der vielleicht nicht passen könnte... Das mit der "Unkomfortabilität" mit der auswahl von Debug und Release und so und dem ständigen flashen nehm ich im moment in Kauf, da ich größere Probleme hab ;) ...
In die ISR geht er nur, weil er DelayUs nicht findet und damit irgendein undefiniertes Verhalten abgefangen wird. Darfst du das komplette Projekt hochladen? Falls ja mach das. Falls nein: darfst du es mir per Email schicken? Evtl. kannst du auch ein neues Projekt anlegen, in dem nur die DelayUs aufgerufen wird. Das könnte dann auch als Muster für evtl. "Nachfolger" dienen.
Hi nochmal! Ich schätze ich darf das Projekt nicht hochladen, weil es sich dabei um einen Teil einer Diplomarbeit handelt. Aber ich kann es ja "abspecken". Hoffe, daß ich da alle Dateien für zusammen kriege. Mich nervt total, daß ich mich mit solchen Sachen aufhalten muß, weil ich lieber Code schreiben würde. Ich möchte voran kommen! Aber es ging ja schon gut los, als ich nach Handbuch vorgegangen bin und die geforderten Dateien nicht vorhanden waren! Ich bin wirklich gewillt mich in den ganzen Kram rein zu arbeiten, aber dieses CCS macht mich irgendwie fertig... seufz Ich schau mal, was ich hochladen kann.
So, hab mal was hochgeladen. Die eingebundene Datei "test.c" ist die, mit der main-routine. Was sinnvolles steht da nicht drin, ist eben ein Test :) ... Ich hoffe ich hab alle Dateien dabeigepackt und, daß ich alles "sensible" rausgenommen hab... Wenn dir das hier übers Forum umständlich wird steht weiter oben ja auch meine ICQ-Nummer. Danke schonmal...!
ach nochwas... das Projekt ist jetzt wieder in dem Zustand, wie ich es in meinem Post vom 30.03. 10:40 zum laufen gebracht habe. Habe also die sache mit "secureRamFuncs" nicht berücksichtigt. Das war halt die letzte Version, die "am wenigsten" Macken hatte. Sie lässt sich kompilieren (hoff ich) und läuft im Debug-Modus so, wie ich wollte: stumpf erstmal einen Pin toggeln, weil da eine externe Watchdog-Hardware dranhängt...
Versuch es mal damit. So sollte es sowohl aus dem RAM als auch aus dem Flash laufen (nicht getestet). Ich habe mir auch erlaubt ein wenig "aufzuräumen". Die Library wird in den Build Options eingestellt (zumindest habe ich es in der TI-Schulung so gelernt; anders geht es aber wohl auch), ebenso der Include-Pfad wenn die *.h nicht direkt im Projektverzeichnis liegen. Des Weiteren habe ich einige Dateien von der Compilierung ausgeschlossen, erkennbar am fehlenden Pfeil (im Ordner Source). Teils brauchst du sie (höchst-) wahrscheinlich nicht, teils haben sie Fehler verursacht, da dadurch Symbole doppelt erstellt wurden. Hier musst du ggf. testen und spielen. Ich bitte um Feedback...
Ich habe noch was vergessen: - bei den Librarys würde ich immer aus dem CCS-Verzeichnis nehmen - das ist aber dir überlassen. - das Projekt soll nur als Beispiel dienen. Du kannst es natürlich gerne wieder umbauen und ändern...
Hallo und erstmal vielen Dank für deine Bemühungen! Das mit den Libs wußte ich noch nicht. In dem Handbuch stand, daß ich sie manuell einfügen soll. Aber ok, ich hab sie weggelassen und es entsprechend in den Build Options eingestellt. Das funktioniert auch soweit. Wenn ich jetzt flashe gibt es immernoch diese Meldung, wie in meinem Post vom 30.03., 10:40. Ich hab die Vermutung, daß es damit auch irgendwie zusammen hängt, daß die delay-Funktion immer noch nicht läuft. Ich bin ja schon "froh", daß nicht mehr wild irgendein Interrupt ausgelöst wird. Aber jetzt bleibt er einfach bei dem letzten Befehl "LRETR" stehen. Aber ohne die Schleife vorher komplett durch zu arbeiten (ACC runter zu zählen). Das alles passiert, wenn ich dieram-Datei excludet habe und auf Release gestellt habe und dann flashe... seufz Ich hab ja auch schon darüber nachgedacht das alles ohne delay zu versuchen, aber dann muß ich für jedes bißchen warten ja immer einen Timer anschmeißen oder die Routine selbst schreiben. Aber den Gedanken find ich echt mal blöd, weil ich doch nicht das Rad neu erfinden will...
Ach ja, wegen >- das Projekt soll nur als Beispiel dienen. Du kannst es natürlich gerne > wieder umbauen und ändern... Es wäre ja nicht schlau von mir, wenn ich den Rat von LEuten, die mehr Ahnung haben, nicht annehmen würde :)
Hmm - wenn ich das Projekt im Simulator laufen lasse (habe gerade kein Board zur Hand) scheint es zu laufen. Läuft es denn aus dem RAM?
Ja, Ram läuft ja, das ist kein Problem. Das wundert mich ja auch. HAtte grad Mittagspause und jetzt hat mir hier einer mein Board weggeschnappt. Kanns also auch grad nicht testen. Hast du denn so insgesamt eine Idee oder einen Verdacht, wodran das liegen könnte? KAnn es evtl. was mit meinen Einstellungen von CCS zu tun haben?
Wie es aussieht werde ich das Board heute wohl nicht mehr wieder kriegen. Das ist ja mal ungünstig. Ich denke mal, daß ich es morgen wieder haben werde. Ich würde mich echt freuen, wenn du hier noch etwas am Ball bleiben würdest. Hier im Labor bin ich nämlich z.Z. der einzige, der sich da rein arbeitet. Darum hab ich hier auch im Moment noch keinen, den ich wegen Problemchen ansprechen könnte. Aber wie gesagt... danke auf jeden Fall und ich werd mich morgen früh melden, ob das Programm jetzt läuft. Solange probier ich noch rum...
Der Fehler kommt daher, dass etwas was im RAM stehen sollte nicht im RAM steht, sprich nicht dorthin kopiert wurde. In diesem Fall ist/war es die Funktion "InitFlash". Code, der den Flash initialisiert darf nicht im Flash stehen, sondern muss aus dem RAM ausgeführt werden. Siehe Zeile 35/36 in *_SysCtrl.c zwecks der nötigen Änderung. Das hatte ich beim letzten Mal vergessen/übersehen - sorry! Im cmd-File gibt es eine Sektion secureRamFuncs, die zwar im Flash gespeichert ist, aber gleich am Anfang der main ins RAM kopiert und von dort ausgeführt wird. Hierbei gilt: loadstart = Startadresse im Flash, loadend = Endadresse im Flash, runstart = Startadresse im RAM (siehe *_flash.cmd und main.c) Der Einfachheit halber kannst du diese Sektion benutzen um die Flash-Initialisierung abzulegen, du kannst aber auch zeitkritischen Code dort hin mappen. Dies kann nötig werden, wenn die Ausführung aus dem Flash zu langsam ist. Anbei nochmal das komplette Projekt.
Das ist ziehmlich nett, daß du dir die Mühe gemacht hast! Da wäre ich allein wahrscheinlich nicht drauf gekommen... Danke! Hier wird leider kein Workshop oder so zu den TI-Teilen oder zu CCS angeboten :( ... Und einfach mal so aus dem Stehgreif einen neuen Controller zu verstehen ist gar nicht sooo einfach, find ich. Sobald ich das Board wieder hier hab werd ich die von dir abgeänderte Variante ausprobieren. Wenn es dich interessiert und du noch nicht völlig entnervt bist (würd mich aber wundern ;) ) kann ich dich gern auf dem Laufenden halten.
>Hier wird leider kein Workshop oder so zu den TI-Teilen oder zu CCS angeboten Frag mal bei TI an, die machen das sicher auch bei euch... ;) >Und einfach mal so aus dem Stehgreif einen neuen Controller zu verstehen >ist gar nicht sooo einfach, find ich. Zumal wenn man aus der AVR-Welt kommt und plötzlich einen 32bit-Typen einer anderen Firma vor sich hat... >Wenn es dich interessiert und du noch nicht völlig entnervt bist (würd mich >aber wundern ;) ) kann ich dich gern auf dem Laufenden halten. Ich hätte mich schon gewehrt - keine Angst. Aber das kannst du gerne tun. Ich bin recht zuversichtlich, da ich es diesmal selbst "am lebenden Objekt" getestet habe... ;)
Hallo nochmal! > Ich hätte mich schon gewehrt - keine Angst. Aber das kannst du gerne > tun. Da bin ich auch wirklich dankbar, glaub mal :) Also ich habe das Projekt von dir mal ausprobiert mit den folgenden "Ergebnissen": wenn es es so übernehmen, wie du des geändert hast läuft das Programm bis in die delay-Funktion, wo es sich dann aber aufhängt. Daraufhin habe ich alles so gelassen, außer, daß ich in der delay das ".sect "secureRamFuncs" " gegen ".sect "ramfuncs" " ersetzt habe. Daraufhin funktionierte das Programm, solange ich es vom PC aus laufen lies. Nach Trennen des Jtag-Teil und Neuanlegen der Versorgungsspannung konnte ich aber kein Toggeln des Test-Pins feststellen. Dann hab ich nochmal die spra958 gewälzt und gesehen, daß da diese "ifndef"-Bedungung, die du eingefügt hast, nicht vorkommt. Wofür die da ist kann ich mir (glaube ich...) denken. Aber da sie weder im Debug- noch im Release-Mode ausgeführt wurde habe ich das "ifndef" mal auskommentiert, so daß sie auf jeden Fall durchlaufen wird. Das hatte aber leider das gleiche Ergebnis. Vom PC aus kann ich das Programm laufen lassen (mit Jtagger dazwichen) aber allein passiert da nichts. Wo ist da bloß der Haken?!
Ich glaub ich habs! Aber zu früh freuen will ich mich mal noch nicht. Ich habe jetzt folgendes gemacht: in der delay-asm hab ich wieder .sect "secureRamFuncs" da stehen. Das "ifndef" ist aber immer noch rauskommentiert. Außerdem hab ich die InitFlash so erweitert, daß sie genauso aussieht, wie in dem spra958-Dokument. Außerdem hab ich Release eingestellt und halt nur die flash-cmd mit eingebunden. So scheint es zu funktionieren. Ich wüßte aber gern WARUM und auch, mit welchen Schwierigkeiten ich zukünftig zu rechnen habe...
Mea culpa: öffne mein zweites Projekt in seiner Originalform, wähle Release und lösche in den Build Options unter Compiler -> Preprocessor -> Pre-Define Symbol "_DEBUG;" (anschließend steht dort nur noch "LARGE_MODEL"). Der Code innerhalb der #ifndef dient dazu Code aus dem Flash ins RAM zu kopieren (um ihn später von dort ausführen zu können). Das ist aber nur nötig wenn das Programm aus dem Flash läuft. Siehe Erklärung oben. Ich hatte Release als Kopie von Debug erstellt und das Symbol "_DEBUG" nicht gelöscht. Dadurch wird der Code nie ausgeführt...
Super, vielen Dank! Ich glaub so kann ich es lassen :) ! Wäre es für dich ok mir evtl. deine eMail-Adresse zukommen zu lassen? Ich würde mich gern nochmal melden, wenn ich wieder vor lauter Bäumen den Wald nicht sehe. Wenn nicht ist das auch ok, man kriegt ja schon genug Spam ;) ... Eins hab ich noch: wo liegt denn jetzt der Unterschied, ob ich auf Debug oder Release stelle? Das macht doch vom Ablauf her jetzt keinen Unterschied mehr, oder? Danke für deine Hilfe und bis demnächst ;) ! VG
>Wäre es für dich ok mir evtl. deine eMail-Adresse zukommen zu lassen? Wenn du hier angemeldet bist: http://www.mikrocontroller.net/user/show/kichi >Eins hab ich noch: wo liegt denn jetzt der Unterschied, ob ich auf Debug >oder Release stelle? Das macht doch vom Ablauf her jetzt keinen >Unterschied mehr, oder? Doch. In einem Fall (Release) wird der Code aus gewissen Sektionen (secureRamFuncs) zuerst ins RAM kopiert und dann von dort ausgeführt. Code aus den anderen Sektionen hingegen läuft aus dem Flash und damit langsamer (dank Waitstates). Im anderen Fall (Debug) läuft alles aus dem RAM. Du kannst auf diese Weise auch ein Programm flashen und wenn du spielen und etwas neues versuchen möchtest, kannst du das mit Debug tun. Das Programm im Flash wird dabei nicht verändert und ist hinterher immer noch lauffähig. Siehe auch: Beitrag "Re: TIs und "DELAY_US()""
Nachtrag:
>Das macht doch vom Ablauf her jetzt keinen Unterschied mehr, oder?
Bei Release wird der Code innerhalb
1 | #ifndef _DEBUG
|
2 | ...
|
3 | #endif
|
ausgeführt und bei Debug nicht. Und die *.cmd-Dateien sind komplett verschieden.
Ok, dann werd ich mir mal einen "offiziellen" Account zulegen :) Danke nochmal und ich würd erstmal sagen: CLOSED ;)
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.