Microvisor Private Beta
Microvisor is in a pre-release phase and the information contained in this document is therefore provisional and subject to change. Some features referenced below may not yet be available in or supported by the current version of the Microvisor system calls or REST API.
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.
Until the Microvisor Public Beta, this document will focus on giving designers an understanding of how they might begin work on such products and the support components it will require when they do. Microvisor is still in development, and you should expect significant changes to be made before the Public Beta phase. Please check the Document History to ensure you stay up to date.
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.
The following diagram illustrates the core components of a Microvisor-based IoT product:
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 early beta phases. 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.
In addition to the STM32U585 MCU, Microvisor-based IoT products will require the following components:
An external 64Mbit (8Mbyte) or greater SPI flash part is mandatory. This will be used to stage application and system updates. The address space above
0x400000 (4096Kbyte) (TBC) can be used by your application via Microvisor system calls. Areas below this address will be erased and reprogrammed by Microvisor, so applications using pre-programmed SPI flash components must not use space below this address.
For Private Beta we expect to support 8Mbyte Flash. Larger capacities may work, but only 8Mbyte will be visible. We hope to extend the supported size to 16Mbyte for the Public Beta, and support for larger sizes following later. However, this schedule is tentative and may be subject to revision.
The following SPI flash parts are directly supported:
|Part Name||Chip ID||Voltage Range||Quad-read supported|
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
- Either support deep-power-down using commands
0xAB(wake), or ignore those two commands.
Add an external crystal connected to the Low-Speed External (LSE) clock source.
The crystal is connected between the STM32U585’s
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.
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 early beta release phases.
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.
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.
WiFi and BLE will not be available in the Microvisor early beta release phases.
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.
Ethernet will not be available in the Microvisor early beta release phases.
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.
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.
In addition to the mandatory hardware components, we recommend you incorporate the following components and sub-systems in your design.
To provide users with a reset button, connect the STM32U585’s
NRST pin to a switch which will connect
GND when pressed. In the reference design, for example,
RESET_L connects to
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.
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.
Microvisor reserves the following STM32U585 peripherals:
|STM32U585 Peripheral||Reserved For|
||The STM32U585’s reset and clock controller|
||The STM32U585’s true random-number generator, used to make secure TLS network connections and for other security functions|
||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|
||The System LED PWM timer|
||The Microvisor system timer|
||The STM32U585’s power controller|
||The STM32U585’s interface to the external QSPI, used to securely store upgrade Bundles|
||Used for communications with the cellular modem|
||Used for communications with the WiFi+BLE module|
||The digital camera interface. This is currently reserved by Microvisor but may become free in a future update|
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.
Microvisor reserves a number of STM32U585 pins for essential system usage, i.e., to enable the peripherals described above. These pins include:
PE10— connection to the QSPI flash.
PD2— SDIO connection to the WiFi+BLE module.
PE7— USB connection to the cellular module.
UART5connection to the cellular module.
PE8— cellular modem
PD14— cellular module power enable.
PD15— WiFi+BLE module power enable.
PC6— Rescue pin
PE6— Tri-color LED.
For 3V3 applications alternate GPIO pins can be used for the cellular UART:
For development devices — but not production devices — the following pins will be reserved:
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.
• STM32U585 datasheet
• Espressif ESP32 WROOM-32E datasheet
• Microchip LAN8720A Ethernet PHY datasheet
• Bel Stewart SI-50170-F Ethernet connector datasheet
• Nexperia 74LVC1G175GW single flip-flop datasheet
Access to STMicro documentation may require signing in to the STMicro website.