Developing with STM32 introducing ChibiStudio

Developing on STM32: introducing ChibiStudio

Introduction

In this article, we are going to set-up a ready-to-use Eclipse-based toolchain named ChibiStudio for the development on STM32. We will also explore this development toolchain explaining some basic operations necessary for daily development. So we will introduce the ChibiOS project, we will setup ChibiStudio taking a tour of some parts of it, we will import some ready to use projects and perform our first flash and run. Note that to proceed with this tutorial is necessary the installation of ST-Link drivers: this procedure has been shown in the previous article From 0 to STM32.

Notes about programming language

We never talked about programming language deliberately until now. Actually, programming is a matter of mindset and logic. The language is just a way to put into effect a well-defined idea. Of course, there are certain languages which are more suitable for a purpose. The embedded programming is extremely close to the hardware and most effective programming languages for this purpose seems to be the C and the Assembly. In some cases, some libraries are written in C++ and more rarely in Java, PHP or Javascript.

We are going to use C.

The ChibiOS project

We said that ChibiOS is an Embedded Library but this is the most simplistic and general way to qualify it. To be more specific, ChibiOS stands for Small Operating System (Chibi is a Japanese word which means small) nonetheless it has evolved over the year to become something more than a Real-Time OS (or RTOS).

History in brief

Inception

ChibiOS (formerly ChibiOS/RT) is a project born in the 80s and published on Sourceforge in 2007 by my mentor and friend Giovanni Di Sirio. In the beginning, the project was named ChibiOS/RT because it was basically an RTOS. After some months of development, the project starts to include a set of device drivers for testing purposes.

Growing up, the device drivers branch became self-consistent. It was split from RT and named as Hardware Abstraction Layer aka ChibiOS/HAL. Prior to the version 3.0.0, the HAL and the RT were joint together and interdependent. Starting from 3.0.0, the two parts have been separated and interconnected through an Operating System Abstraction Layer (also known as OSAL) in this way HAL became able to run independently from the underlying Operating System.

Nowadays

The ChibiOS project has now a portfolio of four software products which could be used separately or joint-together. It now counts two different kernels: the first is RT aka ChibiOS/RT; the second could be considered a subset of RT designed to be the smallest RTOS ever and is know as NIL or ChibiOS/NIL.

Starting from the latest version, ChibiOS include also a new set of complex drivers: its name is ChibiOS/EX and stands for external peripherals. We will properly describe all these products as we start to use them. In these tutorials, we are going to use some demos based on ChibiOS/RT + ChibiOS/HAL.

Here a collection of useful links related to ChibiOS. We will deepen them later but right now is good to have all the quick references grouped in the same place:

  • The ChibiOS project has an Official Website (chibios.org) and a support forum (forum.chibios.org): I suggest you explore the website because it provides interesting technical information, documentation, and news. Another good idea is to subscribe to the forum and get in touch with the community: it could be an irreplaceable source of knowledge.
  • This project has an Official Facebook page: the suggestion here is to like and to follow it to receive news about releases or events related to the project.
  • The code comes with detailed documentation (there is a document for each sub-project): this is very useful while developing. Anyway, the documentation is auto-generated from code using a tool named Doxygen: exploring the code, you will be able to find all the information needed. We will deepen this point later during hands-on.
  • The project is distributed through OSDN. On the project page, you will find a link to the SVN repository and a directory with all the downloadable files.

Concluding, PLAY Embedded has a lot of resources to learn to work with ChibiOS. We often offer support to people who comment on our articles or subscribes our forum (forum.playembedded.org).

Version number

When you ask for help the most important think is to give a precise information about the version of ChibiOS you are using.

The project is released as package versioned using the method yy.m.p “codename” where:

  • yy indicates the release year (less significant two digits) and changes only on major releases;
  • m indicates the release month number and changes only on major releases as well as year;
  • p indicates the patch, a number incremented in case of small bug fixes on minor releases;
  • codename is an identifier for the current patch.

Each product (for example RT or HAL) has its own version number according to the method M.m.p where:

  • p indicates the patch, a number incremented in case of small bug fixes;
  • m indicates the minor, a number incremented in case of small changes or even addition of features which in any case do not impact on APIs;
  • M indicates the major, a number incremented in case APIs change or addition of big features which requires a change of the design.

At the time of writing the latest ChibiOS package was also indicated as ChibiOS 17.6.2 “Allegro” while ChibiOS/RT was 4.0.0, ChibiOS/HAL 5.0.0 and ChibiOS/NIL 2.0.0. ChibiOS EX instead is a collection of drivers individually versioned. Now I am reviewing this article ChibiOS package is marked as  ChibiOS 20.3.2 “Praiano” but concept explained in the articles here presented are still valid.

Summarising:

Each ChibiOS sub-project has its own version number identified by three numbers M.m.p. The whole package is versioned with a three number plus one word system yy.m.p “codename”.

There is full compatibility between two different patch numbers. For example, the code that runs on ChibiOS 17.6 “Adagio” runs also on ChibiOS 17.6 “Allegro” but maybe does not compiles on ChibiOS 19.1 “Minori”. Note that usually, it is quite easy to port your application from an older version of ChibiOS to another but the complexity depends on the dimension and the design of your code.

How to use it

Basically ChibiOS is a software library: it is a folder containing source code and other plain text files. There is no way to use ChibiOS itself without a toolchain!

Dealing with programming, more so with embedded programming, you will often hear about “toolchains”.

A toolchain is a set of distinct software development tools linked (chained) together. When you develop code for embedded systems you are compiling code which will run on a machine different from your Computer. 

So, we need

  1. specific embedded libraries able to address our MCU
  2. a compiler able to generate code which will run most likely on a different architecture: this is known as a cross-compiler,
  3. a flasher to flash the binary into the STM32,
  4. in a decent development system, a debugger to test code at run-time.

All those things are provided all together in ChibiStudio, a ready to use toolchain named ChibiStudio which we are now going to install. The following figure schematise the toolchain:

Development system diagram
A diagram of the development system composed by ChibiStudio + an STM32 based development board

On the PC side, we have the toolchain which contains the ChibiOS Embedded Software + the user application. It is compiled through the ARM GCC Cross Compiler generating a firmware.

On the Development kit side, we have the STM32 connected through the JTAG to the ST-Link debugger.

The two sides are interconnected by the debugger which is composed of a hardware layer (STLink + Cable) plus a software layer (OpenOCD and GDB Server). Using this interconnection is possible to flash the firmware on the STM32, to execute the code step by step or to explore the MCU memories and CPU registers.

Setup of ChibiStudio

The setup of ChibiStudio for Windows is pretty straight forward.

  1. Get the last ChibiStudio from the Official page of ChibiStudio
  2. Extract the files under C:\ using 7zip
  3. Copy the link “Chibi Studio GCC x.x” on the desktop and use it to launch the toolchain.

Disclaimer: The following video has been recorded when the latest version of ChibiStudio was ChibiStudio Preview 21. It is still a good reference but there will be some differences from your setup. If you have any issue performing this procedure please refer to this How-to.

Exploring ChibiStudio

Some necessary concepts

Startup with ChibiStudio could be thorny, especially if you are new to Eclipse. We are going to introduce some general concept related to Eclipse pointing out which are the ChibiStudio specific customization: this would improve your experience. Feel free to jump to paragraph 4.2 if you are already experienced with ChibiStudio.

Eclipse

First of all, Eclipse is an Integrated Development Environment (often abbreviated IDE). An IDE is a tool which aims to simplify the development process with visual aids like code highlighting, autocomplete content assist, advanced code browsing, debugging windows and so on.

Eclipse is completely open source and is widely used but not strictly necessary: it is possible also to write code in a text editor and compile it using a shell if you prefer. Anyway, a well configured IDE is always a good help to develop code quickly, especially if you are not used to shell and scripting languages.

Workbench and workspace

Eclipse is organized in Workbenches: a workbench is practically the Eclipse main window. It is the bench where you can organize your programming instruments, hence the different views and editors. Views and editors are your instruments to manipulate sources and data. and you can arrange them at hand for specific tasks (exploring, debugging, coding, etc.).

All the configurations related to Workbench (settings, IDE related variables, perspectives, history, imported projects, etc.) are saved as metadata in a specific location which is named Workspace. The workspace folder is also the default location where new projects are saved.

ChibiStudio comes with more than a release of ChibiOS for a matter of back compatibility. For example, ChibiStudio Preview 21 comes with three different versions of ChibiOS:

  • ChibiOS 20.3.1 (located at C:\ChibiStudio\chibios203), which was the latest stable version of ChibiOS when ChibiStudio has been released.
  • ChibiOS 19.1.2 (located at C:\ChibiStudio\chibios191), which is the previous version of ChibiOS with the latest patch available when the toolchain has been released.
  • ChibiOS Trunk (located at C:\ChibiStudio\chibios_trunk). The Trunk represents the development version of ChibiOS which by definition is not stable updated at the latest revision number available when ChibiStudio has been released.

The presence of the oldest version of ChibiOS would be a kind of bridge between the old version and the new one: having the previous and the latest version of ChibiOS in the same toolchain could be the chance to port projects from the previous ChibiOS release to the latest one using the same toolchain. The trunk instead could be used to test new features and is also used from us to continue the development. Note that is possible to work on trunk updating it to the latest revision following this article (we are not going to use trunk right now so you don’t need to do this now).

For each version of ChibiOS integrated into ChibiStudio, there is a related Workspace. So, in ChibiStudio Preview 20, there are three different workspaces:

  • Workspace 203 (located at C:\ChibiStudio\workspace203), which is configured with all the available demos for ChibiOS 191 already pre-imported;
  • Workspace 191 (located at C:\ChibiStudio\workspace191), which is configured with all the available demos for ChibiOS 182 already pre-imported;
  • Workspace Trunk (located at C:\ChibiStudio\workspace_trunk), which could be to try trunk new features.

Additionally, there is another workspace:

  • Workspace User (located at C:\ChibiStudio\workspace_user, which is an empty workspace dedicated to the user.

In Eclipse, Workspace and workbench are different terms for different concepts: The workbench is the Eclipse main window, The workspace is a directory that holds information about workbench like the projects you work on, as well as the Eclipse preferences (from layout to behavior). For more information you could refer to Eclipse documentation.

It is possible to switch workspace in use through the menu File->Switch Workspace and choosing a workspace from the history or selecting “Other…” to browse a new workspace like is shown in the next figure.

Switching workspace
The switch workspace menu

Taking a look at this menu you can also figure out which is the workspace in use because it would not be in the list. Refers to the previous figure, we are currently using Workspace User which is not in the history list.

Choosing another Workspace Eclipse will restart loading a new Workbench.

Perspectives

The organization of your Workbench could be saved to be quickly recalled at the proper moment: these preset take the name of perspectives.

ChibiStudio perspectives
ChibiStudio perspectives

Perspectives could be switched using the proper button in the top right corner of your Workbench. It is also possible to add other perspectives, save or reset the current one to default through the drop-down menu “Window” located in the menu bar.

Note that switching perspective is a matter of views organization, this will not impact your code or your files. You can switch perspective as you want without any concern.

ChibiStudio comes with two separate perspectives: C/C++ and Debug. If the on first run your do not have C/C++ and Debug perspectives on the top right corner most likely you haven’t uninstalled the antivirus or you haven’t updated 7zip: the extraction has been affected by this.

ChibiStudio perspectives
A close look to ChibiStudio perspectives. On the left the C/C++ perspective, on the right the Debug perspective.

The two perspectives reflect the way which is split the code development process. Code editing is only a phase of the whole development process: having a compiling code it does not mean it is working as expected. We are talking about functional behavior here. So, the whole development process could be split into two specific parts that are two specific moments of the development process:

  1. The software development, in other words, that process related to new project creation, code editing, compiling and resolution of errors and warnings. The perspective C/C++ is oriented to this part and you can figure out this because the largest amount of workbench area is dedicated to the text editor area.
  2. The debugging, in other words, that moment related to testing the functionality of our code, detection of unexpected behavior or evaluation of software performances and consistency. The perspective Debug is oriented to this phase and it offers a lot of additional windows to explore code, memory, and variables or to evaluate an expression, connect terminal and so on.

First launch

The Project Explorer in ChibiStudio 20 and higher versions

At first launch, ChibiStudio usually shows a welcome window: just close it. You should be now in the C/C++ perspective. The editor window is the largest windows in the middle of the workbench and should be empty. On the right, there is the Project Explorer which usually contains all the imported projects.

If you have downloaded ChibiStudio Preview 20 or higher, you will start in the User Workspace and the project explore should contain only two dummy projects representing the documentation and the tools of our toolchain as shown in Fig. 5.

Projects folders
Some ChibiOS projects

The best way to proceed at this point is to import a ready to use the demo. The demos we need to import are under the folder C:\ChibiStudio\chibios203\demos\STM32. This is true because we are going to use ChibiOS 203 but there are similar folders also under ChibiOS 191 and ChibiOS Trunk directories.

In the demos\STM32 directory, there are a lot of folders each of which represents a standalone project. Each project is named following the same pattern KERNEL-MCU-BOARD. For example, RT-STM32F207ZG-NUCLEO144 is a demo based on ChibiOS/RT for STM32 Nucleo F207ZG, a Nucleo-144  equipped with STM32F207ZG and it works on this specific development kit.

Importing an existing project

The next step is to import a demo for the development board you are going to use. Almost every official STM32 Discovery and STM32 Nucleo boards are supported. Since I will use both STM32 Nucleo F401RE and STM32F3 Discovery kit, I will import both RT-STM32F401RE-NUCLEO64 and RT-STM32F303-DISCOVERY.

The steps required to import an existing demo are:

  1. Select File->Import from the menu;
  2. In the newly prompted window select Existing project into workspace and press Next;
  3. Select Root directory: “C:\ChibiStudio\chibios182\demos\STM32″;
  4. Check all the project you want to import and press Finish.

The following video has been done with ChibiStudio Preview 19. If you are using ChibiStudio Preview 20 things are almost the same. The difference is that the latest version of ChibiOS is 182 thus we have to select a different demo root (“C:\ChibiStudio\chibios182\demos\STM32” instead of “C:\ChibiStudio\chibios182\demos\STM32”).

This argumentation will be more valid when a newer version of ChibiStudio will be available. It is always a good idea to use demos from the latest stable version of ChibiOS and many users are even working with Trunk. Note also that in the following video we are importing a demo named RT-STM32F303-DISCOVERY-REVC which in ChibiOS182 have been merged with RT-STM32F303-DISCOVERY (thus in case you are using F3 Discovery import this one).

Handle imported projects

At this point, the Project Explorer should contain one or more additional projects according to how many projects you have imported.

In Eclipse, a project is a blue folder containing files, links, and subfolders and it actually is mirrored to a real folder. As example, the project RT-STM32F401RE-NUCLEO64 is mirrored to the directory “[chibios folder]\demos\STM32\RT-STM32F401RE-NUCLEO64\”. To be able to explore a project in Eclipse it should be open. You can open a project right clicking on it and selecting Open Project.

In Eclipse a project could be open or closed right clicking on it and choosing the proper entry from the menu. A project shows its resources only when is open. To avoid confusion, it is a good idea to work keeping all the projects closed except the one you are working with. It is possible to close all the project except one right clicking on the one you want keep open and choosing Close Unrelated Projects.

Build and clean

Build folder
the build folder: the result of a successfully make in ChibiStudio

The projects we are going to use are based on makefile: the makefile is a script file which contains a series of directives used by make to build our code. All the projects in ChibiOS come with a complete and a ready-to-use makefile.

It could happen that the makefile has to be edited to customize the build process or include new sources and we will face this problem if necessary. Right now we do not have to edit the makefile. Anyway, is interesting to know that if build procedure ends successfully the makefile is designed to create a subfolder named build under the project main folder.

As shown in the figure, the build folder contains the compiled firmware as binary (ch.bin) and as hexadecimal (ch.hex) but also the Executable and Linkable Format file (ch.elf). The ELF contains the executable but also information about how the code is organized in memory and the list of all symbols: this file is required by debugging activities.

To build a project right click on it and select Build Project. Another way is to click on it and press the hammer button in the tool bar. If the procedure ends successfully a new folder into the project will appear: it is named build and contains the output of make process as bin, hex, elf and other formats.

Note that a project could be also cleaned, the clean procedure removes the build. If we do not clean a project, in case of small edits, next build time will be shorter. This because the build folder which contains also some object files.

The object files are a kind of partial output of the making process. These files are not rebuilt if Eclipse “thinks” that related sources have not been modified. This reduces the built time in case of small edits.

Rarely could happen that this mechanism fails: in this case, there could be some misalignment between code and binary. In such a particular condition, a clean and rebuild will solve any issue. A good idea is to clean and rebuild the project when we do major edits to our code, especially when dealing with makefile or pre-processor directives.

There could be mutiple causes of failure during build of default demos and most common are: your antivirus, an error occured during extraction of ChibiStudio or a misplacement of ChibiStudio main folder.

Flash and run

An important part of software development is the flash and run. This procedure copies the binary into the microcontroller flash memory and starts its execution. The flash and run is automatized in ChibiStudio and involves OpenOCD on the PC side and ST-Link on the Development board side as shown in Fig.1.

OpenOCD is an open source GDB server which offers a programming interface to a hardware debugger. The debugger allows common operations like write/erase flash memories, write/clear RAM memories, set register values, set breakpoints or watchpoints, set program counter, execute the code step by step and so on. From our point of view we can say that:

The debugger is composed by an hardware part (in this case ST-Link Embed Debugger) and a software part (in this case OpenOCD). The debugger could be considered like a bridge between our IDE and the MCU. To perform any debugging operation the first step is to “create this bridge”

Launch tools
ChibiStudio launch tools

There are two buttons which we will use to execute the flash and run: these two buttons are shown in the figure and are the External Tools Menu (Orange) and the Debug Menu (Azure). Actually, we should not press on the button but on the small black arrow beside them: this will open a drop-down menu.

Starting from ChibiStudio 2020-04 you need to do an extra step to do the flash and run: generate the Debug Launch configuration.

To do so:

  1. Build your target
  2. in your project, under the folder build, select your elf file
  3. From the External Tools Menu (Orange), choose “Create OpenOCD Debug Configuration (pre-select elf file into a project)” from the external tool menu
Generating a Debug configuration
Generation successful

When the generation is completed you’ll see a message in the console.

Once the generation is done you can launch proceed with the flash and run. To do so we need to select again the External Tools Menu (Orange) and choose another launch configuration. When using the ST-Link as the interface you should pick up the script: “OpenOCD on ST-Link (prompts for .cfg target configuration)“. Note that, many OpenOCD configurations specify the interface internally and thus the script “OpenOCD no interface (prompts for .cfg target configuration)” will work as well.

If the external tool menu is empty, check that you have imported and opened the project ChibiStudio Tools: this project contains the launch configurations of all the external tools including OpenOCD.

The OpenOCD log
How the console window looks when OpenOCD starts correctly.

After selecting a voice from that menu, a window will prompt: in here, we have to pick-up a configuration script for OpenOCD which indicates which board we are going to target. All the scripts are contained under the folder C:\ChibiStudio\tools\openocd\scripts\board and usually there is a script related to each STM32 development kit.

By choosing the configuration, OpenOCD attempts to start-up and, if this operation goes successful we will see the target information in the Console window, like the MCU voltage, the number of breakpoints and watchpoints as shown in Fig.9.

From the Debug Menu (Azure in fig. 8), we can now launch the flash and run procedure selecting the proper Launch Configuration. Each project has its own Launch Configuration. It is easy to associate the configuration to the related project because they have the same name.

Once we have selected it, Eclipse will build the project (if this has not been already done) and will start the procedure switching automatically to Debug: in this perspective, we can press the Resume button to run the code execution as shown in Fig.10.

Debug windows + Resume
The resume button in ChibiStudio. In the debug window is possible to see that OpenOCD is running.

Summarising:

  1. Generate the launch configuration selecting the elf in the build folder and choosing Create OpenOCD Debug Configuration from the External Tool Menu (not shown in the video)
  2. Launch OpenOCD from the External Tool Menu choosing the proper interface (ST-Link in this case);
  3. In the newly open window, select the proper configuration script related to the board in use;
  4. Check that OpenOCD has been started properly looking to the console windows: there should be information about the MCU voltage, the number of breakpoints and watchpoints.
  5. From the Debug Menu, launch the flash and run selecting the proper Launch Configuration;
  6. In the Debug perspective press the Resume button to run the code execution.

In the following video, we are showing the procedure of flash and run on two different STM32 development boards. Note that this video has been created with an older version of ChibiStudio when the Generation of the Launch configuration wasn’t required.

The first “flash and run” procedure is very important to check if you have set up the toolchain correctly. As example, if you are not able to launch OpenOCD maybe there is a problem with ST-Link drivers: in this case check that drivers have been installed correctly and check also that the USB cable has been connected properly using to the proper port: certain Discovery kits have more than a USB port so you have to check that you are using the port marked as ST-Link USB.

If you receive an error while switching on Debug perspective it could be that OpenOCD has not been started properly or that it has lost connection with the target so you have to relaunch it (in debug context the MCU targeted by the debugger is usually called target).

If OpenOCD starts properly, you will be able to read the target voltage, the number of breakpoints and watchpoints

Information about the target will appear in the console windows and this will look like Fig.9. While OpenOCD is running, in the Debug perspective, you will see a related entry as shown in Fig.10. Note that,

You cannot launch OpenOCD twice and you cannot launch the flash and run procedure if OpenOCD is not running. To restart the OpenOCD you have to terminate the first instance.

Resuming the code execution, one or more onboard LEDs on will start to blink. On STM32 Nucleo-64 there is a green LED, in case of STM32 Nucleo-144 there are three colored LEDs which execute a nice light game, in case of STM32F3 Discovery it is even showier since this board has 8 LEDs.

If LEDs blinks you have successfully completed this tutorial and you can jump to the next article. In case of problems, just comment on this article or subscribe to our forum.

In this article, we focused more on the IDE and the basic procedures required by software development. In the next article, we will take a deeper look to default demos focusing more on programming.

Previous and next

This article is part of a series of articles which are meant to be tutorials. I have composed them to be read in sequence. Here the previous and next article of this series:

Replies to Developing on STM32: introducing ChibiStudio

  • hi,

    Great starting article, one observation though…
    Isn’t the case that yy is actually the most significant two digits?
    I mean…it is not the information that changes most often, and…for some reason, for me the most natural order is LittleIndian :P.

    anyhow, if you are interested, and consider this info needs a quick change, there you have the string to search for:

    “yy indicates the release year (less significant two digits) and changes only on major releases;”

    Regards,
    Victor

    • Hi Victor,
      thanks for posting. I am afraid I am missing the point. We are talking of how the version number has been explained or about the version number itself?

      In the first case, I am just describing how version number works. Let me make this more clearer with an example, if a new release has been delivered on October 2018 with the code-name “Red” than the version number will be 18.10.0 “Red” where ‘1‘ and ‘8‘ are the less significant digits of the year which is 2018. If in November 2018 a new patch will be deliverd with code-name “Azure” the newer version number will be 18.10.1 “Azure” (the year and month are not changing) and so on. The year and month will change on a new major release.

      In the second case, this is just an article. The right place to discuss about this is the Official ChibiOS forum.

      What am I missing?

  • Rocco,

    This is a really great writeup. Nice work – really. This is a tutorial I could have used 2 years ago – Ha!

    Looking forward to your next article on multi-threading..

  • Hi Rocco,
    Very nicely written and explained. Thanks for your efforts.
    I have been starting to learn STM with these articles.
    I have with me a custom board based on STM32F407ZGT6 which I bought from ebay named as RedDragon STM32F407.
    How can I develop code for this board. I mean the leds, switches are on different ports as compared to Discovery.
    How should I go ahead. Please suggest.

    Thanks in anticipation.

    • Hey there,
      you have to create a custom demo with custom board files for you board
      the step would be these:

      1. duplicate a demo for STM32F407 Discovery which is equipped with STM32F407VG
      2. make it compile
      3. go under CHIBIOS/os/hal/boards and duplicate the whole folder ST_STM32F4_DISCOVERY
      4. rename it with a name you prefer (as example RED_DRAGON_F4)
      5. in the project edit your board linked folder location (right click and properties) and link it to the new folder (according to the previous example it would be CHIBIOS\os\hal\boards\RED_DRAGON_F4)
      6. in the project edit your makefile to use the new files instead of the old one (replacing as example this line include $(CHIBIOS)/os/hal/boards/ST_STM32F4_DISCOVERY/board.mk with include $(CHIBIOS)/os/hal/boards/RED_DRAGON_F4/board.mk)
      7. Enter in the linked folder delete board.c borad.h and board.mk
      8. Configure board files and regenerate them following the next video

      Creating custom board files

      Some notes about configuration:

      • Take care to set each unused pin as Input Pull Up.
      • Take care to properly configure debug pins (SWDIO SWDCLK) which on F4 are PA13 and PA14 (Alternate 0).
      • Take care to set at least LED pin as Output Push Pull an Button pin as Input Floating.

      If you are not aware of how to configure GPIO take a look to this article.

      I will write an article about this soon.

  • Hi.
    Thanks a lot for your detailed reply.
    Is there not a simple way of doing this. I have read about ST CubeMx. I am not sure, but I read it can generate the files directly for specific micro.
    Is it possible use these generated files with Chibistudio so as to create everything from scratch?

    • The generator creates the whole board.c, board.h and board.mk. Once you have generated them you can use stand alone in every ChibiOS project. It seems complex but it is quite easy because, in the beginning, you have just to set few PINs plus eventually the external oscillator frequency. The goal should to create a simple demo which blinks a LED. Are you using an external debugger or a simple bootloader?

  • I am using external STLink debugger.
    My first aim is of course to blink the Leds and to read the switches.
    But as I checked with STCubeMx we can initialize all the peripherals as we want but with the duplicating approach we will be duplicating only discovery functions.
    I will try the duplicate method for my first project and then would love to try CubeMx.
    Thanks for your support.

  • Hello sir as you told I downloaded chibistudio setup and extracted also. but ti is not showing the setup.please reply

  • As Linux developer I really hate all this stuff related setting up the development environment, learning how it works for a given board, installing IDES… and repeating all that process for each board I work with. I am developing for a STM32 platform using the gcc-arm-none-eabi, libnewlib-arm-none-eabi and gdb-arm-none-eabi packages from my Ubuntu 16.04 LTS. I load firmware to the board using dfu-util. This is a more portable and easy to install environment, even easier to maintain documentation updated. Anyway, all the documentation is really very well explained and I want to read all your posts for a better understanding of Chibios and STM32 platforms. Thanks for sharing!! 🙂

    • Yeah, we know that this is pity for a linux developer but here we are trying to address all kinds of problems especially for windows user which are not used to command line and related. Thanks for you feedback.

  • HI! Thanks for answer my question. two quick question I am using ChibiOS studio preview 20 and my External Tools Menu (Orange) doesn’t have three different configurations which was depending on the version of our ST-Link but “OpenOCD on STLink” and “OpenOCD on ICDI” and “OpenOCD no interface” so is this normal? or not If is not How do I fix it. by the way I am using ST-LINK V2. that is one number two In your article the development board is STM32 Discovery but I don’t have it I only have maplemini and I also saw that you demo folder have corresponding demo and of course I have succeed to compile it but due to the OpenOCD problem I can not download it also I do not know which configuration script I should have can you help me thank you!!!!!

    • Hello,
      question one: starting from ChibiStudio Preview 20 the external tools menu is slight changed. Please re-read paragraph 4.6

      question two: at a quick read mapple mini has a F103 with no onboard stlink. You have to use an external debugger to use openocd. Mi suggestion is to switch to a STM32 Nucleo-32 which already includes the ST-Link. Even more I would use and STM32F3 more than an STM32F1 which is obsolete. (NUCLEO-F303K8)

      Note that even if I usually reply to every comment this is not the better place to get support. I suggest you to visit forum.chibios.org

      Ciao,
      RM

  • Hi Rocco.
    May you help me?
    Now I am using Ubuntu Linux to program stm32f405 with Elipse Oxyden. May you guide me how to add ChibiOS to eclipse oxyden? I searched on internet, but there was no way I found.
    Thank you so much.

    • Hey there,
      there were some incompatibilities with Eclipse prior this moment. I am planning to prepare a new ChibiStudio Preview 22 in the next weeks.
      Up to that moment, note that there is a mint based virtual machine by Giovanni Di Sirio… you could take inspiration from it.
      Take a look here

    • Hi Van, I’m using Ubuntu too… Giovanni Di Sirio told me to try the Mint setup on Ubuntu maybe it may work. Please Van Quang let me know when you successfully run it on Ubuntu.

  • When it comes to IDEs, I generally do not like Eclipse-based solutions. The dark mode is … just bad, it breaks indentation on nested switch-case blocks (I know that code should be refactored sonner than later), renaming include guards with the refactoring tool does not work (it renames the first one back reliably here) … It has just become too complex to handle and relying on all those 3rd-party modules does not improve the situation.

    I am working in the MCU field for a month now and really want to get rid of our Eclipse-based tool chain. Simple Makefile projects that can be opened in the IDE of your choice (Qt Creator for me) would be nice. Not sure if that is possible without entering another hell but I am currently investigating this step … which will also be a step away from STs software stack, which bit our arse twice since I started working here.

    • Hey there,
      I moved the comment under the proper article. Note that ChibiStudio is just a helper that allows browsing the code and which provides a simple interface for debugging (there is even a debugging plugin that comes with ChibiStudio).

      Anyway, ChibiOS is standalone. Open a command prompt, point to the directory of the project you want to build and make. Obviously GCC should be added to the path before. Exploring C:\ChibiStudio\start_gcc70.bat you will notice that the batch is adding some directories to the path for that instance:
      set PATH=C:\ChibiStudio\tools\gnutools\bin;%PATH%
      set PATH=C:\ChibiStudio\tools\openocd\bin;%PATH%
      set PATH=C:\ChibiStudio\tools\GNU Tools ARM Embedded\7.0 2017q4\arm-none-eabi\bin;%PATH%
      set PATH=C:\ChibiStudio\tools\GNU Tools ARM Embedded\7.0 2017q4\bin;%PATH%

      You can add them permanently in case you want to build ChibiOS from the command line or set up a new IDE.

      Also, you should take a look at the demo for the STM32F3 Discovery which is ready to be imported in Keil or IAR.

      Even you should take a look here. They are creating a new IDE from scratch because they do not like Eclipse so much. I neither like Eclipse but I suppose it does its job decently and I got used to it so no plan to explore new alternatives in the near future.

  • Hi Rocco,

    After I’ve built the demo, and selected “OpenOCD on STLink”, I am not able to select a .launch file to carry out the flash/run. There is no debug folder to search for this file manually (there is a build folder, though). What am I doing wrong?

    Thanks.

    • Hello Anthony,
      a very good question actually. Starting form ChibiStudio 2020-03 the launch configuration shall be generated through a new procedure. Please take a look to this post, more in detail the point 3.

      I will update this article in future but at the moment we are working on a genera restyling of the entire website and we are busy with that.

  • Hello, I thought it is good to read this content!

    I am making a datalogger, with USB host MSC and USB host HID (also, LCD SPI, Flash Memory SPI, Accelerometer I2C, RTC I2C and One Wire temperature sensor). I am using a STM32F407VG uC.

    I managed to make it work with the STM32CubeIDE (which also uses Eclipse), but due to several functions, I am looking to use RTOS.

    Unfortunately at STM32CubeIDE I was not very lucky with RTOS and USB host, ST offers some sample projects, but they are from old versions of compilers, and when importing the project it is not recreated as a native project. So I’m trying to understand about ChibiOS.

    I found some quotes that ChibiOS documentation is difficult for new users, I would like to know if there is any video playlist that can start from the beginning and arrive at USB Host.

    Thank you!

  • Relating the missing flash/run configuration in the latest version of the IDE… PLEASE PLEASE take a little time to AT LEAST insert a small errata / link in the text body. I’m sure a few more people will waste a lot of time looking for a non-existent problem before finally coming to the middle of the user comments. Thanks!
    Regardless, these tutorials are really beneficial to get started quickly and correctly with ChibiOS, thanks for your excellent work.

    • Hello Giorgio,
      thanks for your feedback. The plan is to update the entire article, but as you may understand this is a personal blog that I am writing and maintaining in my spare time: I have other priorities at the moment.

  • Hello Rocco,

    I have run into an issue with the final step of the debug process, after I generate my debug configuration and run the debugger I receive the following error message. Do you have any idea of what this could be.

    Error in final launch sequence:

    Failed to execute MI command:
    -target-select remote localhost:3333

    Error message from debugger back end:
    localhost:3333: No connection could be made because the target machine actively refused it.
    Failed to execute MI command:
    -target-select remote localhost:3333

    Error message from debugger back end:
    localhost:3333: No connection could be made because the target machine actively refused it.
    localhost:3333: No connection could be made because the target machine actively refused it.

    Thanks,
    -Connor

    • Hey Rocco,

      Giovanni was actually able to help me out on the chibi forum, the fix was quite simple. turns out I needed to run the ““OpenOCD no interface (prompts for .cfg target configuration)” in addition to running the “OpenOCD Generate configuration…”. I wrongly believed that just generating the configuration would open port 3333. I believe you actually addressed this in a previous comment. Possibly a quick revision to this article may aid future developers. That being said, these tutorials have been incredibly helpful and are very well put together.

      Thanks,
      -Connor

  • hi Rocco,

    i saw Connor messages above, and followed the steps he mentioned that first to run the ““OpenOCD no interface (prompts for .cfg target configuration), second to to run the “OpenOCD Generate configuration…”, and third to select the generated configuration. but i got an error below:

    Error in final launch sequence:

    Failed to execute MI command:
    symbol-file C:/ChibiStudio/chibios203/demos/STM32/RT-STM32L496ZG-NUCLEO144

    Error message from debugger back end:
    C:/ChibiStudio/chibios203/demos/STM32/RT-STM32L496ZG-NUCLEO144: No such file or directory.
    Failed to execute MI command:
    symbol-file C:/ChibiStudio/chibios203/demos/STM32/RT-STM32L496ZG-NUCLEO144

    Error message from debugger back end:
    C:/ChibiStudio/chibios203/demos/STM32/RT-STM32L496ZG-NUCLEO144: No such file or directory.
    C:/ChibiStudio/chibios203/demos/STM32/RT-STM32L496ZG-NUCLEO144: No such file or directory.

    Best Regards,
    Mike

  • i found the problem. It seems that i have to select the elf file first, before running the “OpenOCB Generate configuration”. Else, it won’t generate correct configuration that is able to locate where is the elf.

  • Hello Rocco,
    I use a “NUCLEO-G474RE” board to learn chibistudio,but i can not find the corresponding script file under folder C:\ChibiStudio\tools\openocd\scripts\board. can you help me!

  • hello sir i have created a library for flash and i want it to include an library created by me and want it to access globally in any code like lis302dl library, how i can do it

Leave a Reply to sumaiyyaattar Cancel reply