STM32F1xx micro-controller C firmware template
Go to file
King Kévin 21a23e18c1 README: fix lists 2021-01-28 13:17:09 +01:00
lib sensor_gm1351: make decoding user driven 2021-01-28 11:12:32 +01:00
libopencm3@cb0661f81d update libopencm3 2020-02-17 11:43:47 +01:00
.gitignore cherry-pick from busvoodoo branch, part 2 2018-02-18 15:20:01 +01:00
.gitmodules remove STM32duino-bootloader 2016-08-14 19:03:17 +02:00
Doxyfile doc: fix documentation 2020-01-03 00:16:59 +01:00
LICENSE.txt add GPLv3 license file 2018-02-13 15:14:10 +01:00 README: fix lists 2021-01-28 13:17:09 +01:00
Rakefile Rakefile: use black pill board for this project 2020-02-20 11:51:56 +01:00
application.c application: add gm1351 decoding 2021-01-28 11:13:34 +01:00
application.ld ld: update ld script to updated libopencm3 2020-01-12 15:52:27 +01:00
bootloader.c doc: fix documentation 2020-01-03 00:16:59 +01:00
bootloader.ld ld: update ld script to updated libopencm3 2020-01-12 15:52:27 +01:00
global.c global: improve user storage security 2020-02-11 12:15:31 +01:00
global.h global: switch debug off, enabling watchdog 2020-02-20 11:52:59 +01:00

This is the firmware for the sound lever meter. It will read the measurements from a GM1351 sound level meter and send them over Bluetooth.



The GM1351 is a digital hand held sound level meter. It is available under multiple brands. There is no connector/interface to read the measurements. Instead I am using test point on the back of the PCB. This allows me to monitoring the interface to the LCD and read back the data displayed into measurements.

The measurements are send transmitted over Bluetooth using a SPP module.


The firmware runs on a black pill development board. It is based on a STM32F103C8T6 micro-controller. This will do all the processing and control the peripherals.

The Bluetooth module is a HC-05. It should be configured to be a slave and offer a SPP profile. The measurement will be forwarded by the micro-controller over the UART part configured at 115200 bps 8N1. It will transmit the measurement in the format "123.4 dBa\n".

This does not use a Bluetooth Low Energy (BLE) module because it does not fit the needs. There is no need to save energy since the device needs permanent power just for the display. There is a constant stream of data (not fitting BLE principles). The is a specified Classic Bluetooth profile for serial data: Serial Port Profile (SPP). BLE module use non-standard GATT characteristics for serial data transfer.


Connect the peripherals as described below.

MT3608 voltage regulator module:

  • IN-: ground
  • IN+: 5V
  • OUT-: ground
  • OUT+: IDC 2x3 pin 5

Set the MT3608 voltage output to 9V. This is meant to replace the GM1351 PP3 9V battery. It kind of also works with 5V, but the LCD is very dim. Since I don't know if the measurements remain accurate at 5V, I prefer to provide the voltage it was designed for.

HC-05 Bluetooth SPP module:

  • STATE: no connect
  • RX: USART3_TX/PB10
  • TX: no connect
  • GND: ground
  • VCC: 5V
  • EN: no connect

n-channel MOSFET 2N7000:

  • 1 source: ground
  • 2 gate: PB0, add pull down resistor
  • 3 drain: IDC 2x3 pin 2

IDC 2x3 2.54 mm, micro-controller side:

  • 1: ground
  • 2: PB13, SPI2_SCK
  • 3: 2N7000 pin 3
  • 4: PB15, SPI2_MOSI
  • 5: MT3608 OUT+
  • 6: PA8

IDC 2x3 2.54 mm, GM1351 side (solder wires on the PCB):

  • 1: B-
  • 2: LCD_WR
  • 3: D7/D8, on the text side, to control the ON/OFF button
  • 4: LCD_DATA
  • 5: B+
  • 6: LCD_CS

All pins are configured using defines in the corresponding source code.



The source code uses the libopencm3 library. The projects is already a git submodules. It will be initialized when compiling the firmware. Alternatively you can run once: git submodule init and git submodule update.


To compile the firmware run rake.


To generate doxygen documentation run rake doc.


There are two firmware images: bootloader and application. The bootloader image allows to flash the application over USB using the DFU protocol. The bootloader is started first and immediately jumps to the application if it is valid and the DFU mode is not forced (i.e. by pressing the user button on the board or requesting a DFU detach in the application). The application image is the main application and is implemented in application.c. It is up to the application to advertise USB DFU support (i.e. as does the provided USB CDC ACM example).

The bootlaoder image will be flashed using SWD (Serial Wire Debug). For that you need an SWD adapter. The Makefile uses a ST-Link V2 along OpenOCD software. To flash the booltoader using SWD run rake flash_booloader.

Once the bootloader is flashed it is possible to flash the application over USB using the DFU protocol by running rake flash. To force the bootloader to start the DFU mode press the user button or short a pin, depending on the board. It is also possible to flash the application image using SWD by running rake flash_application.


SWD also allows to debug the code running on the micro-controller using GDB. To start the debugging session run rake debug.


The firmware offers serial communication over USART1 and USB (using the CDC ACM device class).