STM32F0: Systick will nicht wenn mit gcc unter linux compiliert

Hallo Jim,

also die File-Extension sind alle klein geschrieben.

im dump sieht man

 800003c:  08000249   stmdaeq  r0, {r0, r3, r6, r9}

für den SysTick Vector die Adresse wo dann auch die Routine liegt

08000248 <SysTick_Handler>:

GPIO_InitTypeDef        GPIO_InitStructure;

volatile uint32_t Milliseconds = 0, Seconds = 0;

void SysTick_Handler(void){
 8000248:  b510        push  {r4, lr}
    Milliseconds++; //Increment millisecond variable
 800024a:  4b0c        ldr  r3, [pc, #48]  ; (800027c 
<SysTick_Handler+0x34>)
 800024c:  681b        ldr  r3, [r3, #0]
 800024e:  1c5a        adds  r2, r3, #1
 8000250:  4b0a        ldr  r3, [pc, #40]  ; (800027c 
<SysTick_Handler+0x34>)
 8000252:  601a        str  r2, [r3, #0]
    if(Milliseconds%1000 == 999){ //If 1000 milliseconds have passed, 
increment seconds
 8000254:  4b09        ldr  r3, [pc, #36]  ; (800027c 
<SysTick_Handler+0x34>)
 8000256:  681a        ldr  r2, [r3, #0]
 8000258:  23fa        movs  r3, #250  ; 0xfa
 800025a:  0099        lsls  r1, r3, #2
 800025c:  0010        movs  r0, r2
 800025e:  f000 fa31   bl  80006c4 <__aeabi_uidivmod>
 8000262:  000b        movs  r3, r1
 8000264:  1e1a        subs  r2, r3, #0
 8000266:  4b06        ldr  r3, [pc, #24]  ; (8000280 
<SysTick_Handler+0x38>)
 8000268:  429a        cmp  r2, r3
 800026a:  d104        bne.n  8000276 <SysTick_Handler+0x2e>
        Seconds++;
 800026c:  4b05        ldr  r3, [pc, #20]  ; (8000284 
<SysTick_Handler+0x3c>)
 800026e:  681b        ldr  r3, [r3, #0]
 8000270:  1c5a        adds  r2, r3, #1
 8000272:  4b04        ldr  r3, [pc, #16]  ; (8000284 
<SysTick_Handler+0x3c>)
 8000274:  601a        str  r2, [r3, #0]
    }
}
 8000276:  46c0        nop      ; (mov r8, r8)
 8000278:  bd10        pop  {r4, pc}
 800027a:  46c0        nop      ; (mov r8, r8)
 800027c:  20000014   andcs  r0, r0, r4, lsl r0
 8000280:  000003e7   andeq  r0, r0, r7, ror #7
 8000284:  20000018   andcs  r0, r0, r8, lsl r0

warum dieser Versatz um 1 keine Ahnung, ist aber auch im Coocox dump so

Die Routine SysTick_Handler selbst kann ich auch separat aufrufen, und 
die läuft dann auch so wie gewollt, nur der int macht nichts, es gibt 
auch keine Default-Handler Reaktion, es läuft einfach weiter

LG tux

>warum dieser Versatz um 1 keine Ahnung, ist aber auch im Coocox dump so

Um Thumb-Adressen zu markieren?

tux schrieb:
> Wenn ich das Programm im Anhang unter linux compiliere wird des Systick
> Int nicht ausgelöst.

Versuche doch mal, das Prinzip zu verstehen!
Du brauchst zu allererst einen funktionablen Startupcode, denn dort 
stehen deine Vektoren drin.

Diese Vektoren zeigen auf Handler, welche einen Namen haben und mit 
[WEAK] gekennzeichnet sind.

Dein Handler muss exakt den gleichen Namen wie der Defaulthandler 
haben, damit der Linker das begreift und statt des Defaulthandlers 
deinen Handler in die Vektortafel einträgt.

so. Nun kennen wir nicht die vermutlich unterschiedlichen Startupcodes 
deiner Coocox-IDE und deines Linux-Zeuges, wir wissen auch nicht, was es 
für Unterschiede bei deiner Linkerei geben mag - und du fragst dennoch 
nach ner Lösung.

Das ist zuviel gefragt mangels ausreichenden Inputs.

Also inspiziere mal deinen Startupcode, inspiziere deine 
Link-Zusammenstellung (als Linkerfile oder als .xcl) und inspiziere 
deine Namenswahl für den Handler.

W.S.

Hallo W.S.

wie oben schon geschrieben der Startup-Code ist in beiden Fällen der 
gleiche, da sowohl unter linux als auch in der Coocox Umgebung  die 
gleichen Dateien inkl derer aus den CMSIS_BOOT und CMSIS_CORE 
Verzeichnissen verwendet werden. Das Linkerfile ist auch in beiden 
Fällen das gleiche.
Ebenso der Compiler nur einmal die gcc version für Windows bzw. Linux.

Und wie man dem oberen Dump ja auch entnehmen kann steht der 
Adressvektor für den SysTick Interrupt Handler (SysTick_Handler) ja an 
der richtigen Stelle.

Andere Interrupts sind wie man dem Quellcode entnehmen kann, nicht im 
Spiel und der Default-Handler ist die Standard Endlosschleife.

Das das Programm sich aber nicht aufhängt, sondern gemäß der 
Warteschleife endlos auf PA1 toggelt, wird wohl der Interrupt selbst in 
der Linux Variante nicht ausgelöst.

LG tux

tux schrieb:
> wie oben schon geschrieben

Also, mal ganz trocken formuliert: Wenn alles wirklich das Gleiche 
ist, dann ist Magie im spiel. Glaub ich aber nicht, also ist irgendwas 
eben NICHT gleich.

btw: warum linkst du dein Zeugs auf $0800'0000 ? Linke das ganze mal auf 
0 und probiere es noch einmal.

W.S.

Hallo W.S.

das Linker-script (ram-gcc.ld) wurde vom Coocox erzeugt.

Bei 0x08000000 ist immer der Flash des STM32F050  unabhängig von der 
Bootkonfiguration zu finden.

Klar kann man auch bei boot0=0 gegen 0x0 linken, da der Flash dann 
zweimal im Speicherbereich auftaucht (0x0 und 0x08000000).  Was soll das 
aber ändern ?
Beide Compilierungen (Win und Lnx) greifen auf die Dateien aus dem 
gleichen Verzeichnis zu (Server"laufwerk")

Ne Magie ist da sicherlich nicht bei.

Vermute das Problem bei der Compilierung der Initialisierung via 
SysTick_Config, da wie gesagt er nicht in einer Endlosschleife 
verschwindet (falsche Vektorposition bzw Vektoradress) und die 
SysTick_Handler bei direktem Aufruf wie gewünscht funktioniert

LG tux

Hi,

Ursache gefunden.

das st_flash util unter linux muss extra darum gebeten werden(option 
--reset), das es nach dem Beschreiben des Flash auch ein Reset für den 
µC auslöst.
Dann geht es auch mit dem Linux Compilat.

Das Coocox ST-Link Interface macht das automatisch.

LG tux