How to Verify a Network Driver Using the Arm Mbed Greentea Test Suite
This is a guest blog, written by James Flynn from Avnet.
When implementing a network driver, you must verify the APIs are all used correctly. To make that possible, Arm provides a suite of network socket tests within Mbed OS called Greentea. The Greentea test suite runs on the test automation environment. This test suite exercises all of the fundamental APIs to ensure the driver will function correctly when integrated. It is a Pass/Fail verification of compliance, not a benchmark.
More information on Greentea can be found in the Greentea section of the Mbed documentation. In this article, we discuss using Greentea to verify operation of the WNC14A2AInterface Network Driver that is available with the AT&T Cellular IoT Starter Kit. The driver and all the code is available in the M14A2A Greentea Test Suite Example.
The Avnet AT&T Cellular IoT Starter Kit provides designers a way to quickly implement cellular IoT connections using AT&T’s 4G LTE network. The kit includes a NXP Freedom FRDM-K64F board and a Wistron Neweb Corporation (WNC) Cellular Data Module (the WNC14A2A). The K64F board, running the Arm Mbed OS, interacts with the WNC14A2A which implements the Cellular Radio functionality via a Network driver. The Network driver uses a UART interface to the WNC14A2A module to issue AT commands data call setup/teardown.
The WNC14A2A Network driver, in the M14A2AGTTS_Example archive, has been tested with the latest Mbed OS (version 5.7). The readme file contains all the instructions for building and running both a basic application to demonstrate the use of standard HTTP commands (PUT/GET/POST/DELETE) and for running the Greentea network socket tests.
To successfully run the Greentea network socket tests, you need to use mbed-cli version 1.3.0 or higher. To get started, be sure the Arm Mbed Command Line Interface (CLI) is installed.
To successfully run the Greentea network socket tests, you need to use mbed-cli version 1.3.0 or higher.
Aside from the CLI, you also must have the latest version of GNU Arm embedded tool chain installed.
Start with the basic application
The basic application exercises the network interface to ensure you have successfully installed and built the source code. It makes a simple connection using HTTP or HTTPS. The README.md file in the archive illustrates the expected output from the basic application.
Before running the network socket, ensure you have successfully installed and built the source code. It makes a simple connection using HTTP or HTTPS. The README.md file in the archive illustrates the expected output from the basic application.
Test operations due to multiple main() functions being found
Prior to building the Greentea tests, you must eliminate the main() function (located in M14A2AGTTS_Example/source/main-x.cpp). The mbed-cli will compile and link all source code it finds under the current working directory. If it compiles main-x.cpp, a linker error occurs due to multiple main() functions being found. The reason for multiple main() functions is that the application has one (main-x.cpp) and the Greentea test files also have one. The easiest way to resolve the problem is to rename the main-x.cpp file to main-x.cpp_ and keep the mbed cli from compiling and linking it.
Once main-x.cpp has been renamed, issue the command: ‘mbed test –m K64F –t GCC_ARM –c –test-config wnc_config.json –n mbed-os-tests-netsocket-*’. The Network socket related tests will be compiled, linked, and sequentially loaded onto the AT&T Starter Kit and executed. You will notice during execution the following:
Build skips: Build skips:
The ‘Build skips’ are tests that are currently excluded from Greentea verification test run, so you will not see results from these tests.
Some tests such as the UDP_DTLS_HANDSHAKE test cannot currently be tested on cellular interfaces. That test will fail when using a cellular interface because it requires the Greentea test server to be on the same network node as the device being tested, but the AT&T Starter Kit (SK) is running on an external server (AT&T’s server).
If you want to exclude a test, such as when running on a cellular interface, you can edit the respective source file in mbed-os/TESTS/netsocket to remove the test.
In the test results below, the UDP_DTLS_HANDSHAKE test is failing because that test is not currently possible on cellular interfaces. If you want to exclude a test, you can edit the respective source file in mbed-os/TESTS/netsocket and insert or remove the following at the top of the file:
#ifndef MBED_EXTENDED_TESTS #error [NOT_SUPPORTED] Pressure tests are not supported by default
The ‘test case report’ which follows, lists individual tests along with their pass/fail result and execution time as shown:
The UDP_DTLS_HANDSHAKE test failure is expected. All the other tests pass.
By testing plug-in boards with Greentea, you can ensure applications will work as intended and will not cause unexpected problems when deployed.
From idea to design and from prototype to production, Avnet supports customers at each stage of a product’s lifecycle. A comprehensive portfolio of design and supply chain services makes Avnet the go-to guide for innovators who set the pace for technological change. For nearly a century, Avnet has helped its customers and suppliers around the world realize the transformative possibilities of technology. Learn more about Avnet at www.avnet.com.
You need to log in to post a discussion