Pull Request Overview

This pull request adds support for the STM32WLE5xx family of chips. Specifically, this adds support for the Seeed Studio LoRa e5 Mini, a development board that uses the STM32WLE5JC. The STM32WLE5xx family of chips is a low power SoC that has an integrated SX126X LoRa radio.

A few Important Notes for Reviewing the PR

SubGhz LoRa Radio Interrupts

The architecture of the stm32wle5xx is somewhat unique as the SubGhz LoRa radio is located on the SoC and the cortex-m4 processor communicates with the radio using an internal SPI bus. SX126X radios (the type of the internal LoRa radio) typically expose an interrupt pin, reset pin, busy pin, and SPI pins. For the stm32wle5xx this is all internally mapped to various registers, NVICs, and EXTI.

This is all important and relevant for how we handle interrupts from the radio. When the radio triggers an interrupt, this results in an NVIC (that is level triggered). This interrupt will remain asserted until the processor sends a SPI command to the radio clearing the radio's internal interrupt.

For our implementation, we use libtock-c support for LoRa and LoRaWAN using RadioLib. To use this, we expose the needed GPIOs/SPI bus to userspace and allow libtock-c to form the needed SPI commands. This creates an issue for the level triggered SubGhz Radio interrupt---the kernel will never exit the service interrupt loop and blocks initiating an upcall to the application/allowing the application to run. Without the application running, the SPI command is not generated/sent to the radio and the radio's interrupt is never cleared.

To fix this, we use interrupt masks when checking for interrupts and manually check if the SubGhz radio interrupt is set after handling all other pending interrupts. This has worked well so far and has not caused issues when testing LoRa/LoRaWAN. I'm open to suggestions if others can think of a more elegant way to implement this.

SubGhz Driver - "Virtual/Logical" GPIOs

As mentioned above, libtock-c has support for LoRa and LoRaWAN using RadioLib. RadioLib expects the radio's interrupt, busy, and data pins to be exposed as GPIOs. This creates issues for the stm32wle5xx as the internal radio maps these behaviors to registers. This issue was thoroughly discussed in RadioLib's bare metal port of the stm32wle5xx here. The solution they use (and what I'm emulating in the Tock port) are "virtual gpios". The chips/stm32wle5xx/src/subghz_radio.rs creates an object that wraps the underlying registers and implements the gpio HIL so that this can be exposed to user space through the standard gpio capsule.

Similarity to STM32f3

There is a high degree of carry over/copying from the STM32f3 chip drivers. This issue was brought up in #4672. It seems some of these drivers can be refactored to a shared directory. This seems like something that should be further discussed once this is merged as this is a larger issue to the STM32 chips in general.

Other Notes / Context

This PR is part of a larger effort to port the Environmental NeTworked Sensing (ENTS) platform to use Tock. ENTS, as the name implies, is a general purpose sensing platform that is already used by environmental scientist at universities across the US. It is in many ways similar to Tock's original roots in the SignPost platform. All this is to say, there will be more contributions coming from and built upon this PR!

Testing Strategy

This pull request was tested by running:

• libtock-c LoRa tx app
• libtock-c blink app
• libtock-c printf testing apps
• libtock-c LoRaWAN app (sending data to The Things Network backend)

TODO or Help Wanted

• Clocks: The clock implementation mostly copies the f4 implementation as this is the most complete of the stm32 chips. The stm32wle series has a somewhat different setup to optimize for low power. The current implementation leaves mostly everything at the default values.

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make prepush.