Mikroe Clicker 2 for STM32 and STLink v2

Mikroe Clicker 2 for STM32 and STLink v2

1 Introduction

In this tutorial we are going to see how to connect a STLink v2 debugger to a Clicker 2 for STM32 enabling users to do debugging which could be very useful in development phases. A debugger is a computer program which is used to test and debug another program usually named Target.

In embedded things are slightly different since the code is executed on an external MCU and it is required an interface Computer-MCU. In this case the Target is the MCU and a debugger is composed by the ensemble of a hardware and a software tool. Nonetheless, when the majority of people is talking about debugger,they are referring only to the hardware part.

A debugger allows the connection to a Target enabling the Host to load a firmware on it managing its code execution, allowing the inspection of its registers and much more. To do this, it uses some specific commands that usually depend on the MCU architecture: this means that there are specific debuggers for specific MCUs. The STLink v2 is a low cost debugger supporting both STM32 and STM8. In what follows we are going to use OpenOCD, an open source debugging software largely used in ChibiStudio since it is a reliable solution for debugging. continue reading…

Building OpenOCD under Windows using MSYS2

Building OpenOCD under Windows using MSYS2

1 About

In past, building OpenOCD under Windows was really complicated since it has a lot of dependencies and not was easily available under windows. With MSYS2 this task has become very simple and, if you need to use the latest stable version of OpenOCD in MSYS2, it is available as binary and could be installed with a single command.

In some cases, you need to build the development version of OpenOCD or, maybe, to apply some patches from OpenOCD Gerrit repository. Using MSYS2 and some PKGBUILD from the upstream repository, this operation is easy to accomplish.

1.1 Introducing MSYS2

MSYS2, which stand for Minimal SYStem 2, is a compact application based on Cygwin and MinGW-w64 which runs under Windows. It allow to use autotools, revision control systems and build native Windows applications using MINGW-w64 toolchains. The installation of packages is simplified since creators have ported Arch Linux’s Pacman. This brings many powerful features such as dependency resolution and simple complete system upgrades. When launched MSYS2 appears to be a simple terminal.

MSYS2 consists of three subsystems (here and out MSYSTEM) and their corresponding package repositories. They are msys2, mingw32, and mingw64.

  • The mingw subsystems provide native Windows programs and are the main focus of the project. These programs are built to cooperate well with other Windows programs, independently of the other subsystems.
  • The msys2 subsystem provides an emulated mostly-POSIX-compliant environment for building software, package management, and shell scripting. These programs live in a virtual single-root filesystem (the root is the MSYS2 installation directory). Some effort is made to have the programs work well with native Windows programs, but it’s not seamless.

1.2 Preliminary notes

First time I wrote this article I was looking for a simple recipe to build OpenOCD under Windows and create a standalone suitable for ChibiStudio. The initial purpose has been extended and this article now is addressed to the reader who wants:

  • install OpenOCD in MSYS2 from binary;
  • compile and install OpenOCD in MSYS2 from development repository;
  • export OpenOCD as stand alone. continue reading…

Hello ChibiOS

Hello ChibiOS

1 Something more about multi-threading

One of most important feature of ChibiOS is multi-threading. Oversimplifying, a thread could be imagined like a sequence of instructions (with associated a priority and a working area) and multi-threading means kernel can manage more than a thread independently, executing them in a parallel fashion even if there is a single core.

Achieving this requires Kernel must plan operation sequence: this task is called scheduling. We could act indirectly on this operation though priority levels. Priority follows a simple rule:

among all the threads ready for execution, the one with the highest priority is the one being executed, no exceptions to this rule.

There is a nice article on chibios.org about how to create threads.Threads must always have a chThdSleep() or some suspending function inside their loop. In this way they will yield the CPU ownership and the Kernel will perform a context switch resuming the thread in ready state having the highest priority. Typically a thread is resumed on a certain event, performs its operations and than is suspended.

The best way to maximize usefulness of multi-threading is to divide our application in more independent parts and make them cooperate to achieve our purpose. Every part will represent one of ours threads.

Consider a scenario in which a LED changes its state on button pressed: we can consider this like a kind of action and reaction. So we have two task: checking the button state and changing the LED state. We can assign these tasks to two different threads, in this way code related to every task is independent from other tasks and if a task changes we don’t have to edit the whole software.

In this tutorial we are going to use the green LED and the User Button of our STM32 Nucleo-64 F401RE to explain how to use multi-threading and to introduce the PAL driver. In the following step, we will modify the LED related task without editing the one button related.

2 STM32 General Purpose I/Os

The simplest way to interact with a MCU is sampling voltages from its pins or force a signal on them. Every MCU manages its pins in different way and typically pins or pads (inspired by contact pads) are grouped by ports. continue reading…