Over-the-Air (OTA) updates are incredibly useful in applications where plugging in a cable is inconvenient or impossible. This is increasingly the case in IoT products with extremely small form factors. I’ve recently used the BL652 BLE Module from Laird in a number of projects. Laird’s SmartBASIC run-time engine supports Over-the-Air (OTA) updating of SmartBASIC applications. Here are my thoughts on getting it to work successfully.
The BL652 is based on Nordic Semiconductor’s very popular nRF52832 SoC. At the heart of the nRF52832 SoC is an ARM Cortex-M4 32-bit processor. The nRF52832 can be programmed using the two-pin Serial Wire Debug (SWD) interface available on the ARM architecture. For developers with the appropriate knowledge level, hardware and inclination, this allows the BL652 to be operated with entirely custom firmware or with low level control over the Nordic Semiconductor SoftDevice running on the nRF52832.
SmartBASIC Applications and Run-Time Engine (Interpreter)
For many developers working on BLE applications, accelerated product development time and ease of use is more important than low level control. For those reasons, Laird developed the SmartBASIC programming language and associated run-time engine to execute SmartBASIC applications running on modules such as the BL652.
SmartBASIC is derived from the BASIC programming language. It is very easy to use with a simple code syntax. User applications written in SmartBASIC are anticipated to be “event driven”. This reflects the typical use case for BLE modules in embedded systems.
When the BL652 module is shipped by Laird, it comes pre-loaded with a SmartBASIC run-time engine. During module operation, this run-time engine interprets the user’s SmartBASIC code to execute the application.
For SmartBASIC application development and downloading, Laird provide a terminal emulator called UwTerminalX. UxTerminalX will be used to interact with the SmartBASIC run-time engine running in the BL652 module to download the user’s SmartBASIC application.
The SmartBASIC Core Functionality User Guide is a very thorough resource if you are interested in learning more about SmartBASIC.
Downloading SmartBASIC Applications to the BL652
The BL652 ships with the initial Production Release (v126.96.36.199) of its SmartBASIC run-time engine pre-programmed. Obviously, the user’s SmartBASIC application code is not pre-programmed on the module when it arrives. The user’s SmartBASIC application must be downloaded to the module. This can be done in many ways:
- Through the UART Interface (Serial Port) on the BL652.
- Through the SWD Interface on the BL652.
- Wirelessly “Over-the-Air” using the Virtual Serial Port (VSP) on the BL652.
During development (and in some product configurations), it is common to download the user’s SmartBASIC application to the BL652 module over its UART Interface. This is option 1 above. A computer (running UwTerminalX) or an embedded host processor communicates with the BL652 over a UART interface, i.e. through a serial port. This is the approach commonly used when working with the BL652 Development Kit (DVK-BL652).
In a production environment, option 2 in above list may be the most appropriate programming approach. It is possible to rapidly program the latest version of the SmartBASIC run-time engine and a user’s SmartBASIC application on to the BL652 in a single operation over the SWD interface.
Option 3 provides an interesting alternative to the first two options. Unlike the first two options listed above, this method does not require a physical connection between the programmer and the BL652 module to be programmed.
What is the Virtual Serial Port (VSP)?
The BL652 running the SmartBASIC run-time engine has a physical UART interface, i.e. serial port.
In SmartBASIC Interactive/Development Mode, this UART is used to interact with the SmartBASIC run-time engine using AT commands and to download a user’s SmartBASIC applications.
In SmartBASIC Run-Time Mode, this UART is available for use by the user’s SmartBASIC application, e.g. to communicate with a peripheral in the user’s product.
The Virtual Serial Port (VSP) provides similar functionality over BLE.
In VSP Command Mode, AT commands that are sent over BLE to a VSP Service running on the BL652 will be handled by the SmartBASIC run-time engine. The SmartBASIC run-time engine will send back appropriate responses to the AT commands. A SmartBASIC application can be downloaded to the BL652 wirelessly in VSP Command Mode. This is a very useful feature!
In VSP Bridge to UART Mode, data sent over BLE to a VSP Service running on the BL652 will be passed to the physical UART interface. For example, an app running on a smartphone (with a BLE interface) could communicate directly with a peripheral in the user’s product.
Enabling VSP Command Mode
VSP Command Mode can be enabled at module power-up or reset.
To enable VSP Command Mode, the following conditions must be met:
- SIO_02 (Pin 23) must be externally driven or pulled high.
- SIO_13/nAutoRun (Pin 28) must be externally driven or pulled low.
- There must be no $autorun$ application present in the BL652 filesystem.
Condition 3 is subtle. Condition 2 states that the nAutoRun pin must be pulled low. Under those circumstances, if an $autorun$ file is present in the filesystem, it will load automatically and VSP Command Mode will not be enabled. The ERASEFILESYSTEM function can be used in a SmartBASIC application to erase an $autorun$ application, if required.
Below, using the nRF Connect for mobile app from Nordic Semiconductor, a BL652 is seen advertising in VSP Command Mode.
After the BL652 enters VSP Command Mode (through a module power-up or reset), it will advertise until a BLE connection is made or a timeout period elapses. The timeout period isn’t very long – less than a minute. The Device Name is always “LAIRD BL652”. The 6-byte Device Address (MAC Address) is different for each device.
For products incorporating the BL652, it is usually a good idea to permit external configuration of the SIO_02 and SIO_13 pins. To keep the required area, BOM cost and access to a minimum, this can be done with test points, jumper links, pull-up/pull-down resistors or miniature push buttons, as appropriate. An example implementation from a recent project that I worked on is shown below.
OTA Programming with the BL652 Development Kit
The BL652 Development Kit (DVK-BL652), shown below, can be used to wirelessly download SmartBASIC applications to a target BL652 module.
Laird provide an explanation of how to use the BL652 Development Kit to program modules wirelessly in the OTA Loading of smartBASIC Applications – BL652 to BL652 Application Note.
Here, I will provide an alternative explanation based on the same approach.
Principle of Operation
When downloading SmartBASIC applications wirelessly between two BL652 devices, Laird’s Virtual Serial Port (VSP) BLE Service is used in both devices.
Development Kit BL652
The BL652 on the Development Kit operates in a pass-through mode. This is the use case for the VSP Bridge to UART Mode, described above.
The physical UART interface on this BL652 is connected to a PC running UwTerminalX. The BLE interface is connected to the BLE interface on the target BL652.
It receives data on its physical UART interface (from UwTerminalX) and transmits this data over its BLE interface. Similarly, it receives data over its BLE interface and transmit this data over its physical UART interface (to UwTerminalX).
In effect, AT Commands and Responses pass between UwTerminalX and the BLE interface.
The target BL652 operates in VSP Command Mode (once configured to do so at power-up or reset).
The BLE interface is connected to the BLE interface on the Development Kit BL652. Data received from the BLE interface, typically AT commands, is handled by the SmartBASIC run-time engine. Data transmitted to the BLE interface, typically responses to AT commands, is generated by the SmartBASIC run-time engine.
BLE Interface Connection
For the Development Kit and target BL652 devices to communicate, a BLE connection needs to be established.
In VSP Command Mode, the BL652 behaves as a “server” awaiting connections. As the target device is operating in VSP Command Mode, the Development Kit device will need to act as a “client” and connect to the target device. This is reflected in the file name of the SmartBASIC application mentioned above, $autorun$.VSP.UART.bridge.outgoing.sb.
The Development Kit device needs to know what target device to connect to. For this reason, the Device Address (MAC Address) of the target device must be known. The Device Address can be determined in many ways. It may be convenient to use the nRF Connect for mobile app from Nordic Semiconductor to do so.
Before running the $autorun$.VSP.UART.bridge.outgoing.sb SmartBASIC application on the Development Kit, the Device Address of the target device must be updated in the application source code.
This is done in the line beginning with #define BTAddr. A seven-byte value is expected. The first byte indicates the address type and the remaining six bytes indicate the actual Device Address. A value of 0x01 for the first byte indicates a Random, Static Device Address. A value of 0x00 for the first byte indicates a Public (i.e. IEEE defined) Device Address.
For the SmartBASIC application to attempt to connect to the target device automatically, #define CONNECT_ON_STARTUP 0 should be changed to #define CONNECT_ON_STARTUP 1 in the application source code.
SmartBASIC Application Download
Once a connection has been established between the Development Kit and the target device, UwTerminalX can be used to interact with the target device in the usual manner.
The “XCompile + Load” command can be used to download a SmartBASIC application to the target device. The download speed may be slower than with a wired UART connection to the target device but given the convenience, the trade off is well worth it.