Initial Bluetooth support for nRF52840 in Renode

For several years now we have been working with the Google TensorFlow Lite Micro team on making their ML framework aimed at MCUs and other low-power devices easier to test and demonstrate using our open source simulation framework, Renode.

Throughout this time, we helped bring TFLM to RISC-V, improved the framework’s kernel testing capabilities and created full system testing and demonstration environments which give you the ability to experience the end-to-end ML flow in the browser, with all stages of the processing: data acquisition, driver operations, ML processing and the system’s reaction to the results.

One platform we have been focusing on is the Nordic nRF52840-based Arduino Nano 33 BLE Sense board. For this tiny but versatile platform, we implemented a number of I/O peripherals including microphone and camera - allowing the users to test scenarios relying on images, sound data, acceleration and more. A notable exclusion from our nRF52840 support however was the Bluetooth Low Energy radio, which was initially out of the TFLM team’s scope of interest - but based on popular demand, BLE support in Renode is becoming a reality.

Renode’s wireless capabilities

Being used in the testing and CI of networking-oriented RTOS such as Zephyr, RIOT, Contiki and mbed, Renode has already supported the simulation of complex multi-node systems for many years, both with wired and wireless networks. The framework provides many additional features that make development of network protocols easy, starting from host-guest connectivity, through native Wireshark support, to advanced traffic testing capabilities and wireless medium manipulation. We’d even shown how to simulate the bridging of two types of networks to reflect the simulator’s aim to support complex, real-life setups which may require the use of multiple radio bands..

These features make Renode an excellent choice for development of IoT systems like smart home or wearables, in which reliable connectivity is key. With the growing interest expressed by our customers and partners, and the TF Lite Micro team’s observation that BLE made for a much smoother user experience for experimentation in their ML courses than serial connectivity, adding BLE support was only a matter of time.

Bluetooth and Zephyr

If you plan to develop a BLE-enabled product, the Zephyr RTOS with its open BLE stack which has been pre-qualified by the Bluetooth SIG in several variants is a natural choice. Featuring first-class support for the nRF52840 chip, with an excellent community and extensive documentation, it provided us with ready to use samples which we could use in our development. These samples showcase various BLE profiles, protocols and roles.

.
├── beacon
├── central
├── central_{hr|ht|iso|past}
├── direction_finding_connectionless_{rx|tx}
├── eddystone
├── handsfree
├── hci_{pwr_ctrl|rpmsg|spi|uart|usb|usb_h4}
├── ibeacon
├── ipsp
├── iso_{broadcast|receive}
├── mesh
├── mesh_{demo|provisioner}
├── periodic_{adv|sync}
├── peripheral
├── peripheral_{csc|dis|esp|hids|hr|ht|iso|ots|past|sc_only}
├── scan_adv
└── st_ble_sensor

For the initial work, we decided to prepare a heart rate monitor setup, using the central_hr and peripheral_hr samples. The peripheral sends a fake heart rate information every second and the central scans the environment for heart rate monitors and reports received readouts.

How it works

The Nordic BLE SoCs feature a subsystem called PPI - Programmable Peripheral Interconnect. It is used to connect peripheral events (like a timer tick or a state transition in a radio) with peripheral tasks (like triggering packet reception or disabling the radio). It is a very convenient way to simplify your algorithms and offload the CPU by automating workflows, and it is used heavily by Nordic’s BLE drivers.

Another interesting feature available in Nordic’s SoCs is called “shorts”. Shorts are designed to automate transitions between states in a single peripheral, e.g. to stop the timer as soon as the compare value is reached. Effectively, it has a similar role to PPI, but is confined to the scope of a single IP block.

PPI, along with RNG and of course the radio itself, were new models we had to implement to progress further with the BLE support. As PPI and shorts introduce a processing model that is not commonly found in other vendors’ devices, it required us to design a way to reflect these interactions within the emulated machine.

An early version of all of these models is now publicly released on Renode’s GitHub. The screenshot shows the nodes communicating with each other, with traffic sniffed and displayed in Wireshark.

Future capabilities, planned work

This initial stage is just a start of BLE support in Renode and there are many ways in which we plan to improve it. Wireshark support for more link layers, improvements in the nRF52840 radio model and multi-node BLE demos are under active development to allow more engineers to employ Renode in their everyday IoT workflows. Ultimately, this work will enable end-to-end testing of device-user app interactions using e.g. Android studio. With Renode, complete testing frameworks can be created to verify - among other things - the user experience of smart office, car, home, city and building management systems with real, binary-compatible software that will be deployed in the field.

We help customers create well-tested, modern based systems on open source technologies using our open hardware platforms and open source operating systems and tools that we create. If you’d like to work with us to build your next product, and particularly if you are interested in BLE support in Renode, please reach out to us at contact@renode.io.