Microcontroller (MCU) development boards are widely used for many Internet of Things (IoT) applications. They are compact, powerful and highly versatile with a wide range of I/O capabilities. The PJRC Teensy3.X family of products are highly capable and very popular. These were some of the first MCU development boards that brought transformative performance to the IoT Maker community in small form factor and at a reasonable price. Tlera Corporation offers a family of MCU development boards that were initially inspired by the Teensy3.2 but are based upon ST Microelectronics' STM32L4 microcontroller.
The STM32L4 is an 80MHz ARM Cortex M4 microcontroller with an embedded floating point unit and a very rich I/O portfolio. Like the Teensy3.X family, Tlera's MCU development boards are supported by a mature Arduino core for easy application development. The differentiating advantage of the Tlera STM32L4-based MCU boards is low power sleep capability. State-preserving sleep modes can be easily implemented using the Arduino IDE and typically result in ~1.6uA current consumption. The STM32L4 can be woken up by either an external interrupt or periodically by using the internal RTC.
The combination of ample numerical processing speed, rich I/O capability, very low power sleep states and Arduino IDE support make the STM32L4 an excellent choice for developing battery-powered remote sensing devices. However, one critical limitation has persisted: No integrated wireless connectivity. In order to address this need, Tlera Corp. now offers an nRF5282 BLE board to bring wireless connectivity to your favorite MCU boards:
This add-on product was specifically designed to plug directly into the Tlera "Dragonfly" and "Butterfly" MCU development boards and is also pinout compatible with the Teensy3.X family of products. The nRF5282 add-on board shares 3.3V power and ground connections with the MCU board. The UART serial Tx and Rx lines are connected in null modem configuration. An indicator pin is also available to connect with a digital input on the MCU board. When the nRF5282 pairs with another suitable BLE device, the "IND" node of the add-on board is pulled low. This feature is helpful to notify the MCU that there is a BLE connection before attempting to send data to the paired device.
Physical mounting of the add-on board to the MCU development board is straightforward. Dragonfly/Butterfly:
Teensy 3.1/3.2:
Teensy 3.5/3.6:
Machine pin headers are convenient to mate the add-on board with the MCU development board. In all cases (Dragonfly, Butterfly, Teensy 3.1/3.2 and Teensy 3.5/3.6) the location of the add-on board with respect to the MCU's USB connector (on the right) is identical. The BLE antenna consists of simple 1.2" wire segment
The add-on boards can be flashed to act as either a Peripheral or Central role BLE Nordic UART Service (NUS) device. The NUS characteristic turns out to be extremely useful for enabling BLE wireless connectivity; it acts as a simple BLE-UART bridge. If the nRF52832 receives data from a paired BLE NUS device, it simply relays that data to the MCU over a UART port. Conversely, data written from the MCU to the nRF52832 over the UART port is sent immediately to the paired BLE NUS device. So one could think of the NUS as a virtual "BLE Serial extension cable" connecting two UART ports...
There are a number of NUS BLE Central role applications for smart devices such as cell phones and tablet computers. It is simple to use the nRF5282 add-on in Peripheral role to stream serial data from an MCU to a Central role smart device. However, it has proven to be much harder to establish BLE connectivity between a remote MCU device and a PC. This problem can be easily solved by using a second MCU development board and a Central role nRF5282 add-on:
- A serial bridge is made between the remote MCU device and a Peripheral role nRF5282 add-on
- A second serial bridge is made between a second MCU device and a Central role nRF5282 add-on. We'll call this second MCU the gateway
- The Central and Peripheral role add-ons pair and can exchange data between the gateway and remote MCU's
- Internal to the gateway MCU's programming, data exchanged to/from the BLE/UART bridge is passed from/to the gateway MCU's USB serial port and is available to any kind of serial terminal application on the PC
Having a BLE serial link between a remote MCU device and a PC opens up another exciting possibility: Over-The-Air (OTA) firmware updates for the remote MCU device. The BLE serial connection described above is bi-directional so there is no reason in principle why new firmware information can't be sent to a remote MCU. The Tlera MCU development boards support byte-by-byte writing of a new firmware image from an Arduino sketch directly to the STM32L4's native flash memory. Once the new firmware image is completely written, a soft reset activates it. Using a Tlera Dragonfly board as the gateway MCU makes this process even easier. It is equipped with a 128Mbit QSPI flash chip that is mountable as a virtual disk drive. New MCU firmware can be built with the Arduino IDE, drag-and-drop copied to the Dragonfly's QSPI flash memory and transmitted to the remote MCU over the BLE NUS connection.
The example Arduino sketches in this repository include the necessary infrastructure to perform OTA firmware updates. Data is read from the Firmware image file on the gateway MCU and transferred over the BLE NUS link to the remote device in 32byte blocks. A variation of the MultiWii Serial Protocol (MSP) is used to packetize and decode the firmware image data. MSP has reasonably good packet integrity to protect against data corruption. Block-to-block handshaking, byte counting and limited error recovery have been implemented to ensure that the complete image is received. Transfer times of 2-10min for a complete firmware image are typical.
OTA firmware update is fully functional for STL32L4-based devices but not for Teensy3.X products. At the time of writing this wiki, there is no known method for transferring firmware image data from an Arduino sketch to the bootable portion of the Teensy MCU's flash memory. If this capability were to be developed OTA firmware updates would be possible for the Teensy3.X products as well.
- Select your MCU board (Dragonfly, Butterfly or Teensy3.X)
- Get a Tlera nRF5282 add-on board flashed for Peripheral role. (The add-on boards can be purchased with either Peripheral or Central role firmware pre-flashed)
- Connect the add-on board to the MCU board as shown in the photos above
- Make sure that you have the proper version of Arduino and the correct core/libraries installed for either the Tlera STM32L4 or Teensy3.X MCU board you have selected
- Compile and upload the appropriate remote MCU test sketch for your board
- If you have a smart phone or tablet with a BLE NUS terminal application, connect to your MCU and watch the remote data stream! When the NUS connection is active, the blue LED on the add-on board will come on steadily
- If you want to use a gateway MCU to stream the remote data to your PC, go to the next section...
- Select your MCU board (Dragonfly, Butterfly or Teensy3.X). If you want to do OTA firmware updates on a remote STM32L4 device, we recommend using the Tlera Dragonfly since it has built-in drag-and-drop access to mass memory
- Get a Tlera nRF5282 add-on board flashed for Central role. (The add-on boards can be purchased with either Peripheral or Central role firmware pre-flashed)
- Connect the add-on board to the MCU board as shown in the photos above
- Make sure that you have the proper version of Arduino and the correct core/libraries installed for either the Tlera STM32L4 or Teensy3.X MCU board you have selected
- Compile and upload the appropriate gateway MCU test sketch for your board
- Power-cycle the gateway MCU/add-on board pair and open a USB serial monitor
- Power up a BLE-enabled remote MCU; you should see connection information posted to the gateway MCU's USB serial monitor during the pairing process. When the NUS connection is active the blue LED's on both nRF52832 add-on boards should come on steadily
- Data streaming in from the remote MCU will automatically appear on the serial monitor
- If you selected the Tlera Dragonfly for the gateway MCU and the remote device is either a Dragonfly or Butterfly, you can do OTA firmware updates
- Copy the new firmware image to the gateway Dragonfly's virtual flash drive
- Send a "1" from the serial monitor and watch it go!
- It should take about 2-10min to complete the update, depending on the firmware image size. Upon successful completion, the remote MCU will reboot and resume normal operation
- Detailed OTA firmware update instructions are in "STM32L4_BLE_Bridge_and_OTA_Wiki.pdf" located in the main folder of this repository.
It is recommended to read the "STM32L4_BLE_Bridge_and_OTA_Wiki.pdf" document in this repository for instructions on how to use the Tlera nRF52832 add-on boards and software examples. Practical considerations of using both the Arduino MCU sketches and nRF52832 firmware are discussed there. This section will focus more on using the example sketches as an infrastructure to develop new BLE-connected Arduino applications and how to use the nRF52832 firmware source code in the Nordic SDK to make user-specific modifications.
This repository contains example Arduino sketches for using the Tlera nRF52832 add-on boards on both "remote" and "gateway" MCU development boards. The sketches support "Dragonfly", "Butterfly" and Teensy3.X MCU products. The names should make it obvious which sketches support which boards. All sketches have been successfully tested with their respective products. The Teensy3.X sketches have been tested with the Teensy 3.2 and 3.6 boards. All sketches containing "Blink_Example" in their name are intended to run on the remote MCU. All sketches with "Monitor_Utility" in their name are intended to run on the host MCU.
The most basic form of remote MCU sketches all work on the same principle: Open the UART port connected to the nRF52832 add-on board and read/write/print operations addressed to that port will be handled over the BLE/NUS connection. This is all that is required for the remote MCU device to send results to a tablet computer, smart phone or PC. It should be noted that BLE NUS data rates are fairly limited. As a practical matter, more than about 1kb/s may result in data loss. If OTA firmware update capability is desired, it is necessary to include a serial protocol and an OTA update handler. These are implemented in "Host_WirelessSerial.cpp" and "BLE_OTA.cpp" respectively. The serial protocol is included in all examples but the OTA update handler is only in the STM42L4-related examples. The "WirelessSerial::serialCom()" MSP handler is called every cycle of the main loop to process incoming MSP messages. If a valid MSP message to initiate OTA firmware update is received, the "OTA::OTA_Update(OTA_Update_Size, OTA_Update_Blocks)" sub-loop handler is called to complete the update.
Gateway MCU sketches are equally simple in concept: Check the UART port connected to the nRF52832 add-on board for incoming data each cycle of the main loop. As data is available, read each incoming byte and write it to the MCU's USB serial port. Conversely, the USB serial port can also be checked for incoming data which is then written to the BLE UART port. The STM32L4-related examples monitor the USB serial port for a specific incoming byte in order to call "flashFW()", the OTA firmware update handler. The Teensy3.X-related examples do not monitor data incoming on the USB serial port but it would be a simple matter to do so if desired.
Both Central and Peripheral role firmware for the nRF52832 were developed using v12.2.0 of the Nordic nRF5 SDK. The source code folders are meant to be copied directly into the "...\examples\ble_peripheral" folder (Peripheral role source code) or the "...\examples\ble_central" folder (Central role source code) of the SDK. The firmware is built for the pca10040 board and s132 SoftDevice options using the "armgcc" method (gcc ARM compiler and GNU "make"). The two projects are meant to directly drop into the v12.2.0 SDK without any further modification. The GNU "make" and gcc compiler build method was selected because it doesn't require any monetary investment in order to build the firmware.
The firmware is flashed to the nRF52832 add-on board using the Nordic nRF52 DK board and nRFgoStudio. Detailed instructions for downloading the firmware to the nRF52832 add-on board are given in "STM32L4_BLE_Bridge_and_OTA_Wiki.pdf" located in the main folder of this repository.