The STM32F030 driving an ST7789 display

The ST7789 display used in this example is a 1.3 inch 240×240 colour LCD display. It interfaces to the STM32F030 at the pretty fast speed of 24MHz. The display is connected as follows:
My intention with this circuit is to create a low cost conference badge (actually for Dublin Maker 2019). The target bill-of-materials cost is €5 – most of which is attributed to the display.
Full size image
Connecting the hardware is only part of the story however and a software library is also required. This was based on the Breadboard Games code from last August in Wexford. The main changes that had to be addressed were the new initialization code and the openAperture code. These were based on the Adafruit library code and the manufacturer’s datasheet. This library includes some graphic drawing primitives as well as other functions to support game play (e.g. timing and random number generation). Additional functions will be added as the badge develops.
Code is available on github
A video of the library in operation is available on YouTube.

Weather station part 3: putting it all together


The previous two posts on this topic dealt with the BMP180 pressure/temperature sensor and the NRF905 radio transceiver separately. This post brings it all together and shows how energy consumption was reduced to prolong battery life. The original plan was to run this from two solar powered garden lights. These lights come with coin cell size NiMh batteries and a simple charging circuit. After a bit of fiddling I decided to put this to one side having concluded that the internal resistance of the coin cells was quite high resulting in a large voltage dip during transmission. Furthermore the capacity of the batteries is so small (40mAh printed on the case) and the quality so poor that they were unable to power the station through the night. For the moment I have switched to a pair of rechargeable 1300mAh AA batteries that are charged externally. I may revisit the solar power option later and replace the tiny NiMh batteries with some decent AA or AAA ones.

Reducing power consumption

The three main power consuming elements in the weather station are:
(1) BMP180 pressure/temperature sensor module
(2) NRF905 radio transceiver
(3) STM32F030 MCU

According to the datasheet, the BMP180 has an idle current of 5uA and an active current of up to 650uA. This device is mounted on a breakout board which has a voltage regulator (XC6206) with a quiescent current consumption of 3uA. A MHC5983 magnetometer is also on the board with a quiescent current of 2uA and an active current of 100uA. The total quiescent for this board should be the sum of these : around 10uA. Only the BMP180 is used so the peak current should get to around 650uA.
The NRF905 is powered down when not in use. The datashseet states that its current consumption should get down to 2.5uA when powered down, 32uA when in standby and 20mA when transmitting at +6dBm.
The STM32F030 is put in to deep sleep mode between transmissions. The LSI clock and RTC are left running and periodically wake the system up. It is a little difficult to determine what the current consumption should be in this mode. According to the datasheet, the current consumption should be between 2 and 5 uA. The power consumption of the RTC is of the order of 1uA according to ST literature. During active mode at 8MHz with code executing from flash, the current consumption should be around 4mA.
Adding all of the standby currents up we get to about 10 + 2.5 + 5 + 1 = 18.5uA.
Active mode current flow should be dominated by the STM32F030 and the NRF905. I would expect active mode currents of 5mA with no radio transmission and 25mA during transmission.
The main program loop is as follows:

while(1) {            
    low_power_mode(); // Sleep and wait for RTC interrupt

This transmits a packet with the following format:
This is interpreted as a temperature of 23.3 C and a pressure of 998.04 milibars
The RTC is configured to wake system once per minute (the weather does not change that quickly)
Low power mode is entered and exited with the following two functions:

void low_power_mode()
    PwrLow(); // Put NRF905 into low power mode
    // Turn off GPIO B,A and F		
    RCC_AHBENR &= ~(BIT17+BIT18+BIT22);			
    RCC_APB1ENR &= ~BIT21;   // Turn off clock for I2C1
    RCC_APB2ENR &= ~BIT12;   // turn off SPI1 	
    RCC_CFGR |= 0xf0; // drop bus speed by a factor of 512
    cpu_sleep();      // stop cpu
void resume_from_low_power()
    RCC_CFGR &= ~0xf0; // speed up to 8MHz		
    // Turn on GPIO B,A and F
    RCC_AHBENR |= BIT18+BIT17+BIT22;
    RCC_APB1ENR |= BIT21;   // Turn on clock for I2C1
    RCC_APB2ENR |= BIT12;   // turn on SPI1 	
    PwrHigh(); // power up the radio

Entering low power mode, the code shuts down the NRF905, disables clocks to the I/O port, I2C and SPI peripherals, slows the peripheral bus clock and stops the CPU. Resuming from low power reverses these steps. The CPU can be placed in shallow or deep sleep modes depending upon the setting of bit 2 in the system control register. The code below enables deep sleep mode which stops the CPU clock and powers down flash memory.

    SCR |= BIT2;  // enable Deep Sleep mode

On receipt of an RTC interrupt, the CPU exits sleep mode and resumes execution.



The measured quiescent current was a lot higher than expected; around 170uA @ 3.6V and 90uA at 2.4V. Why is this so much higher? Perhaps passive components on the breakout boards such as pull-down or pull-up resistors are raising the levels. All of the peripherals on the STM32F030 may not be powered off. A current drain of 90uA at 2.4V should allow the station to idle on 1300mAh for more than a year and I felt that this was probably good enough for now. The actual run time is likely to be a lot lower than this due to self discharge in the battery and the energy used during the brief transmission interval. I’ll see how it goes with an extended test.
The active mode current is lower than expected. The MCU current just before transmission is about 3mA. It would seem that the radio is only drawing (19-3) = 16mA during transmission. The datasheet suggests that this level of current should be typically 20mA. During experimentation I found that the current levels during transmission were consistently less than suggested by the datasheet – maybe the datasheet typical values are a little overstated.

Looking at the graph, the 5mA (max) region consists of three approx equal length periods: I2C read of temperature, I2C read of pressure and SPI transfer to NRF905. The NRF905 data packet consists of a preamble (10 bits), address (32 bits), data packet (32 bytes) and a CRC field (16 bits). In total this is 538 bits. The data rate if 50kbps which means the transmission time should be 10.76ms. This agrees with the graph.

Debugging issues

I developed this code using my ST-Link V2 debugger salvaged from a Nucleo board and reflashed with J-Link firmware. OpenOCD and GDB allowed me to debug and download code. A problem arises when the CPU is in a deep sleep : OpenOCD can not talk to it in this mode. It complains and times-out repeatedly. Occasionally, it catches the CPU when its awake allowing you halt it and to download code. If the sleep interval is long (e.g. a minute or more) this can be quite frustrating. There is a way around this however. If you pull the Boot0 pin high and power cycle the MCU it will boot to ISP mode. Openocd & GDB can happily attach to this allowing you to download fresh code. When download is complete, set Boot0 to zero and power cycle once more to run your code. You don’t need to stop OpenOCD or GDB when you do this power cycle (I just pulled a wire from the breadboard and put it back again)

Radio range

The NRF905 radio modules were supplied with some short antennas which seemed too short for 433MHz. I found that replacing them with quarter wave length wires slightly improved signal range. I settled on a power output level of 6dBm as it gave me an (urban) range of about 100m – enough for my needs. The radio module seemed to misbehave at the higher power level of +10dBm. This could be as a result of the breakout board or perhaps poor supply regulation. Running it a +6dBm produced stable results.

Code download

You can download the code for the weather station over here on github:

Weather station part 2: The radio link


As mentioned in the previous post I’m hoping to put together a weather monitoring system. It will consist of an outstation in the garden which will be solar powered. The outstation will send data over a radio link to a base station located indoors. This post outlines the radio link code and setup.

The outstation radio wiring

The figure above shows the connections between the outstation MCU, the BMP180 pressure/temperature sensor and the NRF905 radio module. There are lots of connections to the radio module and I’m not sure they are all strictly necessary at the moment but for now they stay.
The NRF905 can transmit at a number of different frequencies. After some trial and error I decided to go with a frequency in the 433 ISM band as it seemed to work best (the NRF905 is on a breakout board which already has inductors and capacitors in the antenna circuit which I suspect were tuned for this band). The actual module is supplied from (link). Overall I found this module much easier to use than the NRF24L01.
The code for the radio link is available on github over here. This code transmits an counter value once per second at maximum power (10mW). This current consumption while transmittiing is quite high (about 29mA) but this current burst is pretty short lived. Early indications are that the range is sufficient for my purposes though I may fiddle with the antenna later to see how far it can be pushed.
A (messy) prototype is shown in the photo below
You may notice the ST-Link debugger salvaged from a Nucleo board attached to the target. This debugger was reflashed with the Segger/J-Link firmware and behaved very well.

The base station

The base station consists of an STM32L011 Nucleo board attached to an NRF905 module. A photo is shown below (wiring details in the code only for the moment)
The Nucleo outputs any data it receives over its built-in USB/Serial converter. This is displayed on the host PC.
One problem arose with the STM32L011’s SPI interface which is covered in its errata sheet. There is a timing problem with the SPI pins and ST provide a simple fix for this (which I found out about after two days of head scratching :). Code for the base station is available here

Next post

The next post will deal with the issue of power consumption on the outstation. This needs to be kept as low as possible if the solar power cells I salvaged from cheap garden LED lights are to work out.

Weather station part 1: Pressure and temperature


I’ve decided to try to put together a solar powered wireless weather station this summer. It will consist of two parts: an outstation comprising of a pressure/temperature sensor attached to an STM32F030 MCU; all powered by a cheap solar panel and a rechargeable battery. The MCU will use an NRF905 radio module to send data back to a base station within the house which will display it on screen. Power consumption in the outstation will have to be kept to a minimum.
The base station will consist of an STM32L011 Nucleo board and an NRF905 module. It will interface to the host PC using the built-in UART.

The pressure/temperature sensor

About a year ago I bought a BMP180+HMC5983 module from The BMP180 component is a very sensitive atmospheric pressure and temperature sensor with an I2C interface. The HMC5983 is a digital magnetometer may have a future role to play in the weather station.

The outstation MCU

I have previously posted a description of how to mount the STM32F030 TSSOP-20 MCU on a breadboard friendly breakout board. These MCU’s can be configured to consume very little energy. I had several of these lying around so the seemed the logical choice.


The image above shows the wiring involved. The bmp180 module has built-in pull-up resistors so its quite simple. The code on the other hand is quite complicated. The BMP180 has a very strange conversion routine that takes the sensor outputs and converts them to pressure (in Pascals) and temperature (in degrees C x 10). The measurement results are output via the UART TX pin on PA9. I connected this to the host PC using a USB/Serial converter.
The code can be found here. It includes a lot of debugging code that was useful during development. This is very much version 0.1 as it does not take power consumption into account in any way. That will be the subject of a future post.

A very low cost STM32F030 dev board

Aliexpress have begun shipping a low cost breakout/development board for the STM32F030. The board can be programmed using ISP and a USB/UART interface as shown below. The boards cost varies but I got mine for 1.58 Euro.
I had previously worked on some suitable examples which can be found over here.
These examples are built using a Makefile however I have found that the following script is a lot easier to work with (just make sure your PATH environment variable includes the directory where the arm compiler programs and utilities are stored).

arm-none-eabi-gcc -static -mthumb -g -mcpu=cortex-m0 *.c -T linker_script.ld -o main.elf -nostartfiles 
arm-none-eabi-objcopy -g -O binary main.elf main.bin
arm-none-eabi-objcopy -g -O ihex main.elf main.hex

You then program the chip by linking the Boot0 pin and 3v3 with the jumper, hit reset and enter the following:

stm32flash -w main.hex /dev/ttyUSB0

To run your program, move the jumper so that it links Boot0 to GND and hit reset.
The USB/UART interface appeared as /dev/ttyUSB0 on my system, yours may vary (on Windows it will be something like COM3)
stm32flash can be downloaded from a number of sources. On Ubuntu it can be installed with

sudo apt-get install stm32flash

The ARM cross compiler suite can be downloaded from

Aliexpress link to the board.

The Nucleo ST-Link reflashed as a J-Link debugger

ST Microelectronics recently announced that the ST-Link debug interfaces on their boards can be reprogrammed as Segger/J-Link interfaces.  Curious, I flashed the firmware on to such a debugger as directed here .

I then wired the debugger to an stm32f030 as shown in the pictures below (the debugger had been snapped off the Nucleo board because the target MCU had been damaged)


The SWD connections are taken from CN4 and joined to the corresponding pins on the STM32F030.  Note the way the 3.3V is taken from the top of the jumper JP1:  The jumper must remain in place to power the debug interface.

Important: The Boot0 pin must be pulled to ground with a resistor or the CPU will boot to ISP mode and you won’t be able to run your test program.

In addition to the SWD connections, the STM32F030’s UART is connected to the TX and RX pins on the debug interface.  This allows an application running on the STM32F030 to send data to the host PC.

All of this was done in Ubuntu Linux using OpenOCD.  The OpenOCD configuration script (tbrd.cfg) is shown below:


# This is for the STM32F030 connected to the ST-Link Nucleo
# programmer that has been reflashed with the J-Link firmware

source [find interface/jlink.cfg]
transport select swd
source [find target/stm32f0x.cfg]
adapter_khz 1000

reset_config srst_nogate

The debug arrangement worked well: programs loaded quickly, registers could be examined and breakpoints set etc.

To run openocd type the following:

sudo openocd -f tbrd.cfg

In a new terminal window, run arm-none-eabi-gdb

The transcript for a simple session is shown below.

GNU gdb (GNU Tools for ARM Embedded Processors)
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()
(gdb) monitor reset halt
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x080000b4 msp: 0x20001000
(gdb) load main.elf
Loading section .text, size 0x328 lma 0x8000000
Start address 0x8000000, load size 808
Transfer rate: 3 KB/sec, 808 bytes/write.
(gdb) continue