Skip to main content

Makefile Based STM32 Development Environment

The development environment discussed here is minimal, terminal based, and cross platform. This configuration assumes that a terminal based text editor such as vim and the make utility are the primary tools for programming. It consists of following components:
  • GNU ARM Embedded Toolchain
  • Makefile Utility
  • STM32CubeMX
  • Flash Tool (JLink or OpenOCD)
  • Hardware
The most recent version of the compiler suite can be found here. The toolchain is self-sufficient. Thus you can simply unzip the archive into any directory of choice then you are good to go.

In Linux, make utility is included in a package such as build-essential. If you have C/C++ compiler installed on your system then you already have it. In Windows, preferred way to get the utility is to install cygwin first, then to install make from there. Alternatively, you can use the one comes with MinGW system or you can find one of the precompiled version. However you may need to choose 32bit version of make, since the GNU ARM toolchain for Windows is 32bit.

STM32CubeMX is a Java program. Thus it runs on Java RE regardless of the host O/S type. Recent versions of the program comes with installers for Windows as well as for Linux. After the install, you can download SDK for your device using STM32CubeMX.

Building A Makefile Project Using CubeMX

Start STM32CubeMX, select a device or a board, and configure peripherals. Then choose Makefile option when generating code. It will populate the output directory with all the necessary files and folders including the Makefile located on the root.  This project is self-sufficient and portable. You can use the same project in Windows and in Linux. You only need a toolchain and make utility to build.

Before building the project by running make however, you need to enter the correct BINPATH variable, to which all toolchain commands are referring. If the path is accurate, then the building process should be done without an issue.  Following lines will make the setting cross-platform.
Source file 
  101 ifeq ($(OS),Windows_NT)
  102 	BINPATH = c:/Program\ Files\ \(x86\)/GNU\ Tools\ ARM\ Embedded/6\ 2017-q2-update/bin
  103 else
  104 	BINPATH = $(HOME)/bin/gcc-arm-none-eabi-6-2017-q2-update/bin
  105 endif

Flash Download

Most of the ST dev. kits are equipped with onboard version of STLink v.2 interface, some of which you can easily break apart from the kits and use them as stand-alone programmers for your own STM32 projects.

In Windows, you can use ST-Link Utility (GUI) or ST-Link CLI (command line version). If your STM32 kit supports mbed interface, you can simply drag and drop your output onto the drive populated when you insert the kit into a USB port of your computer. There is a Linux version ST-Link tool as well.

Alternatively you can reprogram the STLink and turn it into a Segger J-Link compatible programmer, so that you can use J-Link software by Segger. Benefit of this is to allow you to have cross-platform Makefile setting for flash download.
Source file 
  230 flash:
  231 ifeq ($(OS),Windows_NT)
  232 	c:/Program\ Files\ \(x86\)/SEGGER/JLink_V622d/JLink -if swd -device stm32l052k8 -commandfile jlinkcmd
  233 else
  234 	JLinkExe -if swd -device stm32l052k8 -commandfile jlinkcmd
  235 endif
Note that there is a small difference in the name of the JLink utility, i.e. JLink.exe vs JLinkExe. This command reads command script from the file jlinkcmd, which may look like this: Source file 
    1 r
    2 loadfile build/your_output.bin 0x8000000
    3 r
    4 g
    5 exit
Now you can download the image to the device without leaving your editor. Finally, you can use OpenOCD in a similar way as OpenOCD supports ST-Link directly as well.
Labels:

Comments

Post a Comment

Popular posts from this blog

A Simple STM32 Example Project

Most of the embedded projects share certain initial steps. You need to confirm the clock settings before doing anything, then you want to have debug connection via a UART channel since it is cheap  but still it can provide useful information for debugging. Let us start with CubeMX. You select a device/board of your choice, set up the pinouts for one GPIO output and one UART port. Configure the clock if necessary then create a project. Clock Checking using SysTick The sanity of the clock setting can be done by checking the SysTick interval. All Cortex-M series core have SysTick timer by default, which should fire at 1msec interval while the MCU is active. In the STM32Cube, the SysTick is initialized by HAL_Init() call, which in turn calls SysTick_Config() in CMSIS. Once the SysTick is initialized, it generates 1 msec interrupt and this interrupt is handled by SysTick_Handler() according to the Cube framework. Source file 1 /** 2 * @brief This function han...
Post a Comment
Read more

STM32 USB MSD with SD Card

Build a low level driver for SD card, then the glue logic for FatFs and USB MSD is pretty much the same as Flash memory case posed before. In case of SD card, sector size is 512 in most of the cases. Thus the memory requirement is much relaxed. You can even allocate a file buffer that is bigger than the sector size. FatFs site has a  dedicated page for MMC/SDC, on which you can find fairly detailed explanation about how to interface MMC/SDC via SPI bus. Implementation should be straightforward until you encounter with cheap SD cards that do not behave very well. In such cases, you either have to protect your code with redundancy or just stick with quality devices. If you choose SanDisk or Kingston brand, you will be safe. ADATA on the other hand, frequently generates timeout error at first try. Most of the SD card sockets have a pin to detect the presence of the card. This pin is usually connected to GND pin or some other pin. You can use this to generate interrupt whenever ...
1 comment
Read more

STM32 USB MSC Device with FLASH memory

USB Mass Storage Class framework implements bulk-only-transfer (BOT) with SCSI protocol. USB packets from the host eventually converted SCSI transport commands by the middleware, in which data is exchanged (read / write) in the unit of logical block, typically 512 bytes. This SCSI commands works well with SD card system where a dedicated controller does the job of managing the actual memory elements. If you want to use a FLASH chip as a memory unit instead, you need to handle read / write operation directly. Fortunately, most of flash memory support 4KB block erase. This makes the 4096 bytes as a natural choice for the size of the logical block in the file usbd_storage_if.c. In this case, 8Mbit Flash memory was used. During initial enumeration, this information is registered to the host. The middleware maintains one logical block size of buffer and handles USB transaction where each payload is only 64 bytes. It then calls SCSI requests to store / retrieve data to / from physical...
Post a Comment
Read more