STM32: Default_Interrupt ohne NVIC_EnableIRQ()?

[benpu (Gast)]

Ich habe ein Problem mit meiner Firmware, wo ich versuche den uIP Stack 
zum funktionieren zu bringen. Mir ist es schon gelungen alles so zu 
biegen, dass ich einen Ping beantwortet bekomme. Jedoch leider nur 
einen!

Dass er in den Default_Interrupt-Handler springt hab ich bemerkt als ich 
den Deafult_Interrupt-Handler ersetzt habe und darin noch einen Pin 
hochziehe. Wie ist es möglich, dass er in den Interruot springt, obwohl 
nirgendwo im Quelltext der Interrupt aktiviert wurde und der 
Default_Intterupt-Handler nur angesprungen werden sollte, falls die 
Interrupt-Handler der aktivierten nicht verfügbar sein sollten (.weak)?

Oder gibt es nocht eine weitere Möglichkeit, dass er dort hin springt? 
Ich verwende den STM32F107 mit einer KSZ8021 Phy angebunden über das 
RMII-Interface.

Hat jemand einen Tipp für mich?
Benny

[Jim M. (turboj)]

> Default_Interrupt-Handler

Springt da eventuell der HardFault Handler auch hin?

> [...]  falls die
> Interrupt-Handler der aktivierten nicht verfügbar sein sollten (.weak)

Verwendest Du GCC? Dann eventuell mal die Doku durchlesen, wann Weak 
funtioniert und wann nicht. Das habe ich auch nur zum Teil verstanden...

[Lutz (Gast)]

benpu schrieb:
> Wie ist es möglich, dass er in den Interruot springt, obwohl
> nirgendwo im Quelltext der Interrupt aktiviert wurde und der
> Default_Intterupt-Handler nur angesprungen werden sollte, falls die
> Interrupt-Handler der aktivierten nicht verfügbar sein sollten (.weak)?

Respekt; du hast einen eigenen uIP-Stack geschrieben. Und das auch noch 
ganz ohne Interrupts ...? Der dürfte dann aber noch deutliche 
Performancereserven besitzen.

Versuch doch mal, den Aufrufer der ISR beim Debuggen zu identifizieren. 
Ist nun leider nicht mein Schwerpunkt, aber z.B. Breakpoint auf die ISR 
setzen und den PC auslesen. Nun resetten und bis kurz davor "fahren" und 
sehen, wo es passiert.
Gibt wahrscheinlich aber viel elegantere Methoden.

[benpu (Gast)]

Lutz schrieb:
> benpu schrieb:
>> Wie ist es möglich, dass er in den Interruot springt, obwohl
>> nirgendwo im Quelltext der Interrupt aktiviert wurde und der
>> Default_Intterupt-Handler nur angesprungen werden sollte, falls die
>> Interrupt-Handler der aktivierten nicht verfügbar sein sollten (.weak)?
>
> Respekt; du hast einen eigenen uIP-Stack geschrieben. Und das auch noch
> ganz ohne Interrupts ...? Der dürfte dann aber noch deutliche
> Performancereserven besitzen.
>
> Versuch doch mal, den Aufrufer der ISR beim Debuggen zu identifizieren.
> Ist nun leider nicht mein Schwerpunkt, aber z.B. Breakpoint auf die ISR
> setzen und den PC auslesen. Nun resetten und bis kurz davor "fahren" und
> sehen, wo es passiert.
> Gibt wahrscheinlich aber viel elegantere Methoden.

Ähm nein... ich habe keinen eigenen uIP Stack geschrieben. Ich verwende 
ihn nur. Und ja er funktioniert meines erachtens ohne Interrupts, da sie 
nirgendwo aktiviert werden. Den PC auszulesen halte ich für nicht nötig, 
da er die Adresse des nächsten Befehls enthält und nicht die des 
letzten. Oder ich versteh deine Methode nicht.

Jim Meba schrieb:
>> Default_Interrupt-Handler
>
> Springt da eventuell der HardFault Handler auch hin?
>
>> [...]  falls die
>> Interrupt-Handler der aktivierten nicht verfügbar sein sollten (.weak)
>
> Verwendest Du GCC? Dann eventuell mal die Doku durchlesen, wann Weak
> funtioniert und wann nicht. Das habe ich auch nur zum Teil verstanden...


Ich verwende den GCC von Codesourcery. Der Hardfault-Handler ist meines 
erachtens eine eigene Routine. Weak tritt eigentlich immer in Kraft wenn 
es kein definiertes Symbol dazu gibt. Und so funktioniert es auch.

[Reinhard B. (brainstorm)]

Ich würde mal einen Breakpoint auf den Default Handler setzen und dort 
dann schauen, was im pending register des NVIC steht...