arm-gcc Problem mit -Os

[martin (Gast)]

Also zuerst mal zu meinen Setup:
-) STM32F4DISCOVERY(STM42F407VG)
-) CoIDE 1.7.3
-) arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 
4.7.320121207 (release) [ARM/embedded-4_7-branch revision 194305]

Mein Programm sieht im Moment folgendermaßen aus:

#include "stm32f4xx.h"

void TIM1_UP_TIM10_IRQHandler(void) {
    TIM_ClearITPendingBit(TIM1, TIM_IT_Update);
}

int main(void) {
    GPIO_InitTypeDef gpioInit;
    TIM_TimeBaseInitTypeDef timTimeBaseInit;
    NVIC_InitTypeDef nvicInit;

    // PD12, PD13, PD14, PD15 = LEDs
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
    gpioInit.GPIO_Pin   = GPIO_Pin_12 | GPIO_Pin_13 | GPIO_Pin_14 | GPIO_Pin_15;
    gpioInit.GPIO_Mode  = GPIO_Mode_OUT;
    gpioInit.GPIO_OType = GPIO_OType_PP;
    gpioInit.GPIO_PuPd  = GPIO_PuPd_NOPULL;
    gpioInit.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_Init(GPIOD, &gpioInit);

    // PA0 = button input
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);
    gpioInit.GPIO_Pin   = GPIO_Pin_0;
    gpioInit.GPIO_Mode  = GPIO_Mode_IN;
    gpioInit.GPIO_OType = GPIO_OType_PP;
    gpioInit.GPIO_PuPd  = GPIO_PuPd_NOPULL;
    gpioInit.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_Init(GPIOA, &gpioInit);


    // TIM1 setup
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1, ENABLE);
    timTimeBaseInit.TIM_Prescaler           = 0;
    timTimeBaseInit.TIM_CounterMode         = TIM_CounterMode_Up;
    timTimeBaseInit.TIM_Period              = 2532;
    timTimeBaseInit.TIM_ClockDivision       = TIM_CKD_DIV1;
    timTimeBaseInit.TIM_RepetitionCounter   = 0;


    nvicInit.NVIC_IRQChannel                    = TIM1_UP_TIM10_IRQn;
    nvicInit.NVIC_IRQChannelCmd                 = ENABLE;
    nvicInit.NVIC_IRQChannelPreemptionPriority  = 0x0F;
    nvicInit.NVIC_IRQChannelSubPriority         = 0x0F;

    TIM_TimeBaseInit(TIM1, &timTimeBaseInit);
    NVIC_Init(&nvicInit);

    TIM_ITConfig(TIM1, TIM_IT_Update, ENABLE);
    TIM_Cmd(TIM1, ENABLE);


    volatile uint32_t x = SystemCoreClock;

    while(1 > 0) {
        if(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0)) {
            GPIO_SetBits(GPIOD, GPIO_Pin_13);
        } else {
            GPIO_ResetBits(GPIOD, GPIO_Pin_13);
        }
    }


}

Compiliert wird mit:

-mcpu=cortex-m4; -mfpu=fpv4-sp-d16; -mfloat-abi=hard; -mthumb; -Wall; -ffunction-sections; -g; -Os; -DSTM32F407VG; -DSTM32F4XX; -DHSE_VALUE=((uint32_t)8000000); -D__FPU_USED; -DUSE_STDPERIPH_DRIVER; -D__ASSEMBLY__; -I.;

Und gelinkt mit:

-mcpu=cortex-m4; -mthumb; -g; -nostartfiles; -Map=ARMSynth.map; -Os; --gc-sections; -L${linkdir}; -T${linkdir}/arm-gcc-link.ld;

Das Problem ist, dass ich nicht auf SystemCoreClock zugreifen kann, da 
komme ich dann anscheinend in eine Exception die aber im CoIDE Debugger 
keine Informationen liefert.

0x00000000 in ?? ()
tbreak main
Temporary breakpoint 1 at 0x80001f4: file C:\Users\...\Dokumente\Programmieren\ARM\ARMSynth\main.c, line 7.
continue

Dieses Problem tritt aber nur auf wenn ich das Projekt mit -Os baue und 
die Zeile mit TIM_ITConfig() gleichzeitig drinnen habe.

Bin, wie man wahrscheinlich schon gemerkt hat, was ARMs angeht noch 
blutiger Anfänger.


Martin

[Dr. Sommer (Gast)]

martin schrieb:
> Temporary breakpoint 1 at 0x80001f4: file C:\Users\...
> \Dokumente\Programmieren\ARM\ARMSynth\main.c, line 7.
Das sieht eher nach einem Breakpoint als einer Exception aus. "bt", 
"info reg", "x/16xw $sp" im GDB eingeben, Ergebnis zeigen. Disassembly 
zeigen. ISR-Vektor zeigen. ARMSynth.map zeigen.

[martin (Gast)]

Also hier mal der GDB-Output:
http://pastebin.com/9t2Jqdiy

Mapfile:
http://pastebin.com/6tN6Kzfa

ISR-Vector:
http://pastebin.com/BRLvrieQ

Im Debugger wird mir kein Disassembly angezeigt aber ich habe mal im 
Archiv den vom Compiler generierten Assemblercode angehängt.

[Dr. Sommer (Gast)]

Scheinbar doch eine Exception. Allerdings sind pc und sp komplett 
verbockt... Und der Compiler-Generierte Modul-Assemblycode ist nutzlos, 
wenn schon brauch man die Disassembly nach dem Linken; zu erzeugen mit 
"arm-none-eabi-objdump -d -t -C blubb.elf" - damit könnte man 
herausfinden wo nach Auftreten der Exception hingesprungen wurde, und 
warum danach der Programmablauf komplett durcheinander ging - und nach 
Reperatur des Fehlers und erneutem gdb-Debuggen, wo genau das Programm 
abgestürzt ist.

[Karl (Gast)]

ART angeschaltet? Schau mal in die Errata...