STM32 Microcontroller Development
From STM32L4 ultra-low-power sensor nodes to STM32H7 high-performance acquisition — production-grade firmware across the full STM32 family.
What We Build on This Platform
STM32H7 High-Performance
Cortex-M7 at 480MHz, DMA2D, JPEG, Ethernet, and FSMC for complex real-time signal acquisition and display applications.
STM32L4/L5 Ultra-Low-Power
Sub-3µA stop mode, hardware ADC, OPAMP, and DAC for precision battery-powered measurement over multi-year deployments.
STM32U5 Secure IoT
TrustZone-M33, AES, PKA, and OTFDEC for secure connected device applications requiring on-device cryptography.
STM32G4 Mixed-Signal
HRTIM, OPAMP, comparator, and DAC for motor control and power electronics firmware requiring 184ps timing resolution.
STM32WB Wireless
BLE 5.0 and 802.15.4 co-processor with Cortex-M4/M0+ dual-core for wireless-connected products.
STM32WL LoRa
Integrated LoRa radio and Cortex-M4 for LoRaWAN end device without an external radio module.
DMA Architecture
Multi-stream DMA with MDMA and BDMA for zero-CPU peripheral transfer across the STM32H7's D1/D2/D3 power domains.
STM32 HAL and LL
HAL driver selection and LL direct register access for performance-critical paths where HAL overhead is unacceptable.
How Ankh Uses This Platform
STM32 Family and Variant Selection
Family selected from specific requirements: STM32L4 for multi-year battery from primary cell; STM32H7 for >100MFLOPS DSP or high-speed memory interface; STM32G4 for motor control with HRTIM; STM32U5 for TrustZone with low power; STM32WB/WL for integrated wireless. Variant selected by flash size, RAM, package, and peripheral count.
STM32CubeMX Configuration
Pin assignment, peripheral initialisation code generation, clock tree configuration for target clock speeds on each bus domain, DMA stream and channel assignment, and NVIC priority assignment from the real-time requirement. CubeMX-generated code used as the starting point with selective replacement of HAL calls with LL where HAL abstraction cost is unacceptable.
DMA Architecture
DMA stream assignment for all data-intensive peripherals: ADC multi-channel DMA for simultaneous acquisition, SPI DMA for high-speed peripheral communication, UART DMA with circular buffer for continuous receive. MDMA configured for the STM32H7's cross-domain memory transfers. BDMA for peripherals in the D3 power domain that must function in low-power modes.
Power Management
Stop modes, standby modes, and shutdown configured with RTC wake for the specific duty cycle. LPTIM wake from stop mode for periodic sensor read. Shutdown current measured on prototype hardware. Comparison against the power budget from battery capacity and deployment lifetime requirement.
Production and Debug
SWD programming and debug with J-Link, ST-LINK, and OpenOCD. ITM trace output via SWO. STM32 option bytes configured for read protection, secure boot, and JTAG disable in production. Production programming via SWD with ST's programming tools or third-party ICT fixtures.
Deep Technical Capability
STM32H7 DMA2D and Hardware-Accelerated Display Rendering
The STM32H7's DMA2D (Chrom-ART Accelerator) is a hardware 2D graphics DMA that performs colour fill, bitmap copy, colour conversion, and alpha blending without CPU involvement — enabling LVGL or TouchGFX to achieve 60fps rendering at 800×480 on an external TFT display without the CPU render loop that limits software rendering to 12–20fps on the same display. Effective use of DMA2D requires correct framebuffer placement (SDRAM for large buffers, DTCM for the internal framebuffer), correct DMA2D transfer mode configuration for the source and destination pixel format, and VSYNC synchronisation to prevent screen tearing. Ankh configures DMA2D as the primary render path for all STM32H7-based display products — measuring frame rate and CPU utilisation before and after DMA2D offload to verify the improvement and identify remaining software bottlenecks.
STM32L4 Ultra-Low-Power Design from the Register Level
The STM32L4's datasheet specifies stop mode current as low as 0.8µA with the RTC running — but achieving this in real firmware requires correct configuration of every peripheral's clock gate, correct GPIO configuration for all unused pins in analogue mode rather than floating input, correct LPTIM configuration for the RTC wake, and correct suppression of the MSI clock glitch that occurs on stop mode exit when the system clock source switches back. The run mode current is equally sensitive to peripheral clock enable status — a peripheral whose clock remains enabled in stop mode consumes its quiescent current throughout the sleep period. Ankh measures the STM32L4 stop mode current on prototype hardware using a precision current analyser, compares against the datasheet minimum, and identifies which peripheral clock gates or GPIO configurations are preventing the design from achieving the datasheet stop mode current floor.
STM32G4 HRTIM for High-Resolution Motor Control and Power Electronics
The STM32G4's HRTIM provides 184ps timing resolution at 5.44GHz equivalent from the clock multiplier — enabling PWM frequency and dead-time precision essential for GaN transistor gate drive in bridgeless PFC, LLC resonant conversion, and direct torque control motor drives. The HRTIM's output cross-bar allows any output signal to be routed to any output pin, enabling flexible PWM generation for different bridge topologies without PCB rewiring. Fault input conditioning on the HRTIM produces a sub-100ns response from fault detection to PWM output shutdown — critical for protecting wide-bandgap power devices whose thermal time constant is shorter than the interrupt response time of a standard timer. Ankh designs HRTIM configurations for specific power topology requirements, characterising dead-time, fault response time, and PWM frequency accuracy on prototype hardware before committing the design to a power stage.
Products Built on This Platform
Data Loggers
STM32H7 for 24-bit multi-channel simultaneous ADC with DMA and hardware AES for tamper-evident storage.
View ProductCold Chain Monitoring
STM32L4 for ultra-low-power temperature logger at 47µW average on 5-year primary battery.
View ProductPower Monitoring
STM32G4 for HRTIM-based power quality measurement and 3-phase energy metering.
View ProductPatient Safety
STM32L4 for fall detection wearable with sub-30g total form factor and 5-day battery.
View ProductPOS & Kiosk Hardware
STM32H5 with TrustZone for PCI PTS payment terminal secure element and key storage.
View ProductStructural Monitoring
STM32H7 for GPS PPS hardware timer capture and simultaneous 64-channel ADC acquisition.
View ProductHAL is a starting point, not a final firmware
The STM32 HAL provides a consistent peripheral interface across the family at the cost of runtime overhead from generic error checking, state machine management, and callback dispatch. For a UART at 115200 baud transmitting 20 bytes every 100ms, HAL overhead is negligible. For a SPI at 45Mbps transferring 4096 bytes to an ADC at 500ksps, the HAL callback dispatch overhead in the transfer complete ISR is 1.2µs — which represents 54 missed ADC samples. Ankh adopts HAL for peripheral initialisation and selects LL direct register access for the performance-critical data path in any STM32 application where the HAL overhead represents a significant fraction of the available timing budget.
Clock tree configuration determines every peripheral's performance
The STM32H7's clock tree feeds the Cortex-M7 core, AHB buses, APB buses, ADC clock, SPI clock, and USART clock from a configurable PLL hierarchy. Incorrect clock tree configuration produces ADC measurements with unexpected sample rate because the ADC clock divider was configured for the wrong bus frequency, SPI communication failures because the SPI clock exceeds the peripheral's maximum, or USB enumeration failures because the USB 48MHz clock is not correctly derived from the PLL. Ankh configures the STM32 clock tree from first principles — calculating every bus frequency from the PLL configuration, verifying every peripheral's clock against its datasheet maximum, and measuring output frequencies on prototype hardware before any peripheral is exercised.
Option bytes define the production device's security posture
The STM32's option bytes control read-out protection (RDP level 0: JTAG open, level 1: flash read protected, level 2: permanent JTAG disable), secure boot configuration on STM32U5, watchdog hardware versus software selection, and BOR threshold. A production device shipped with RDP level 0 has its firmware extractable by any engineer with a JTAG adapter. Ankh defines the production option byte configuration at the beginning of every STM32 firmware development programme and includes option byte programming in the production test procedure — so every production unit leaves the factory with the correct security configuration, not with the development configuration.