STM32F0Discovery Under Linux Tutorial Part 2 – Using a Minimalist Integrated Development Environment From the Command Line

 In this blog entry we will examine using a development environment based on command line tools which will include using the VIM (VImproved) text editor, the GDBTUI debugger along with the Texane’s stlink  and OpenOCD GDBserver / programmer utilities. It is assumed that the reader has completed Part 1 of the tutorial.

So why use these tools when you have sophisticated tools such as Eclipse ? Command line tools run faster, are usually less buggy than their GUI counterparts and require significantly less memory and processing power. They also allow for a high degree of automation. They can turn your old PC into a development power house!

Using A Command Line Based Code Editor

Vim (or VI improved) is a powerful command line code/text editor that supports syntax highlighting, tabbed windows, horizontal/vertical split windows, advanced copying & pasting functionality, advanced search (and incremental search) functionality to name a few! Vim is a bit unconventional when compared with other text editors. But those patient and brave enough to use it will reap its benefits. A list of Vim tutorials is provided below:

Figure 1. Using VIM as a code editor.

Figure 1. Using VIM as a code editor.

I recently started using Vim and I’m having a blast! I highly recommend it to others. Other popular command line code / text editors include the incredibly powerful GNU Emacs and GNU Nano.

Using GNU GDB in TUI mode (GDBTUI)

The arm toolchain discussed in this and the previous tutorial comes with a GDB client utility. With the GDBServer (stlink’s st-util or OpenOCD) is connected to the microcontroller, the GDB client connects to the GDBServer to access the on chip debug capabilities of the microcontroller. GDB is primarily  text based, but it also has a mode called GDB Text User Interface (GDBTUI) which is a bit more graphical as it shows you the execution path in your source code as well as provides full GDB functionality. With GDB/GDBTUI one can view disassembly code,  set/toggle/disable/enable/delete breakpoints & watchpoints, perform step into and step over, run (continue), halt, watch variables,  set variables & monitor CPU/memory registers. You can even download the binary file from GDB/GDBTUI using the load command.

Figure 2. Using st-util GDBserver (left) and GDBtui (right) to debug project from command line

Figure 2. Using st-util GDBserver (left) and GDBtui (right) to debug project from command line

A list of good tutorials on GDB and GDBTUI are provided below:

Building Two Simple (template) Projects for the STM32F0 Microcontroller

In this section two simple projects for the STM32F0 microcontroller will be built using the toolchain installed in the previous tutorial. The first project “iotogglem0_wspl” is compiled against the STM32F0 standard peripheral library, while the second “iotogglem0” is not. Both programs perform the same function of toggling the two LEDs on the STM32F0Discovery board.

  • Create a “workspace” directory inside the “EmbeddedArm” directory (“mkdir ~/EmbeddedArm/workspace“) and navigate to it (“cd ~/EmbeddedArm/workspace“).
  • Clone the following ready to go project template based on the STM32F0Discovery standard peripheral library  with the following command: “git clone git://github.com/halherta/iotogglem0_wspl.git“.
  • This project expects  the firmware library folder “STM32F0-Discovery_FW_V1.0.0” to exist in  the “~/EmbeddedArm/STM32F0-Discovery_FW_V1.0.0” directory and the project files must exist at “~/EmbeddedArm/workspace/iotogglem0_wspl”. So be mindful of the directory structures involved.
  • Navigate into the “iotogglem0_wspl” and type “make“. This should build the project as shown in Figure 3a. The number under the word “text” is the size of the binary. In our case this is 2568 bytes out of the 65535 available bytes of program memory or 3.9% memory usage.
  • Type “make clean” to clean the build.
Figure 3a Project (with standard peripheral library)Built Successfully!

Figure 3a Project (with standard peripheral library)Built Successfully!

  • Clone the following ready to go self-contained project template NOT based on the STM32F0Discovery standard peripheral library  with the following command:”git clone git://github.com/halherta/iotogglem0.git.
  • Navigate into the “iotogglem0” and type “make“. This should build the project as shown in Figure 3b. The number under the word “text” is the size of the binary. In our case this is 860 bytes out of the 65535 available bytes of program memory or 1.3% memory usage.
    • Notice how not using the standard peripheral library can help us reduce our memory usage significantly!!!!
  • Type “make clean” to clean the build.
Figure 3b. Project (without standard peripheral library) built successfully!

Figure 3b. Project (without standard peripheral library) built successfully!

I highly recommend to those interested in using the ARM GCC toolchain regularly (with or without Eclipse) to invest some time in learning about the GNU Make and GCC tools Some good tutorials include:

Using Texane’s stlink utilities for Programming and Debugging From the Command Line

The Texane stlink utilities consists of two binaries; st-util is the GDB server, used for debugging and st-flash used for programming.

To start a Debug session (See Figure 2),

  • Connect the STM32F0Discovery board to the PC with a mini USB cable.
  • Open a new terminal and type : “st-util“. This should start the GDBserver at port 4242.
  • Open another new terminal window and navigate to the directory of the project that you want to debug; say “iotogglem0_wspl“.
  • In the second terminal type: “arm-none-eabi-gdbtui -eval-command=”target remote localhost:4242″ iotogglem0_wspl.elf “. This will start the debugging session using GDBTUI. At the GDB prompt  type”load” to program the binary onto the micro and initialize the debug session. You can then use the GDB commands to debug your program.
Figure 4. Programming the STM32F0Discovery Board from the command line using st-flash (texane's stlink)

Figure 4. Programming the STM32F0Discovery Board from the command line using st-flash (texane’s stlink)

To flash a binary file onto the microcontroller using the st-flash utility (see Figure 4):

  • Open a new terminal window and navigate to the directory of the project that you want to program; say “iotogglem0_wspl“.
  • Type the following command: “st-flash write iotogglem0_wspl.bin 0×8000000“. This command writes the contents of the binary file iotoggle_wspl.bin to the microcontroller’s program memory starting at address 0×8000000 (the first location of program/flash memory)
  • The st-flash utility can also be used to erase the program memory with the command “st-flash erase“. Unfortunately there’s a bug that prevents this command from working most of the time. Luckily when using the “st-flash write …” command described above, Program / Flash Memory is completely erased properly, then programmed and then verified. So the lack of a functional erase command is not strictly a major problem.
  • The makefiles that come with the two projects are able to automate the programming and debugging processes described above. This ability to automate  via makefiles and in some cases bash scripts, is probably one of the major advantages of using command line tools. In the appropriate project directory, simply type:
    • make flash_stlink” to program a binary file onto the micro.
    • make debug_stlink” to start a debugging session
    • make erase_stlink” to erase the micro’s program memory… As described above, this is currently not working.

Using OpenOCD for Programming and Debugging From the Command Line

OpenOCD is a GDB server utility that can be used for debugging and programming, very much like stlink’s st-util and st-flash. OpenOCD supports a wide range of programming/JTAG adapters(dongles) a wide range of  target CPUs and a wide range of development boards.

To start an OpenOCD debug session:

  • Connect the STM32F0Discovery board to the PC with a mini USB cable.
  • Open a new terminal and type the following command: “openocd -s ~/EmbeddedArm/openocd-bin/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f0x_stlink.cfg -c “init” -c “halt” -c “reset halt”   “. The -s flag establish a search directory for configuration files, The -f flag  includes specific configuration files from within that directory. In our case we are including the stlink-v2.cfg configuration file for the STLINKV/2 interface and the stm32fox_stlink.cfg file for the STM32F0 target. Finally the -c flag passes commands to the GDBserver so basically whenever a connection is made to the GDBserver by a GDB/ GDBTUI client, the chip will be put in reset first.
  • Open another new terminal window and navigate to the directory of the project that you want to debug; say “iotogglem0_wspl“.
  • In the second terminal type: “arm-none-eabi-gdbtui –eval-command=”target remote localhost:3333″ iotogglem0_wspl.elf“. This will start the debugging session using GDBTUI.  You can then use GDB commands to debug your program.

To flash a binary onto the microcontroller with openOCD:

  • Open a new terminal window and navigate to the directory of the project that you want to program; say “iotogglem0_wspl“.
  • Type the following command: incredibly long command: “openocd -s ~/EmbeddedArm/openocd-bin/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f0x_stlink.cfg -c “init” -c “reset halt” -c “sleep 100″ -c “wait_halt 2″ -c “flash write_image erase iotogglem0_wspl.bin 0×08000000″ -c “sleep 100″ -c “verify_image iotogglem0_wspl.bin 0×08000000″ -c “sleep 100″ -c “reset run” -c shutdown“. Again the -c flag is used to pass a sequence of commands that reset the target, erase its memory, flash it with the new binary, verify the memory and then exit.
  • Alternatively we could  navigate to the directory of the project and type: “openocd -s ~/EmbeddedArm/openocd-bin/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f0x_stlink.cfg
  • Then open a new terminal window and telnet to localhost port 4444 (to install telnet, type: “sudo apt-get install telnet“.) with :”telnet localhost 4444“. This will enable you to telnet into the OpenOCD GDBserver and interact with it.
  • In the telnet window (Figure 5) type the following commands to program the microcontroller: “reset halt“, “sleep 100“, “wait_halt 2“, “flash write_image erase iotogglem0_wspl.bin 0×08000000” & “sleep 100″.
Figure 5. Telnetting into the openOCD GDBserver (port 4444) to flash/erase the microcntroller memory

Figure 5. Telnetting into the openOCD GDBserver (port 4444) to flash/erase the microcntroller memory

  • To verify type: “verify_image iotogglem0_wspl.bin 0×08000000”  and “sleep 100”.
  • To have the debugger put the micro in run mode type: “reset run
  • If OpenOCD hangs, try either pressing the “RESET” button on the STM32F0Discovery board and/or remove the JP2 jumper and put it back on again to cycle power to the board.
  • You could probably omit the “wait_halt 2″ command mentioned for programming.
  • Also verifying flash might not be necessary for most cases. If you look at Figure 5 you will see that the number of bytes written in the program step is larger than the the number of bytes verified. This maybe due to the debug information being embedded in the .bin file that does not need to be verified. But I’m really not sure. Either way the new program should run on the chip with no problems.
  • I got the above commands from a script posted on Github by Mike Szczys.
  • Notice that the commands typed into the telnet window are exactly the same commands typed above are into the command line with the -c flags.
  • Finally note how we didn’t have to specify the directory that the .bin file to be programmed was in. This is because we started the GDB server in the project directory. When using OpenOCD  to program, it is very important to START THE OPENOCD SERVER IN THE PROJECT DIRECTORY!!!!
  • Mike Szczys’s stm32f0-discovery-basic-template enables programming and erasing the microcontroller with openOCD using two modules in a script that are callable from the command line/makefile. This is another very elegant solutionTo flash a binary onto the microcontroller with openOCD:

To erase the microcontrollers program memory with openOCD:

  • Open a new terminal
  • Type: ” openocd -s ~/EmbeddedArm/openocd-bin/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f0x_stlink.cfg -    c “init” -c “reset halt” -c “sleep 100″ -c “stm32f1x mass_erase 0″ -c “sleep 100″ -c shutdown “.
  • Again you can telnet into the openOCD GDB server (port 4444) and type in commands shown above ( “reset halt”, “sleep 100″, “stm32f1x mass_erase 0″ & “sleep 100″ ) to erase the chips memory.

The makefiles that come with the two projects are able to automate the programming and debugging processes described above. In the appropriate project directory, simply type:

  • make flash_openocd” to program a binary file onto the micro.
  • make debug_openocd” to start a debugging session
  • make erase_openocd” to erase the micro’s program memory.
This entry was posted in Free STM32F0 Development Environment. Bookmark the permalink.

28 Responses to STM32F0Discovery Under Linux Tutorial Part 2 – Using a Minimalist Integrated Development Environment From the Command Line

  1. ozgur bas says:

    Hi,
    your arm gnu eclipse manual on windows was very helpful.
    Why did you remove windows version setup manual?
    Do you plan to prepare an other part for linux which shows eclipse setups?
    thank you.

    • halherta says:

      Ozgur, the windows version of the tutorial is still up..look here. For the newer linux based tutorials I will not be showing eclipse setups….. as it’s very similar to the eclipse setup in windows. I’m planning to dedicate whatever free time i have to write new tutorials for the STM32F0 peripherals instead.

  2. Rick Kimball says:

    Thanks, I enjoy your articles on these great chips. One question, why the return to the stm32 chips? I thought you had written them off with the intent of focusing on the PIC32 ones?

    BTW: please keep these up, I much prefer articles on ARM chips.

    • halherta says:

      Yeah I’m sort of flip flopping between the two. I think I’ve decided to stick with the STM32F0′s now that they come in packages that I can solder.
      The PIC32s are still great though as are the dsPICs and PIC24s.

  3. poofjunior says:

    Many thanks for setting this up, halherta!

    Alas, it looks like I can’t quite compile the latest version of your code. In your Makefile for iotogglem0_wspl, I’ve changed DEVDIR to
    DEVDIR = $(LIBSDIRS)/CMSIS/Device/ST/STM32F0xx instead of
    DEVDIR = $(LIBSDIRS)/CMSIS/ST/STM32F0xx currently in the repo.

    In the Makefile, I’ve also changed STM32F0-Discovery_FW_V1.0.0 to STM32F0-Discovery_FW_V1.0.1 to reflect the new version.

    Unfortunately, it’s still saying
    “no such file or directory” for stm32f0xx.h, although the include directory (from the output of make all) now includes
    -I../../STM32F0-Discovery_FW_V1.0.1/Libraries/CMSIS/Device/ST/STM32F0xx/Include
    which is where stm32f0xx.h lives.

    I’ve respected the workspace file structure as you’ve mentioned above.
    Any tips? Thanks in advance!

  4. poofjunior says:

    Whoop–my apologies; I forgot to adjust the name of the directory in the Makefile.
    The latest version of ST’s code unzips to a directory called
    STM32F0308-Discovery_FW_V1.0.1
    and I mistakingly overlooked that the directory in this tutorial is called:
    STM32F0-Discovery_FW_V1.0.0

    With this adjustment, and the one’s above, the code should compile as expected.
    Thanks again!

  5. ozgur bas says:

    Hi,
    thank you for your “STM32F0Discovery Under Linux Tutorial”,
    with ubuntu 12.04 64 bit I failed to set up, but
    with ubuntu 12.04 32 bit everything works fine.
    Additionaly I want to use eclipse on linux with your suggested setups.
    I tried settings for your previous win7 eclipse tutorial on ubuntu but
    it gives error like below.

    Please help to set up eclipse to call “arm-none-eabi-gcc” on ubuntu…
    I do not want to use win7 because of eclipse…

    02:38:37 **** Build of configuration Default for project iotogglem0 ****
    make all
    arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m0 -g -gdwarf-2 -mthumb -Wa,-amhls=startup/startup_stm32f0xx.lst startup/startup_stm32f0xx.s -o startup/startup_stm32f0xx.o
    make: arm-none-eabi-gcc: Command not found
    make: *** [startup/startup_stm32f0xx.o] Error 127

    • halherta says:

      ozgur. First make sure that the arm-none-eabi-gcc compiler is exported in the path variable. i.e. add the following to your .bashrc file
      “export PATH=$PATH:$HOME/EmbeddedArm/gcc-arm-none-eabi-4_7-2013q2/bin”. Make sure you download the latest version of Eclipse for C/C++ Development from the Eclipse site and untar it in your home directory. Now always start eclipse from the terminal window and not the menu i.e. type in a terminal window “~/eclipse/eclipse&” (I’m assuming that the eclipse software/binary will be in an eclipse directory when extracted). This is the best way to allow eclipse to identify the the toolchain. To create a new project, create a makefile project and add the example code iotogglem0/iotogglemo_wspl to it from the git repos as per the articles instructions.

      Also on the 64-bit Ubuntu…make sure that you install the 32-bit libraries i.e. sudo apt-get install ia32-libs. This should get things going on a 64-bit Linux OS

      • ozgur bas says:

        Thank you for reply.
        Giving absolute locations to eclipse setup solved path problem.
        Because there is no path problem on linux terminal call, as you suggest correct way seems to be running eclipse from terminal. I will try.
        With consumeing my all weekend, I have win7-32 and ubuntu-32 virtual machines which are compiles and debugs stm32f0,stm32f1 and stm32f3 projects correctly. Thanks to your work!

        But for stm32f4 project, only compilation works fine, debug crashes. open ocd says “segmentation fault” and closes connection, eclipse says “Failed to execute MI command”. (with latest openoocd&eclipse juno)(stm3f4 board tested with stlink utility under win7 with no problem).

        My suspicion; main difference of mcus above mentioned is only the stm32f4 flash is not equaly paged, others have same flash page sizes.

        Dou you have annny experience with stm32f4?
        Dou you have any idea abouth this openoocd problem?

        • ozgurbas says:

          Hi, I found solution for eclipse oocd debug problem with STM32F4 mcu.
          I had conected oocd with terminal command
          telnet localhost 4444
          reset halt
          flash write_image erase …/x.elf
          and close telnet terminal.

          After one time flash write from telnet,
          clipse connects oocd wihout any erros and debug works.

          Is there a missing setup or bug of oocd?

          Error lines were like below.

          =============================
          in eclipse:

          Error in final launch sequence
          Failed to execute MI command:
          -target-select remote localhost:3333

          Error message from debugger back end:
          Remote connection closed
          Remote connection closed
          ============================
          oocd terminal:

          abatross@abatross-virtual-machine:~$ openocd -s ~/EmbeddedArm/openocd-bin/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f4x_stlink.cfg
          Open On-Chip Debugger 0.7.0 (2013-12-29-02:06)
          Licensed under GNU GPL v2
          For bug reports, read
          http://openocd.sourceforge.net/doc/doxygen/bugs.html
          Info : This adapter doesn’t support configurable speed
          Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0×0483 PID 0×3748
          Info : Target voltage: 3.198425
          Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
          Info : accepting ‘gdb’ connection from 3333
          Info : device id = 0×10016413
          Info : flash size = 512kbytes
          Segmentation fault (core dumped)
          abatross@abatross-virtual-machine:~$

          ============================

          • halherta says:

            Ozgur, I could be wrong but I don’t think the problem is in openOCD. I think the problem is in the .bin/.elf file. The fact that openOCD recognizes the device ID (I’m assuming that it identified the correct device ID) implies that openOCD was able to connect to the chip successfully. The problem is very likely related to how the .elf/,bin was created. Again I’d imagine there’s a problem in the makefile and/or linker file(s)

          • ozgur bas says:

            Hi again, the project I had tried was from web, proven stm32f4 template project. The output elf file runs on board correctly. I am guessing eclipse CDT plug in fails to start up oocd debugging. Any idea?

          • halherta says:

            Ozgur, in the makefile is there a ‘-g’ flag present in the CFLAGS variables ? GCC needs this flag to create a binary with debug information embedded in order to debug the binary. Without this flag embedded in the compilation process, the binary cannot be debugged. Just an idea…

            BTW which STM32F4 project template are you using? I’d like to check it out.

  6. ozgurbas says:

    https://github.com/jeremyherbert/stm32-templates
    and
    CFLAGS = -g -O2 -Wall -Tstm32_flash.ld

    I have an other clue,
    previously mentioned work around(telnet startup flashing) does not work if elf file overflows flash page.
    Small IO toggle template was working with the work around.

    I will give up with stlink v2, I will try to use jlink&oocd with slowing down jtag speeds.
    If you have any idea please share.
    Thank you.

  7. Denis Brion says:

    “Other popular command line code / text editors include the incredibly powerful GNU Emacs and GNU Nano.”

    Well, this is somewhat on the side of the topic, bue joe (Joe’s Own Editor http://joe-editor.sourceforge.net/) can offer syntax highlighting for different languages, and is less ressource consuming than Vim -I love it, but sometimes, it is difficult to have the syntax plugins- or Emacs, and slightly more ressource consuming than nano (AFAIK, nano, though a little simpler to use -but one can activate a concise help- , does not have syntax highlighting). That makes it interesting when one uses qemu -eats lots of ressources, vim can be slow therefore- for emulating small GNULinux powered machines http://www.armadeus.com/wiki/index.php?title=User:DenisB.

  8. ozgur bas says:

    Hi,
    with stm32f0 on linux development environment I get error while calling sqrt function.
    If it is solution how to edit make file for -lm switch?

    // /home/ozgurbas/ws/gcc-arm-none-eabi-4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv6-m/libm.a(lib_a-w_sqrt.o): In function `sqrt’:
    // w_sqrt.c:(.text.sqrt+0×96): undefined reference to `__errno’
    // w_sqrt.c:(.text.sqrt+0xa0): undefined reference to `__errno’
    // collect2: error: ld returned 1 exit status
    // make: *** [iotogglem0_wspl.elf] Error 1

  9. Tommy C. Lee says:

    While st-util is listening on Port 4242, the “gdbtui –eval-command=”target remote tclee-Latitude-E6400:4242″ iotogglem0_wspl.elf” execution connects GDBTUI to GDBserver and succeeds in flashing iotogglem0_wspl.elf into STM32F0Discovery board as:
    …..
    2014-04-09T08:45:17 INFO src/stlink-common.c: Flash written and verified! jolly good!

    At he gdb prompt I did “break main” and continue commands. The result is a SIGTRAP message as:

    (gdb) break main
    Breakpoint 1 at 0x80009c8: file src/main.c, line 65.
    (gdb) continue
    Continuing.
    Note: automatically using hardware breakpoints for read-only addresses.

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0×08000981 in Reset_Handler () at startup/startup_stm32f0xx.s:74

    I am seeking the cause of this trap. Please tell me whether this trap occurs normally. I am also trying to figure our how to debug a program in the st-util/gdbtui environment.

    Tommy

  10. Tommy C. Lee says:

    Using the st-util/gdbtui setting, debugging iotogglem0.elf encounters the SIGTRAP message too. I am going to try other STM32F0Discovery programs to see any better.

  11. Tommy C. Lee says:

    The solution to the SIGTRAP problem is the replacement of gdbtui with arm-none-eabi-gdb.

    • halherta says:

      Tommy, are you using eclipse? if yes then gdb is the way to go…..from the command line gdbtui is better because it provides a simple ncurses based user interface. Also, there seems to be no support for gdbtui in the Windows version of the toolchain.

      • Tommy C. Lee says:

        Halherta,

        I am not using eclipse. I am using the stlink utilities (st-util; st-link) and arm-none-eabi-gdb and succeeded in flash and debugging.

        I am now working on the enabling of the st-linkv2 logging capability. On my stm32f0discovery board, the two CN2 jumpers are still ON. I suppose the st-linkv2 connection (COM) is good for logging the printf() messages back to the minicom process running on the /dev/stlinkv2-1 node with 115200 8N1 setting.

        I wonder if I have to remove the two jumpers and go through the SWD connection to gain the flashing, debugging and logging capabilities.

        • halherta says:

          Tommy, I don’t think that texane’s st-link utility supports logging capability or USB-UART printfing…. unless things changed in the last couple of months

  12. Mirco Gysin says:

    Thank you for your super guide!

    Version 4.8 of the gcc-arm-none-eabi does not provide the “gdbtui” command anymore.
    The way to start the tui is “gdb -tui”.

    Regards, Mirco

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>