[STM32F0] Sprung in ISR vor main()

[Cyblord -. (cyblord)]

Hallo Zusammen,

ich habe hier ein kleines Problem mit einem STM32F030K6. Bisher habe ich 
nur auf STMF1 und höher gearbeitet und muss jetzt aber auf einem F0 was 
machen.

Kurz zu dem Setup:

Ich habe die Toolchain ganz analog zu einem F1 aufgesetzt. Nutze 
GNU-ARM, OpenOCD und die StdPeriphLib für den F0 (noch nicht Cube).

Linkerscript und Startupcode habe ich aus dem StdPeriph Package kopiert. 
Das Linkerscript war für einen C8, habe auf Flash- und SRAM Größe des K6 
angepasst.
SWD Zugriff und Debugging usw. funktioniert alles ohne sichtbare 
Probleme.

Das Problem:
Das Programm startet und durchläuft den Startup Code. Kurz nach Aufruf 
der SystemInit springt es in den Infinite Loop für nicht behandelte 
ISRs. Kann bei Durchsteppen dafür keinen Grund sehen.
Laut Debugger ausgelöst durch den Watchdog Interrupt. Watchdog sollte 
eigentlich per OptionBytes deaktiviert sein und sowieso sollte der NVIC 
ja ebenfalls deakiviert sein.
Behandle ich den Watchdog Interrupt, so springt er danach in den 
nächsten (USART) und geht von dort in den Infinite Loop usw.

Kann mir das nicht erklären, weil mein Setup bei den F1 und F2,F4 ohne 
Probleme funktioniert und ich nichts gefunden habe, was da bei den F0 so 
anders sein sollte.

Ich kann heute Abend leider erst den Startupcode und das linker script 
anhängen. Eigentlich müsste der Fehler dort liegen, oder welche 
Möglichkeiten gibt es?

[Jim M. (turboj)]

Mach mal einen Handler für Hard Fault:

void HardFault_Handler(void) {
  while(1) ;
}

Dort landen alle Faults, und man kann dan die entsprechenden Register im 
Debugger auslesen. Checke mal den SP, eventuell hast Du den vergessen 
anzupassen.

Cortex M0 ist auch empfindlich bei Alignment Fehlern, was Cortex M3 und 
M4 nicht so sehr sind.

[Cyblord -. (cyblord)]

Danke für den Tipp, das werde ich auf jeden Fall versuchen.

[Cyblord -. (cyblord)]

Also das Problem scheint gelöst. Es lag am Linkerscript. Ich hatte zwar 
die Flash und Stackgrößen angepasst, aber die _estack Variable nicht. 
Die stand noch auf 8kb Ram, der K6 hat aber nur 4kb.

Danke für den Tipp mit dem SP, das hat mich auf die richtige Spur 
gebracht.

Übrigens: Der HardFault Handler wird angesprungen, und direkt danach 
gins noch mal ins Nirwana.

[./. (Gast)]

> Übrigens: Der HardFault Handler wird angesprungen, und direkt danach
> gins noch mal ins Nirwana.

> while(1) ;

Wie geht das denn bei einem Endlosloop?

[Cyblord -. (cyblord)]

./. schrieb:
>> Übrigens: Der HardFault Handler wird angesprungen, und direkt danach
>> gins noch mal ins Nirwana.
>
>> while(1) ;
>
> Wie geht das denn bei einem Endlosloop?

Gute Frage, aber beim Durchsteppen sieht man genau das.
Erst springt er in den HardFault Handler und beim nächsten Step an 
irgendeine Adresse worauf der Debugger keinen Code mehr an dieser Stelle 
findet.

Habe 4 Screenshots angehangen. Jeder ist entspricht genau 1 Step.

[./. (Gast)]

Danke fuer die Muehe.

Aber sowas muss man dann doch im Assemblertext durchsteppen.

Ich wuerde vermuten das die Vectortabelle nicht in Ordnung ist.
Ist der Stackpointer dort richtig initialisiert?

Siehe den "merkwuerdigen" Sprung nach 0xfffffff9.

"The Cortex-M0 processor does not support unaligned transfers.
Any attempt at unaligned memory access results in a hard fault
exception."

Der Anfang scheint noch richtig zu sein, weil er den Hardfault
ueberhaupt anspringt. Der steht an der 4. Position der Tabelle.

Zum Analysieren von Hardfaults gibt es eine sehr gute Appnote
von TI. Nummer hab ich Moment nicht parat.

Viel Erfolg.

[Cyblord -. (cyblord)]

./. schrieb:
> Danke fuer die Muehe.
>
> Aber sowas muss man dann doch im Assemblertext durchsteppen.
>
> Ich wuerde vermuten das die Vectortabelle nicht in Ordnung ist.
> Ist der Stackpointer dort richtig initialisiert?

Genau. Das Problem ist ja bereits gelöst. Siehe weiter oben.
Der Stackpointer war außerhalb des RAM Initalisiert.

[F. F. (foldi)]

Cyblord -. schrieb:
> Die stand noch auf 8kb Ram, der K6 hat aber nur 4kb.

Weiß jetzt nicht mehr welche AN das war, aber bei ST gibts Dokumente, 
wenn du Programme auf M0 von F3 und F4 portieren willst, was du beachten 
musst.
Beschäftige mich jetzt mit Andreas (igel1) zusammen auch mit dem 
STM32F407 und in dem Zusammenhang habe ich viel gelesen und bin halt 
auch über so ein Dokument gestoßen.

Vielleicht hilft das grundsätzlich weiter.

[Jim M. (turboj)]

Cyblord -. schrieb:
>>> Übrigens: Der HardFault Handler wird angesprungen, und direkt danach
>>> gins noch mal ins Nirwana.
>>
>>> while(1) ;
>>
>> Wie geht das denn bei einem Endlosloop?
>
> Gute Frage, aber beim Durchsteppen sieht man genau das.

Du hast den Optimizer vermutlich aus, und der Compiler macht 
sinnloserweise sowas wie

push LR

am Funktionsanfang. Mit dem kaputten Stack gibt das ein Lockup durch 
Fault im HardFault Handler. Würde man vermutlich nur im Disassembly 
sehen.