Lora-E5 Software Development with Zephyr and VSCode (Part 2)

Here is how to create a simple STM-raw development environment that lets you build/run the provided Seed Studio LoRaWan examples as well as a working Zephyr OS development environment based on the Visual Studio Code (VSCode) IDE.

Zephyr is a multithreaded OS designed for tiny processors. It is great on power and has internal support for the SX126x direct as well as LoRaWan.

Development Environment

tldr; skip right down to installing the stm32cube if you don’t care about the why’s

How best to develop depends on what you need.

If you need a LoRaWAN node with some changes (like a sensor node that just sends constant data pulses) then using the STM32Cube IDE with the existing node firmware makes good sense.

Otherwise, I personally find that stuff too bit-twiddly with too much zero-structure C code. When the base code changes you have integration issues (the first time I tried to change the configuration the cube IDE tried to update the source files which immediately and permanently broke the build). When things go wrong you spend time poring through the STM32 documentation for register stuff and flipping through releases trying to find one that builds with this 3rd party library and … not fun.

A couple of years ago I switched from the Nordic library to the Zephyr OS and it was a relief to have a kind-of-solid open-source OS with a high-level device view. The maintainers seemed sharp and the codebase relatively clean. Let them worry about the hardware-specific bit stuff.

Zephyr seems even better now — and it newly has support for the STM32WL CPUs with board definitions for the LoRa-E5 dev board and the STM Nucleo STM32WL55 board.

Compare the power usage of STM/Raw vs Zephyr

I wanted to very quickly check out if the STM32WL cpu would hit OK power levels in Zephyr without huge exertions. Otherwise, it might be necessary to use raw STM32 C code and that’s almost a non-starter.

1. I hooked up a probe to the current test point on the development board. The test point measures only the CPU current (not the USB subsystem).
2. I ran the LowPower C application from Seeed using STM32CubeIde. It blinks the LED and goes into Stop2 power mode for half the cycle. I tested the halves at 1.60mA and 560uA.
   I’m not sure why the Stop2 power was so high but think the default clock was too fast. I tried a few things and finally moved on.
3. I then ran the Zephyr Blinky sample app (toggle the led, sleep a second, toggle, …) and it used 3.5mA. I tried adding in some sleep options but without debugging (which I don’t yet have outside of Cube) it wasn’t great and I gave that up.
4. Then, in the Zephyr Blinky project config, I added one line:
   CONFIG_PM=y
   which enables power management and the power usage during sleep dropped to about 220uA! That’s half the power of the best I could get from Cube in Stop2 mode. Since Blinky doesn’t really use any peripherals apparently most of them stay correctly turned off.

Now, is this representative? I don’t know but it’s a good sign. I’m sure it is possible to invest a lot of development, manually turn off a bunch of stuff in raw C STM code and then get great power readings — but having gone that route before it’s usually harder than it looks and usually doc/Google are inaccurate leading to lots of trial and error.

Visual Studio Code as the IDE

My preferred IDE is Visual Studio Code (VSCode) because I love the light weight and know the key-sequences by heart. Any competitors please note the find-all implementation (Ctrl-Shift-F). There are also lots of extensions, including STM32 debug support.

For unknown reasons west flash does not flash the LoRa-E5 sometimes with the STlink V3. The STM32CubeProgrammer application has been flawless with it.

Installing the STM32Cube IDE and support Tools

1. Start by installing the STM32Cube IDE and Programmer suite. The programmer works reliably and is the easiest way to turn off the read-only bit in the STM32 chip.
   The STM32CubeIde is useful for loading and debugging the supplied Lora-E5 sample LowPower and LoRaWAN applications.
2. Open this page: Wio-E5 Development Kit — Seeed Wiki (seeedstudio.com). Scroll down to the section labeled: Develop with STM32Cube MCU Package and follow those instructions until you can build the projects (and flash?) reliably. Ignore all the setting up LoRaWAN stuff.

Installing Visual Studio Code

1. Install VSCode and set it up any way you want.
2. Install two extensions:
   * for the Arm Cortex the Cortex-Debug extension
   * for the STM32WL chip the Cortex-Debug: Device Support Pack — STM32WL

Installing Zephyr OS

1. Follow the Getting Started Guide — Zephyr Project Documentation but don’t create a virtual environment since it’s tough to use that with VSCode.
2. Ensure the west build of blinky works. If west flash does not work then flash your chip using the STM32CubeProgrammer with the zephyr.elf file in build\zephyr.

Building a Zephyr App Folder

The usual zephyr paradigm is to install the entire 3.5GB zephyr git tree in your source code folder which I find repulsive since I may have many little test apps lying around and zephyr gets updated now and then.

Instead, once the “west install” for the zephyrproject folder created above is done we can — and shall — use that zephyr (%HOMEPATH%\zephyrproject\zephyr) forever.

So, to get started on the test app…

1. copy the entire receive folder from %HOMEPATH%\zephyrproject\zephyr\samples\drivers\lora into your documents folder.
2. copy the .west folder from %HOMEPATH%\zephyrproject into your new receive folder
3. type:

west config --local zephyr.base %HOMEPATH%\zephyrproject\zephyr
west config --local manifest.path %HOMEPATH%\zephyrproject\zephyr

to update the local settings for zephyr in this folder. It should do this.

west config --local -l
manifest.path=\Users\me\zephyrproject\zephyr
manifest.file=west.yml
zephyr.base=\Users\me\zephyrproject\zephyr

Once the local settings point to your global zephyr the app setup is done and a west build in the receive folder

west build -p always -b lora_e5_dev_board .

should run fine (don’t forget that trailing ‘.’ to refer to this folder). Also, the config in the new .west folder is now accurate and doesn’t require changing for future projects if you copy it from here.

Next Post

Next I’ll go through customizing VSCode to make debugging work.