Skip to main content
lanchon
Associate III
November 25, 2009
Question

STM32 C/C++ build environment using CodeSourcery Sourcery G++

  • November 25, 2009
  • 26 replies
  • 5222 views
Posted on November 25, 2009 at 04:13

STM32 C/C++ build environment using CodeSourcery Sourcery G++

#fyi
    This topic has been closed for replies.

    26 replies

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

    added basic Eclipse support (no debugging).

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

    yessssssssss!!!! C++, at last!

    Code:

    CodeSourcery/STM32 (by Lanchon, 25-Feb-2008)

    This is a C/C++ build environment for the STM32 using CodeSourcery Sourcery G++

    (arm-none-eabi). It has been tested with:

    Sourcery G++ Lite 2007q3-53

    Sourcery G++ 4.2-84

    The JTAG flash programming support requires OpenOCD r320 (23-Feb-2008) or later

    (openocd.berlios.de, or www.yagarto.de for a win32 port). The GCC version of the

    STM32F10x Firmware Library 1.0 (08-Oct-2007) is included with minor documented

    changes.

    Linker scripts, startup and exception support files were made by me. They were

    based on a detailed analysis of how Sourcery G++ handles other targets, and they

    are fully compatible with CodeSourcery's CS3 framework.

    A demo project that flashes a led connected to PC12 is included. It is ready to

    run on an Olimex STM32-H103 board (http://www.olimex.com/dev/stm32-h103.html).

    The OpenOCD configuration files are ready to flash via an Olimex ARM-USB-TINY

    JTAG dongle (http://www.olimex.com/dev/arm-usb-tiny.html).

    To build the demo, change to the project directory and use the make tool that

    came with Sourcery G++:

    cs-make to build the firmware library and the demo

    cs-make -B to force a complete rebuild

    cs-make clean to delete all previously built files

    cs-make flash to flash an STM32 after building using OpenOCD

    Some files are copyright CodeSourcery and are licensed under a very permissive

    license (see the initial comments in each file). The rest were written by me,

    and I place them all in the public domain.

    Lanchon

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

    hi,

    1) CS G++ supports code generation for the Cortex-M3 core (a product of ARM). they don't provide linker scripts supporting the STM32. they don't provide startup code either, and the code I've seen elsewhere didn't support C++. they do provide the common part of the implementation of an initialization strategy called CS3 onto which one can plug in.

    2) sources for (parts of) CS3 come with the non-lite version of CS G++, which you can evaluate for free for a month if our register on their site. (this version also comes with linker scripts and initialization code for various micros, but not the STM32.) these files are ''conveniently'' missing on the free version, but the files on the commercial version are provided under a permissive license, so I could include the relevant ones with my download. the startup code that comes with fwlib isn't used, it doesn't support C++ (or CS3). the startup files for the STM32 were made by me after looking at other startup files by CS. the comment at the beginning of each file tells you whether it's CS's work or mine, or a mixture of both.

    the source for a specific stage of CS3 is missing because it isn't included in commercial G++, but you can objdump it to take a look. (but you probably aren't licensed to reproduce the output, and I don't know if you are even allowed to objdump it in the first place.)

    mc1
    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 12:25

    Dear Rodrigo,

    You did incredible job ! I still do not have evaluation board, but I have successfully compiled your example and now I am waiting for the evaluation board. I did not have to deal with GNU Linkek configuration files before, so all this is really new to me.

    I would be really gratful if you find some time to answer my questions ?

    1) What is wrong with Code Sourcer w.r.t. STM32. Is it supported or not? They say they support Cortex M3 so I am not sure why is it necessary to do something more ? Esspecially, I do not understand how it was possible that their linker files did not handle static constructors initialization correctly so that you had to change anything ?

    2) I am wondering how did you find the sources of the libcs3 ( the boot code that comes with the stm32 fwlib) ? Did you get it somehow from Code Sourcer or you made them all yourself ? I could not find it.

    Thanks for help,

    Marcin

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

    hi Marcin,

    if you run into trouble you should post in this forum or contact ST support. you might be under the wrong impression: I'm not affiliated with ST and I don't provide support.

    (PS. I'm lanchon, not Rodrigo.)

    mc1
    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 12:25

    Rodrigo,

    Thanks for your answers (I have been away that's why I haven't answer anything). It clarifies a lot for me. I will be playing with GCC, STM32, and Olimex in the next month (I will start right after Easter :)). I am wondering if it is possible to have your e-mail in case of real troubles ? (my Skype is mczenko2). In any case, one more time, thanks for your work and help !

    Marcin

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

    I forgot to write a comment about this on the makefile. in the makefile you'll find these lines:

    LD = $(CC)

    #LD = $(CXX)

    you should change them like this if you're compiling c++:

    #LD = $(CC)

    LD = $(CXX)

    this makes the c++ support libs available to the linker.

    also, a sad note: iostreams are not usable, the compiled size is too big. there's no intrinsic reason for them to be, the library implementation simply lacks quality in this regard.

    and a tip: you can redirect the stdout like this:

    extern ''C'' int _write(int, char*, int);

    int _write(int file, char* ptr, int len)

    {

    display.print(ptr, ptr + len);

    return len; // or -1

    }

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

    hi Miles,

    I normally don't get my hands dirty with these things, I write mostly portable code and leave the details of toolchains to others. I had zero experience with GCC and with setting up a compiler so this was kind of a drag. Also, I never use debuggers (I instrument code instead) so I can't help you in the least bit with GDB.

    There's Anglia IDEaliST that I think can do debugging via OpenOCD, you could try that IDE. In my release I included a file called jtag/target.ini that was taken from IDEaliST 1.61. Apparently it's some kind of configuration file for GDB, but I wouldn't know. I included it in hopes that someone might find it useful...

    mc1
    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 12:25

    OK. No problem.

    PS/

    I did not assume that you are affiliated with ST.

    PS/

    Sorry for using your real name.

    (I took from one of your post:

    http://www.st.com/mcu/forums-cat-5951-23.html&start=10

    )

    miles
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 12:25

    Thanks very much for putting this together. I tried it out along with the codesourcery toolchain, and a few different versions of OpenOCD. In each case I was able to build, flash, and execute the application using OpenOCD, but I was not able to debug. GDB (the one included in the codesourcery toolchain) could connect with a ''target remote localhost:3333'', which would stop the app from running. Entering 'continue' would make it continue, but gdb became unresponsive, and did not return a '(gdb)' prompt after the continue command. This is all on winXP pro, and the versions of OpenOCD I tried were:

    1) built from source

    2) included with CodeSourcery's eval pro IDE

    3) YAGARTO's OpenOCD installer

    If anyone could tell what's wrong (or what to try next), I would appreciate it.

    Thanks,

    Miles