Setup Problems (and how to solve them)

The experience of setting up a development environment is far from consistent. Unfortunately, every year many poor souls are caught facing config issues that can take hours to resolve. The build up of frustration over such a long duration is not healthy and can result in configure-itis (which is prevalent among the developer population).

If you are reading this document, you may be wondering, “oh no, the steps I followed didn’t work and my firmware code still isn’t building!” Well fear no more, for this document has solutions to problems our teammates suffered from in the past!

If any of the solutions listed below do not work, please let the embedded lead know!

MacOS cmake cannot find the arm compiler

After following all previous steps, when running ./Tools/build.bash -c in Terminal, the build would fail and output:

This error indicated that cmake could not find the arm compiler.

To solve this problem, the following steps were conducted:

  1. Install the latest version of Xcode through the App Store (Note this is a 12 GB app)

  2. Install Homebrew

  3. Run the following bash commands in Terminal:

$ brew tap ArmMbed/homebrew-formulae $ brew install arm-none-eabi-gcc

After running the two commands, your code should build when you run ./Tools/build.bash -c.

GDB not working on MacOS

MacOS has very strict permissions when it comes to executing code, and often prefers to use certain tools over others. One example of this is the fight between lldb and gdb, between which lldb is preferred by Apple. While lldb is an extremely capable tool, unfortunately for Mac users, most dev environments (including STM32CubeIDE) uses gdb for debugging. As a result, if we haven't already done so, we must ensure we have GDB set up properly.

To install GDB properly, follow the steps outlined here starting at the “Generate a certificate” section. In case the blog is taken down, I have also included a PDF in the attachments that you can refer to.

If you don’t have GDB installed via Homebrew yet, run these commands in Terminal:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" $ brew install gdb

The first command installs Homebrew, so you can skip it if you already have it installed. The second command is what you care about as it installs the latest version of gdb. If you want to update gdb, you can run $ brew reinstall gdb.

Flashing to ZeroPilot boards yields ‘Failed to start GDB server'

Back in early 2021, many members on the team had trouble flashing to their boards, with the following errors coming up:

STMCubeIDE Error when Flashing:

st-link MacOS Terminal Interface: WARN common.c: unknown chip id! 0x3748

These errors meant that our STLink v2 could not communicate with the chip on our board.

Steps to take to resolve the problem:

  1. Make sure you have the following wires connected to your board: RST, SWDIO, SWCLK, GND, and 3.3 V. If you are missing any of these connections flashing won’t work.

  2. Ensure GDB is configured properly for your OS and has the correct permissions (OS dependent, googling is your friend)

  3. Ensure you have a .gdbinit file with the following written in it: set startup-with-shell off.

  4. Ensure that STM32CubeIDE can find your GDB executable and .gdbinit file. (refer to sub-step 1 below)

  5. Change the wires you are using to connect to the board (sometimes shitty wires can cause problems).

Sub-step 1: Ensuring STM32CubeIDE can find your GDB executable and .gdbinit file:

This sub-step assumes that you have created your .gdbinit file and that you have configured GDB correctly for your OS.

Now that you have GDB installed on your computer, you need to tell STM32CubeIDE (Eclipse) where to find the GDB executable and the .gdbinit file. This can be done by following the steps outlined in the “Set Eclipse for using gdb“ of this blog (For a pdf, see Set_Up_GDB_MacOS.pdf in the attachments). While the blog is made for MacOS, the window layouts are platform independent for STM32CubeIDE.

GTEST Files Missing

Run the bash file found in the attachments of the Unit Test Build page corresponding to your OS with Admin privileges.

Bash files can still say they were successful installing Gtest without admin powers, but will not allow you to compile.