Skip to main content
lanchon
Associate III
February 20, 2008
Question

firmware library bugs

  • February 20, 2008
  • 4 replies
  • 816 views
Posted on February 20, 2008 at 03:21

firmware library bugs

    This topic has been closed for replies.

    4 replies

    lanchon
    lanchonAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:24

    Hey ST, why not add a bugtracker for the lib?

    #1 bug?

    http://www.st.com/mcu/forums-cat-6362-23.html

    #2 lib can't be safely compiled at opt levels -O2 -O3 or -Os without disabling some optimization with -fno-strict-aliasing. (http://mail.opensolaris.org/pipermail/tools-gcc/2005-August/000047.html)

    just looked into a header for a minute and saw these, it seems there could be lots of bugs. #1 is quite serious, maybe we shouldn't trust the defines. should I use the lib or just ignore it?

    [ This message was edited by: STOne-32 on 17-02-2008 17:25 ]

    lanchon
    lanchonAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:24

    hi ST,

    thanks for clearing #1 up, it was kinda serious if it was bug, so I'm really relieved.

    #2 yes, CodeSourcery arm-2007q3-53-arm-none-eabi. problems are all over, here's a sample from adc.c:

    Code:

    arm-none-eabi-gcc -Wall -W -Wshadow -Wwrite-strings -Winline -O2 -finline -finline-functions-called-once

    -I . -I lib/inc -mcpu=cortex-m3 -mthumb -c -o lib/src/stm32f10x_adc.o lib/src/stm32f10x_adc.c

    lib/src/stm32f10x_adc.c: In function 'ADC_DeInit':

    lib/src/stm32f10x_adc.c:124: warning: dereferencing type-punned pointer will break strict-aliasing rules

    lib/src/stm32f10x_adc.c: In function 'ADC_SetInjectedOffset':

    lib/src/stm32f10x_adc.c:1034: warning: dereferencing type-punned pointer will break strict-aliasing rules

    lib/src/stm32f10x_adc.c: In function 'ADC_GetInjectedConversionValue':

    lib/src/stm32f10x_adc.c:1056: warning: dereferencing type-punned pointer will break strict-aliasing rules

    levels -O2 -O3 and -Os make assumptions about pointer aliasing that the lib code apparently breaks (or more precisely, the compiler can't verify that it doesn't). this means that certain optimizations are not guaranteed to be safe and must be disabled, or the compiled code may not behave as expected. to reproduce download

    http://www.st.com/mcu/forums-cat-6304-23.html

    , comment line 5 (COMPILE_OPTS += -fno-strict-aliasing) from libstm32.mk and make. see

    http://mail.opensolaris.org/pipermail/tools-gcc/2005-August/000047.html

    for more info.

    I also posted that the IS_GPIO_PIN(PIN) macro was bugged and don't remember what else.

    16-32micros
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:24

    Hi lanchon,

    While answering you, I have made a mistake and I've removed some parts of your message not on purpose. Anyway I will report these minor defines typos to our application group to be taken into account in next enhancement and improvement [Thank You so much :) ].

    To go back to (1#) : This is not a bug and it was a typo on the old UM0306 : you can refer again to my reply :

    http://www.st.com/mcu/forums-cat-6362-23.html

    .

    For Point (2#) : I assume that you are using GNU Complier , right ? is it possible to report the version and the release, is it the codesourcery one ? and I would be very grateful if you provide a screenshot of a concrete example. Thank you in advance, Cheers

    STOne-32 :o

    lanchon
    lanchonAuthor
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:24

    also, remove the definition of the ''bool'' typedef; it's never used and it conflicts with C++ and C99.