Interrupt funktioniert nicht

[buell23 (Gast)]

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

[Mike R. (thesealion)]

Hast du auch die StartUp Files angepasst?

[Jim M. (turboj)]

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.

[Stefan K. (stefan64)]

Siehst Du den Pin Change im Debugger (EmbSys Registers)?


Viele Grüße, Stefan

[buell23 (Gast)]

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 (Gast)]

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?

[Amateur (Gast)]

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

[buell23 (Gast)]

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.

[Stefan K. (stefan64)]

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

[buell23 (Gast)]

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.

[Feldkurat K. (feldkurat)]

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-

[Sebastian S. (amateur)]

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.