ARM enables IOT with Beetle Platform

Introduction

ARM and its Partners share a vision where the creation and deployment of commercial, standards-based IoT devices at scale is as easy possible. The ARM mbed IoT Device Platform enables a software ecosystem that helps make it as easy as possible by providing a common platform for developing connected IoT devices.

The ARM IoT subsystem for Cortex-M processors allows design teams to create IoT endpoints faster and with lower risk.  ARM’s scalable IP solutions are designed to target across the value chain from sensors to servers.  ARM’s IoT subsystem with mbed OS is a complete reference system that reduces the complexity and risk of a SoC design for IoT endpoints. The subsystem features a range of peripherals and interfaces. It is specifically designed for the use with Cortex-M processors and Cordio ® Bluetooth® Smart radio. ARM has taken this subsystem and generated a proof of concept platform called Beetle.

Beetle proof of concept

The test chip used on the Beetle platform provides partners with a low risk proof of concept methodology that showcases how designers can rapidly move from Register Transfer Level (RTL) which is a high-level hardware description language used for defining digital circuits to silicon with minimum engineering effort. The central element of the Beetle test-chip is the IoT subsystem, which is pre-validated allowing the user to hit the ground running. We built on the IoT subsystem attaching the Cortex-M3 processor, ARM’s Cordio BLE 4.2 radio, TSMC embedded flash and a host of other complementary peripherals from 3rd party vendors. This test chip was also built using the ARM Artisan® physical IP platform specifically tailored for IoT applications. The design is fully compliant with ARM’s mbed IoT Device Platform to enable rapid development and prototyping.

Beetle FPGA prototyping

As part of the of Beetle pre-silicon validation plan, the RTL was ported to the Cortex-M Prototyping System (MPS2). This is a low cost FPGA development board from ARM which is ideally suited to prototyping IoT endpoints. We synthesised the design for FPGA, replaced the embedded flash with FPGA block RAM and used an external ARM Cordio evaluation board instead of the ASIC macro. This gave us a platform on which to perform functional testing of all the peripherals and to develop peripheral drivers ahead of silicon.

We demonstrated the ARM IoT subsystem at Computex in Taipei June’15, using our platform and an external ARM Cordio radio to send sensor values to an ARM server over Bluetooth. The Beetle test chip was sent for fabrication using TSMC’s 55nm process technology. While waiting for silicon to arrive, we developed the drivers on the FPGA prototype.

Software Frameworks

Our initial development work started when mbed OS was still at an early alpha phase. We decided to proceed with an mbed SDK (mbed Classic) driver port, so that we could create a stable demo for TechCon. Meanwhile the new mbed OS development moved from alpha, to beta, and then to the mbed OS 2015.11 technology preview release. Our ultimate goal was to have a complete IoT software framework ported to the device enabling rapid IoT device application development.

Showtime!

With ARM TechCon just around the corner we received our Beetle chips back in mid-October.

Then it was all hands on deck to bring up the chip and integrate the Cordio firmware with mbed. The demo included the Beetle platform with an external Cordio evaluation board sending sensor values over BLE to a nearby phone that displayed the data. In parallel to BLE transfers data was also sent over WiFi to an ARM based server, which collated this data with all the other sensors data from other sensor nodes around the ARM booth.

Activities after ARM TechCon

After TechCon, we started the port of mbed OS and updated the firmware, improved the power consumption, performed some benchmarking and added additional features.

So what have we been working on for the last few months?

Benchmarking

With Beetle intended as a proof of concept, we were interested in performing some initial benchmarking tasks. We ported CoreMark to the platform with good results:  a score of 137 (running from flash at 48MHz with 1 wait state) which was comparable to other Cortex-M3 based SoCs.

Firmware updates

While porting mbed OS, we also began a series of firmware updates which included:

• CMSIS-DAP support over USB with drag and drop programming of Beetle software binaries to the embedded eFlash or external QSPI.
• Serial wire debugging (SWD) for use with ARM Keil uVision.
• Virtual serial port commination.

Board improvements

We put some effort into refining energy consumption for the Beetle board. Among of the changes we made to the board are:

• The largest single power saving was ensuring that the CMSIS-DAP microcontroller on the board was put into deep-power down mode when not required. This alone saved 12mA . In the microcontroller, when the ARM Cortex-M0 is put into its Wait for Interrupt (WFI) low power state, the surrounding logic detects this and turns off the power to the majority of the chip, including stopping the clocks. The CMSIS-DAP is put into this mode by default when the board is battery powered, but is reawakened when USB power is applied, allowing for the use of USB debug and virtual serial power connections
• Added pull ups to the QSPI Flash, SPI ADC chip selects and clocks. This ensured that devices were put into their lowest power modes if the I/O was explicitly configured by the software.
• We found that the ORing diodes used to power the ARDUINO® shield’s supplies had a fairly high reverse leakage current, which was wasting energy. The solution was to utilise FETs rather than diodes, slightly more complex but less wasteful.

Migrating from mbed Classic to mbed OS

mbed OS differs from mbed Classic and introduces a new lifecycle tool called yotta, which makes it easy to reuse software modules in C and C++. This requires new structure definitions, modules and targets organization. Supporting the new strategy meant understanding the object oriented design of the new operating system. From the board support package (BSP) standpoint, this meant refining the driver architecture in order to fit the new design and be compliant with the new model defined through JSON, which is a lightweight data-interchange format.

Once the definition was complete it was time to start adding some code. All the drivers are split between CMSIS and HAL and built through CMake infrastructure. One important thing to keep in mind is the introduction of the new MINAR scheduler, which requires an lp_ticker and a sleep driver, both of which are not present in mbed Classic (take a look at the advantages of the MINAR scheduler). After this addition, with only a couple of changes to the scatter file and an understanding of the memory allocation in mbed OS, our Beetle was ready to boot. And of course “Welcome to mbed OS” was the first message we saw on the serial port.

mbed OS Cordio BLE Integration

After completing the base port we moved onto our next activity, bringing up the ARM Cordio BLE radio. We needed a BLE infrastructure in our mbed port. mbed OS already provides a BLE Object, which is the main interface between the OS and the BLE world. It is responsible for providing a set of compliant BLE services that can be instantiated directly from the main application. In order to talk with the low level IP, the BLE Object interfaces with a lower level BLE stack, which in our case was the ARM Bluetooth Stack (formally WiCentric).

Next we had to integrate the Cordio firmware and Cordio drivers into the rest of the system. What we noticed immediately was that we could not use the SysTick as the main timer anymore, because this was making it difficult to synchronize with the Cordio macro. The main challenge here was that we had to re-architect our timer strategy, because the various sensors and IP had specific requirements for timing. After some investigation, we used the Dual Timer for the lp_ticker and the Cordio IP, and the Timer0 for the us_timer, which worked like a treat.

mbed OS sensors integration

Now that we had a functional system it was the time to transmit some real data over BLE. For a previous demo we created a shield containing proximity, microphone and humidity and temperature sensors and we decided to reuse this. Together with the internal True Random Number Generator (TRNG) we had enough data to stream over BLE.

Android demo app

ARM’s demo team had already created an android app for the TechCon demo, which was to be used for the final phase actually transmitting the data over BLE. The initial app’s services needed a minor modification to be able to recognize the new sensor data coming from over Bluetooth. Then it was time to click “connect” and see the application read and display sensor data from the board.

Conclusion

The experience of taking something from prototype to silicon and pulling all the software together was amazing. It was a rewarding and interesting challenge for engineers to get involved in. We learned on the value of FPGA prototyping and software development ahead of silicon. Found ways to reduce the board power consumption. Learned how to port mbed OS and integrate Cordio BLE software and add sensors. We plan to release the source code for Beetle shortly so you can benefit from everything we’ve learned to shorten your development time and focus on the differentiating part of your design.