Get Started with the Microvisor Nucleo Development Board
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.
The Twilio Microvisor Nucleo Development Board (NDB) is a complete evaluation and development platform for Twilio Microvisor and the STMicroelectronics STM32U585 microcontroller. It is based on the familiar STMicroelectronics Nucleo form-factor. You will use it to explore the Microvisor platform, and to develop and prototype your IoT applications.
This Quick Start Guide will help you get your NDB powered, connected, and running a sample application that you will deploy to the board over the air via the Twilio cloud.
New to Microvisor?
Take a moment to learn what Microvisor is all about, its ARM TrustZone-based secure architecture, and the benefits it will bring to your IoT application.
What’s in the box?
Your NDB, which has been pre-registered with your Twilio account, comes with the following items:
- A USB-C cable to power the NDB.
- A USB AC power adapter.
- A Quectel EG21-G global cellular module PCIe card.
- A cellular antenna and connector cable.
- A Twilio Super SIM.
- A Micro-USB cable for provisioning WiFi credentials.
The supplied AC adapter is optional, but do not run the Nucleo board from a USB port on your computer if it is not able to deliver at least 15W (3A at 5V) peak. The Nucleo board draws more power than some older computers’ USB ports are usually able to deliver.
You will also need a Twilio account. Sign up now if you don’t have one.
Microvisor currently supports only Super SIM for cellular connectivity. We expect to enable support for other SIMs in a future release.
Super SIM setup
Your NDB comes with a Twilio Super SIM that has been set up for you to provide you with global cellular connectivity. The SIM has already been fitted into your board, so you are ready to go.
- Unpack the cellular modem card and fit its connector into the slot on the NDB:
- Push the card gently down onto the board until the two restraining clips snap to hold it firmly in place:
- Fit the antenna cable’s female u.FL connector to the male connector on the modem card marked MAIN:
- Screw the large antenna onto the board’s jack:
- Remove the nano-size SIM card from the Super SIM packaging and slot it into the receptacle on the NDB. The contacts should be face down, and the edge with the notch inserted first. This may have been done for you:
See the note below if you are only using WiFi and/or Ethernet.
- Plug in the AC adapter and use the USB-C cable to power the NDB:
If you are using the NDB in WiFi or Ethernet mode — you’re not using its cellular functionality — you will still need to fit the supplied modem card for the time being. However, you should not install the Super SIM. If a SIM has been fitted into your board for you, please remove it.
Do not try to power the NDB through the Micro USB port marked CONTROL (or DEBUG on older boards), depending on the board revision. This connector is not able to deliver power to the board.
On your first power up, if you are connecting via cellular, it can take the modem a significant amount of time — 10 minutes or more — to attach to the network. See below for the signals shown on the NETLIGHT LED.
The Microvisor application development process goes like this. You will use your computer to build new versions of your application. You run each new build through Microvisor’s bundle creation tool to generate the file that will be uploaded to the Twilio Cloud from where it will be deployed to the device or devices that you specify, such as your NDB, at a time you choose.
At this stage in Microvisor’s release schedule, we support Ubuntu 20.04 LTS Linux as a primary development environment. While we hope to support other platforms in due course, for now Windows and macOS users will have to choose between interacting with the Microvisor development tools through Docker or from within a virtual machine running Ubuntu.
The Twilio CLI is cross-platform, so macOS and Windows users require Docker or a VM solely for the build process. Ubuntu-specific steps are marked as such when they come up.
If you’re willing to take a risk, and are happy not to be supported, you can try the tools on some unsupported platforms.
The first thing to do is set up your computer for Microvisor application development.
1. Install the prerequisites
Ignore this step if you are using Docker.
sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi \ build-essential libsecret-1-dev cmake curl git jq
2. Install the Twilio CLI
To install and set up the Twilio CLI on your development machine, please jump to the Twilio CLI Quickstart and then return here when you’re done.
If you already have the Twilio CLI installed, take this opportunity to update it to the latest version. You’ll need version 4.0.1 or above to follow this guide.
3. Install the Microvisor plugin
twilio plugins:install @twilio/plugin-microvisor
4. Sign in to Twilio
twilio login. You will be asked for your account SID and your account Auth Token, both of which you can call up from the Console if you don’t have them handy. Do keep them nearby — you’ll need them in the next section. You will also be prompted to enter a ‘shorthand identifier’, a local ID for your credentials. Enter your initials or any phrase you prefer.
If the Twilio CLI later fails and claims you have set no profile, run this command, substituting your profile name for the placeholder:
twilio profiles:use <YOUR_PROFILE_NAME>
5. Download the Microvisor FreeRTOS Demo
git clone --recurse-submodules https://github.com/twilio/twilio-microvisor-freertos cd twilio-microvisor-freertos
If you are using our Docker workflow on an architecture other than x86/amd64 — such as a Mac with Apple silicon — then you will need to override the platform when running Docker:
This is needed for the twilio-cli apt package which is x86 only at this time.
Get to know your board
Before you build your first application, let’s go on a quick tour of the NDB’s key features:
- GPIO header.
- Antenna jack.
- Reset button.
- Network activity LED.
- Power brownout LED.
- Application-controllable LED.
- STM32U585 with Microvisor.
- Quectel EG21-G global cellular modem.
- USB-C power input.
- System LED
- Twilio Super SIM.
- ESP32 WiFi/BLE module.
- RJ-45 Ethernet jack.
- UART control port.
The NDB has three LEDs, marked with the labels listed below, to provide you with status feedback:
- SYSTEM — This indicator signals system status using patterns of colors and flashes. For example, it slowly flashes green when the board is connected. The more commonly encountered patterns are shown below.
It’s important to understand that a pattern may take longer to complete than the time Microvisor spends in the indicated state. As soon as it moves to another state, Microvisor will signal the new state, even if it has not yet finished the previous state’s pattern. This means that you should watch this LED for error or success conditions — a pattern being displayed repeatedly without change — not to observe transient states.
- USER — This is a GPIO connected single-color LED that’s just for you and your application. It is connected to the STM32U585’s GPIO pin PA5. Set this pin high to turn on the LED. You’ll see this in operation in the sample application you’ll deploy shortly:
- NETLIGHT — This is the modem’s network activity indicator. You can see it in the picture below. This LED will blink slowly while the device is idling (long flash) or searching for the network (short flash), and blink rapidly during data transfer.
- BROWNOUT — This will light when the modem’s power draw has exceeded the power supplied to the board. You will usually see this happen when you are powering the board with your own AC adapter and it is not delivering sufficient power. Make sure your adapter delivers at least 15W (3A at 5V). The adapter and cable supplied with the NDB is rated to meet the peak power draw of the board and modem, so we recommend you use this in place of your own.
All of the STM32U585’s GPIO pins that are available to the user are broken out through the NDB’s two headers, marked CN11 and CN12. Any pins not present are reserved for Microvisor’s use both on this board and on customer implementations. Please see the STM32U585 data sheet for the functionality enabled at each pin. The headers are connected as follows (click on the image for a large view):
NC = Not Connected
CN11 pin 33 is not connected, but bridging W1 will connect it to VDD BAT IN.
You can manually trigger a device reboot at any time by pushing the RESET button:
Common SYSTEM LED patterns
The table below shows you some color and blink patterns that you may see on the SYSTEM LED. The first six of these signal the NDB’s progress as it comes online. This usually happens quite quickly so you may not see all of them before you see the steady green blink that indicates the NDB is online. The NETLIGHT LED will blink rapidly at this point.
If you do not see the even green blink, match the pattern you do see to those listed above. It will tell you how far the NDB progressed and the likely cause of its failure to connect. For example, if you see the Waiting for SIM pattern, you know to check that the board’s Super SIM has been inserted fully and correctly. A pattern further down the list might indicate a broken antenna connection.
If everything seems slotted correctly, and you’re still not connected — you‘ll see the Checking PPP Connection pattern — you may not have cellular connectivity where you are. Try moving the device to an alternative location. But don’t forget, Twilio Support is ready to assist.
The NDB incorporates an ESP32 WiFi/BLE module and Ethernet jack. These features can be used by the NDB to connect to the Internet in place of the cellular modem. This takes place automatically at power on:
- For Ethernet, connect an RJ-45 cable between your NDB and your router, then connect the NDB to power.
- For WiFi, add your wireless network’s credentials to the board (see below) and then power-cycle the NDB.
When it is re-booted, Microvisor will attempt to connect to the Internet in this order:
- With Ethernet if it is wired up to an active network.
- With WiFi if it is configured with credentials and the specified network can be found.
- Cellular via Super SIM.
As soon as a connection is made, no other devices are used. For example, if Ethernet is not connected, Microvisor will attempt to connect by WiFi. If it succeeds, it will not attempt to connect by cellular.
To configure your NDB’s WiFi credentials, follow these steps:
- Connect the supplied Micro-USB cable to your computer and to the NDB’s CONTROL port. If you use your own Micro USB cable, make sure it is data-capable, not power only.
- Press RESET on the NDB.
- The NDB’s SYSTEM LED will turn solid blue, and no application code will be run:
- Open a terminal and run:
This will give you a list of serial ports. You will likely see
/dev/ttyACM0, depending on your hardware. We’ll assume the latter; just substitute in the commands below the device that you see.
- To set your WiFi credentials run the following command, substituting your own values for the placeholders:
twilio microvisor:wificonfig:set '<YOUR_SSID>' '<YOUR_PASSPHRASE>' /dev/ttyACM0
- You can check the saved credentials with:
twilio microvisor:wificonfig:get /dev/ttyACM0
Note that this will display your credentials in the terminal.
- Remove the Micro-USB cable from the NDB and power-cycle the board. At this time, a full power-cycle is required: pressing RESET will not move the board out of provisioning mode.
Let’s build and deploy a classic ‘Hello, World’ application so you can see how you interact with the software you’ve just installed and your newly connected NDB. You’ll use the FreeRTOS demo code that you just installed. It flashes the NDB’s USER LED to signal its presence.
1. Build and bundle the application code
Switch to the
twilio-microvisor-freertos directory if you’re not already in it.
If you’re working at the command line, natively or in a VM, run:
cmake -S . -B build cmake --build build
Applications are delivered to the Twilio cloud in the form of a ‘bundle’. This is a zip archive which contains a combination of executable code and data. It also includes a manifest, a signed metadata file which tells Microvisor where to install the code and the data. Build a basic bundle now:
twilio microvisor:apps:bundle build/Demo/gpio_toggle_demo.bin \ build/Demo/gpio_toggle_demo.zip
If you’re using Docker, create a container with:
docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) \ -t microvisor-gpio-sample-image .
Now run the container to build and bundle the Microvisor demo app:
docker run -it --rm -v $(pwd)/:/home/mvisor/project/ \ --name microvisor-gpio-sample microvisor-gpio-sample-image
2. Upload the bundle to the Twilio Cloud
However you generated the bundle in the previous step, upload it to Twilio with this command:
twilio microvisor:apps:create build/Demo/gpio_toggle_demo.zip
Uploaded bundles are accessed through the Microvisor Apps API, which represents each bundle upload as an App resource. Apps are uniquely identifiable by their SID. This allows you to quickly re-deploy an older version of your code if you need to.
You’ll need the new App’s SID. To retrieve it, run:
Make a note of the new App’s SID in the JSON response to the command you just issued. It’s a 34-character string beginning with
KA. The JSON also includes the code’s SHA-256 and the hash value that Microvisor uses to ensure the integrity of Apps it downloads.
To make it easier to identify a specific upload, give it a unique friendly name:
twilio microvisor:apps:create /path/to/bundle <UNIQUE_NAME>
You can use the App’s name instead of its SID in Step 4, ‘NDB, meet application’, below.
3. Get your NDB’s SID
Next, you need to determine the SID of the board itself. You’ll need this to instruct Twilio which device to deploy the uploaded bundle to. First, get a list all of your devices:
This will list your devices — possibly just your Nucleo at this stage — with their SIDs and, if set, unique names.
The QR code on the back of your board and on the anti-static bag in which it shipped also contains your NDB’s SID. Scan the code with your mobile phone and a suitable app, and the board’s SID is the third
4. NDB, meet application
Now ensure your NDB is powered up and connected to the Internet — the SYSTEM LED will be slowly blinking green — and deploy the code to it. To so, make a Microvisor API request like this:
twilio api:microvisor:v1:devices:update \ --sid <YOUR_NDB_SID> \ --target-app <YOUR_APP_SID_OR_NAME>
Again, you’ll need to replace the bracketed values with your own values.
You can avoid using the bulky SID by giving your device a friendly unique name:
twilio api:microvisor:v1:devices:update \ --sid <YOUR_NDB_SID> \ --unique-name my_ndb
Use the unique name wherever you’re asked to enter a device SID.
Twilio will signal the device that that an application update is pending, and Microvisor will reboot, reconnect to the Internet, and download your code. After a moment or two, while the NDB connects to the Internet, you’ll see the USER LED flash once a second.
5. Gather some logs
Microvisor supports the relay of logging statements issued by your application code. To view logs from your device, you’ll use the Twilio CLI. If you didn’t run
twilio login when you installed the tool earlier, do so now. Then you can run:
twilio microvisor:logs:stream <YOUR_NDB_SID>
Sit back and watch some messages appear in your terminal.
How does it work? Logging leverages standard Microvisor system calls for application logging.
Change Apps and deployments
If you make changes to the code, aren’t happy with results, and want to revert to an earlier version, use
twilio to list your Apps, find the SID or the unique name of the version you want to redeploy, and then use
twilio to send it to your NDB:
# Get a list of apps twilio api:microvisor:v1:apps:list # Update the target twilio api:microvisor:v1:devices \ --sid <YOUR_DEVICE_SID_OR_UNIQUE_NAME> \ --target-app <THE_ROLLBACK_APP_SID_OR_UNIQUE_NAME>
Delete unwanted Apps
You can delete unwanted App uploads with:
twilio api:microvisor:v1:apps:remove --sid <AN_APP_SID_OR_UNIQUE_NAME>
But you should note that you cannot delete an App which is currently deployed to one or more devices. To fully delete an App, deploy another one to your device(s) first.
You have set up your development environment and your Microvisor Development Board. You’ve run a FreeRTOS-based sample application on the device by creating a bundle, transferring it to the Twilio cloud, and then deploying it to your board over the air. You have viewed logging information transmitted by your application.
What next? Microvisor now supports remote debugging: controlling running application on your Microvisor device wherever in the world it is located. To try out this powerful development functionality, work through our Microvisor Remote Debugging guide.
Here are some suggestions for further stages of your Microvisor journey.
- Build some of our demo applications to learn how to integrate specific technologies into your own Microvisor code.
- Get some further guidance on developing applications for Microvisor.
- Check out the functionality Microvisor can provide to your application through its system calls.
- Review STMicro’s STM32U585 Reference Manual and HAL documentation.
- Is designing hardware your focus? If so, find out how to design Microvisor-empowered IoT devices.
- Read about the Microvisor API you use to interact with the Twilio cloud.
We can’t wait to see what you build with Microvisor and the Nucleo Development Board. Make sure you let us know through one of the feedback channels discussed with you!
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.