Hallo zusammen
Ich habe eine etwas blöde Frage.
Ich habe auf dem Nucleo Board stm32l476rg ein Interrupt implementiert,
sprich EXTI auf PC12. Das hat auch gut funktioniert.
Jetzt habe ich das Programm 1:1 auf mein Board übertragen und muss
feststellen, dass er im Debugger nicht mehr in den Interrupt springt.
Das funktioniert jetzt irgendwie überhaupt nicht, der Code ist aber der
selbe. Der chip auf dem Board ist STM32L432RCI6.
Kann jemand helfen?
Vielen Dank
buell23 schrieb:> Jetzt habe ich das Programm 1:1 auf mein Board übertragen
Schlecht. Der neue Prozessor hat IMHO nur die Hälfte an RAM - damit ist
der Stack nicht benutzbar, denn der wird Top-of-RAM initialisiert.
Du musst das Projekt neu übersetzen mit den korrekten Einstellung für
den neuen Prozessor. Neben dem RAM könnte sich auch die Interrupt Vektor
Tabelle geändert haben - siehe Startup Files.
Ich denke, das sollte passen.
Ich habe mit CUBEMX den Workordner erstellt und meinen Code Stück für
Stück per copy and paste übertragen.
Den neuen Chip habe ich direkt im CUBEMX angewählt.
Ich weiss jetzt nicht, ob der Trigger wirklich kommt oder nicht.
Beim Nucleo Board habe ich direkt immer 3.3V an den Pin kurz angelegt
und es funktionierte so.
Wenn ich im Debugger den Pin aktiviere, sprich high schalte ist das ja
kein externer Trigger.
Wenn ich doch am Messpunkt ein 3,3V Signal drauf gebe, müsste es doch in
den Interrupt springen.
buell23 schrieb:> Ich denke, das sollte passen.> Ich habe mit CUBEMX den Workordner erstellt und meinen Code Stück für> Stück per copy and paste übertragen.> Den neuen Chip habe ich direkt im CUBEMX angewählt.>> Ich weiss jetzt nicht, ob der Trigger wirklich kommt oder nicht.> Beim Nucleo Board habe ich direkt immer 3.3V an den Pin kurz angelegt> und es funktionierte so.>> Wenn ich im Debugger den Pin aktiviere, sprich high schalte ist das ja> kein externer Trigger.>> Wenn ich doch am Messpunkt ein 3,3V Signal drauf gebe, müsste es doch in> den Interrupt springen.
Ich habe mich auf Mike R. damit bezogen, sorry.
Was meint ihr genau mit den startup files?
>Was meint ihr genau mit den startup files?
Beim Kopieren ist das Hirn ausgeschaltet!
In dem Moment, in dem Du den Prozessor wechselstet, wechselst Du auch -
meist - einige Konstanten. So auch die von der Speichergröße abhängige
initialisierungskonstante. Üblicherweise wird die letzte Speicherstelle,
per default genutzt - für den Stack. Ist der "neue" Speicher jetzt
kleiner, so zeigt dieser Wert ins Nirwana, also hinter den tatsächlich
verfügbaren Speicher. Ist der Neue größer, so verschenkst Du Platz.
Letzteres merkst Du aber nicht.
Übrigens: Mit Hirn meine ich den Compiler, der nicht nur Deinen Sermon
überprüft, sondern, entsprechend dem angegebenen Prozessor, auch
Codeanpassungen vornimmt.
Amateur schrieb:>>Was meint ihr genau mit den startup files?>> Beim Kopieren ist das Hirn ausgeschaltet!>> In dem Moment, in dem Du den Prozessor wechselstet, wechselst Du auch -> meist - einige Konstanten. So auch die von der Speichergröße abhängige> initialisierungskonstante. Üblicherweise wird die letzte Speicherstelle,> per default genutzt - für den Stack. Ist der "neue" Speicher jetzt> kleiner, so zeigt dieser Wert ins Nirwana, also hinter den tatsächlich> verfügbaren Speicher. Ist der Neue größer, so verschenkst Du Platz.> Letzteres merkst Du aber nicht.>> Übrigens: Mit Hirn meine ich den Compiler, der nicht nur Deinen Sermon> überprüft, sondern, entsprechend dem angegebenen Prozessor, auch> Codeanpassungen vornimmt.
Ok, ich verstehe ungefähr worauf du hinaus willst.
Was schlägst du jetzt genau vor was ich tun soll?
Ich habe das Programm schon mehrmals komplett kompiliert.
Schau doch erstmal, ob da elektrisch auch was ankommt. Also Pin auf den
aktiven Pegel legen und im Debugger schauen, ob das Pin-Register das
auch anzeigt.
Gruß, Stefan
Stefan K. schrieb:> Schau doch erstmal, ob da elektrisch auch was ankommt. Also Pin> auf den> aktiven Pegel legen und im Debugger schauen, ob das Pin-Register das> auch anzeigt.>> Gruß, Stefan
Das habe ich jetzt gemacht und an die Messpunkte weitere Kabel
angelötet.
Das Signal kommt an, aber jetzt tut es auch irgendwie, wobei der Autor:
Amateur (Gast) auch irgendwie Recht gehabt hat. Ich hatte zuvor
irgendwie eine axf Dateigrösse von 1000Bytes und eine Programmgrösse von
64bytes.
buell23 schrieb:> Das Signal kommt an, aber jetzt tut es auch irgendwie, wobei der Autor:> Amateur (Gast) auch irgendwie Recht gehabt hat. Ich hatte zuvor> irgendwie eine axf Dateigrösse von 1000Bytes und eine Programmgrösse von> 64bytes.
Das passiert, wenn man im Radio an einem Tag 10x das gleiche Lied von
Nena hören muß:
https://www.youtube.com/watch?v=6W51gDVMjxo
-Feldkurat-
An wie vielen Stellen ein Programm, das für einen anderen Prozessor
geschrieben wurde hängen kann, lässt sich nicht vorhersagen.
Manchmal ist es wirklich nur ein anderer Speicher, schau die einfach mal
die Möglichkeiten einer beliebigen Prozessorlinie an: Andere
Speichergröße, andere Flash-Größe, zusätzliche Anschlüsse usw.
Das kann aber bis zu völlig anderen Befehlscodes, für ein und die selbe
Sache gehen.
Üblicherweise weiß Dein Compiler, durch die Typangabe, was Sache ist. So
hat der Programmierer auch nichts damit zu tun. Aber, was der Compiler
üblicherweise nicht tut bzw. kann, ist überprüfen, ob Deine Angaben auch
stimmen.
Auf diese Weise kann man absichtlich, oder auch aus Versehen, Code für
einen anderen Prozessor generieren.
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