WiFi Startup

This document briefly describes how the application handles WiFi startup. It provides little detail, except to provide pointers to a few files and objects in the code that can be used in an editor or in a debugger to gain a good understanding of the subject. Because that approach (browsing the code and using a debugger) is very easy and fully informative for this subject, no additional documentation work is planned. Wired ethernet startup is described in EthernetStartup.

CC3100

This describes the startup for the CC3100 chip in applications with the main file TezzeretApp.cpp.

Hardware

A Tiva-based board, using the CC3100 WiFi chip

Overview

WiFi startup occurs in 2 stages:

• Main startup of the WiFi core system.
• Processing of additional setups, including starting daemons, etc.

Core WiFi startup

Core startup happens in 3 main stages:

• Pin setup and power-on : Handled in the main application thread and optionally in a SystemControl thread.
• SimpleLink network startup: a set of functions that start the WiFi module, set SSID, password, signal strength, and so on. The CC3100 can be used as an access point or as a station; in most of the Geometrics applications it is an access point.
• Acquisition of a network link to another device - When the CC3100 is set up as an access point, this occurs when the other devices connects to the CC3100.

To trace the core startup process, look for the WiFi semaphores in TezzeretApp.cpp. The process bounces between a few different threads, but it's not hard to trace the process; just look for the semaphore posts and pends.

If the WiFi does not initialize correctly, the process will not freeze in the main thread of execution, but will log error messages if possible and continue into the rest of the application functionality (limited of course by the lack of functioning WiFi).

Additional setups

When the CC3100 connects to another system or disconnects, events are inserted into a queue, to be handled in a loop in the function setupwifiConnection(). The events are handled in setupwifiConnection, by starting and stopping various network daemons as well as doing any other wifi tasks.

The queue-based approach is needed because the various events and tasks often occur with some delay, so that a pure interrupt-style approach to the handling might break some of the ordering invariants.