Design IoT Devices with Microvisor

Microvisor Public Beta

Microvisor is in a pre-release phase and the information contained in this document is subject to change. Some features referenced below may not be fully available until Microvisor’s General Availability (GA) release.

This guide will provide the hardware designer with all the information they need to successfully integrate an STM32U585 microcontroller with Microvisor on board into their own IoT products, whether that’s a new design or an update to an existing product.

Microvisor works with the ST Micro STM32U585 MCU so we recommend that you keep the STM32U585 datasheet nearby while reading this document. We also recommend that you consult the Microvisor Nucleo form-factor development board reference design, which provides a working example of a Microvisor-based product. In particular, use the board’s schematics, Altium and Gerber files , for guidance on designing your own Microvisor hardware.


Hardware architecture

The following diagram illustrates the core components of a typical Microvisor-based IoT product:

The Microvisor hardware architecture

At the device’s center is the STM32U585 MCU. It uses the external flash as a staging area for Microvisor and application updates. Any space beyond the staging area is made available to the application. Connectivity is provided by a cellular module, such as the Quectel EG-21, and/or the Espressif ESP32 WiFi+BLE module. The ESP32 also supports wired network connections, but this will not be available in the Microvisor Public Beta phase. Additional, application-specific hardware is connected through the STM32U585’s GPIO and standard buses (SPI, I2C, I2S, UART).

This represents the initial selection of qualified networking modules. We expect to support further options in due course according to customer demand.

Required hardware

In addition to the STM32U585 MCU, Microvisor-based IoT products will require the following components:

  1. SPI flash of 64Mbit (8MByte) or greater
  2. 32KHz crystal
  3. Cloud communications modules
  4. Tri-color LED

1. 64Mbit SPI flash

An external 64Mbit (8MByte) or greater SPI flash part is mandatory. The address space above 0x600000 (6MByte) is expected to be made available to your application via future Microvisor system calls. The area below this address will be erased and reprogrammed by Microvisor, so applications using pre-programmed SPI flash components must not use any space below this address.

The following SPI flash parts are directly supported:

Part Name Chip ID Voltage Range Quad-read supported
Macronix MX25R6435F C2-28-17 1.8-3.3V Yes
Cypress S25FL064L 01-60-17 2.7-3.3V Yes
Winbond W25Q64JV EF-40-17 2.7-3.3V Yes

Other SPI flash chips should also work with Microvisor, although in 1-bit-wide mode only, provided that they:

  • Are at least 64Mbit (8Mbyte) in size.
  • Support 4, 32 and 64Kbyte erases (commands 0x20, 0x52, 0xD8).
  • Either support deep-power-down using commands 0xB9 (sleep) and 0xAB (wake), or ignore those two commands.

2. 32.768kHz crystal

Add an external crystal connected to the Low-Speed External (LSE) clock source.

The crystal is connected between the STM32U585’s OSC32_IN and OSC32_OUT pins.

The MCU LSE oscillator circuit

The LSE crystal is used to calibrate the High-Speed Internal (HSI) oscillator which drives the CPU core and all peripheral clocks. For this reason, it’s important to ensure the 32kHz oscillator is correctly tuned to be accurate within the crystal specification.

Please see ST Application Note AN2867 for crystal selection and implementation details.

3. Cloud communications modules


Microvisor initially supports the Quectel EG21-G LTE Cat 1 cellular module for mobile connections to the Internet. It has global band support. Microvisor will reserve this module’s networking functionality, and the application must establish cellular Internet communications via Microvisor system calls.

The application will have full access to the EG21-G for GNSS (GPS, GLONASS, BeiDou/Compass, Galileo, and QZSS) operations.

GNSS will not be available in the Microvisor Public Beta phase.

Cellular SIM

In addition to the modem, you will need to incorporate a slot for a card form-factor SIM, or an MFF2 embedded SIM. Microvisor will provide out-of-the-box support for Twilio Super SIM. Other SIMs may also be supported over time according to customer demand.


Microvisor will initially support the Espressif ESP32-WROOM-32E WiFi+BLE module as a communications co-processor for WLAN connections to the Internet. If this module is the device’s primary route to the Internet, Microvisor will reserve its WiFi functionality, and the application must establish WLAN Internet communications via Microvisor system calls. The ESP32 firmware and stack is provided by Microvisor.

The application will have full access to the ESP32 for BLE operations, and full access to the WiFi subsystem for local networking.

BLE will not be available in the Microvisor Public Beta phase.


The Espressif ESP32 module also provides Ethernet support. If this is to be the device’s primary route to the Internet, Microvisor will reserve its Ethernet functionality, and the application must establish Internet communications via Microvisor system calls. The ESP32 firmware and stack is provided by Microvisor.

The application will also have full access to the Ethernet subsystem for local networking.

Device provisioning

Devices which offer WiFi connectivity will need at some point to be provisioned with local WiFi network credentials. The ESP32 WiFi module supported by Microvisor also incorporates BLE functionality, and it is expected that your application will use BLE to receive WiFi credentials and other setup information, such as HTTP proxy settings or static network configuration, from a companion mobile app.

This provisioning functionality is not provided by Microvisor itself, but your application will need to pass WiFi settings to Microvisor so that it can enable Internet connectivity via WiFi. This will be done through a Microvisor system call.

4. Tri-color LED

Microvisor requires the inclusion of a tri-color (red, green, and blue) LED. It is used to indicate different device and network connection states. Situations such as the device’s external SPI flash being inaccessible at start-up, or Microvisor can’t connect to WiFi using stored credentials, will be signalled with a sequence of colours blinked on the LED.

The tri-color LED circuit

Recommended hardware

In addition to the mandatory hardware components, we recommend you incorporate the following components and sub-systems in your design.

Reset button

To provide users with a reset button, connect the STM32U585’s NRST pin to a switch which will connect NRST to GND when pressed. In the reference design, for example, RESET_L connects to NRST:

Microvisor reference design reset switch

At this time, reset behavior is undefined.


STM32U585 GPIO pin PC6 is reserved for the Microvisor Rescue pin. We intended to provide a mechanism to allow, say, a button connected to this pin to be used to recover devices from undefined states during development, or to bypass certain functionality during the start up of production devices. At this time, the Rescue pin behavior has yet to be defined.

On the Microvisor Nucleo Development Board this is connected to VDD via header W6.

The STM32U585 MCU

Microvisor supports the STMicro STM32U585 MCU, a new MCU that supports the ARMv8-M architecture’s TrustZone technology. TrustZone establishes two separate operating domains: the ‘trusted’ Secure World (SW) and the ‘untrusted’ Non-secure World (NSW). Microvisor is pre-installed on pre-release hardware and operates within the privileged Secure World; your application will be stored in and run from the Non-secure World. TrustZone completely isolates the two domains, each of which has its own Memory Protection Unit (MPU), Nested Vector Interrupt Controller (NVIC), and Direct Memory Access (DMA) controller.

Every application has complete access to all of the host device’s hardware resources with the exception of cloud-facing network interfaces and a handful of the STM32U585’s peripherals (see below). The application can access the unreserved peripherals at the memory locations detailed in the STM32U585 datasheet, or by calling functions provided by a hardware abstraction layer (HAL) library.

Applications can rely on Microvisor to provide the secure cloud tunnel, or operate through a virtual network interface provided by Microvisor.

Applications which use network interfaces that are not cloud facing — for example, ZigBee or LoRA gateway products — are totally in control of those interfaces. Microvisor has no access to them.

STM32U585 reserved peripherals

Microvisor reserves the following STM32U585 peripherals:

STM32U585 Peripheral Reserved For
RCC The STM32U585’s reset and clock controller
RNG, AES, SAES, HASH, PKA The STM32U585’s true random-number generator, used to make secure TLS network connections and for other security functions
RTC The STM32U585’s real-time clock. Microvisor owns the RTC, because it has to control when and whether the STM32U585 enters the deep-sleep Standby mode
TIM3 The System LED PWM timer
TIM5 The Microvisor system timer
PWR The STM32U585’s power controller
OCTOSPI1, OCTOSPIM The STM32U585’s interface to the external QSPI, used to securely store upgrade Bundles
OTG_FS, LPUART1 Used for communications with the cellular modem
SDMMC1, UART5 Used for communications with the WiFi+BLE module
DCMI The digital camera interface. This is currently reserved by Microvisor but may become free in a future update

STM32U585 pinout

The STM32U585 is expected to be made available in LQFP100, UFBGA132, and LQFP144 packages. Please see the STM32U585 datasheet for pinout and ballout schematics.

All pins default to tristate high impedance (floating) at power up and while the STM32U585 is in low power deep sleep.

STM32U585 reserved pins

Microvisor reserves a number of STM32U585 pins for essential system usage, i.e., to enable the peripherals described above. These pins include:

  • PA4, PD4, PC0, PC2, PC3, PE10 — connection to the QSPI flash.
  • PC8-PC12, PD2 — SDIO connection to the WiFi+BLE module.
  • PA11, PA12, PE7 — USB connection to the cellular module.
  • PG3-PG8UART5 connection to the cellular module.
  • PE8 — cellular modem RING.
  • PD14 — cellular module power enable.
  • PD15 — WiFi+BLE module power enable.
  • PC6 — Rescue pin
  • PE3, PE5, PE6Tri-color LED.

For 3V3 applications alternate GPIO pins can be used for the cellular UART: PA6, PA15, PB1, PB10, PC1, PC7.

For development devices — but not production devices — the following pins will be reserved:

  • PE4, PB0 — Setup UART.

The pin names listed above are those of the LQFP144 package. These pin reservations will be updated in due course for other STMU585 packages as they are verified.