Getting Started with EZ-BT WICED Modules
Document Number: 002-23400 Rev. **
25
Figure 16. Expected Download Failure After Compiling
The WICED Studio IDE may show some symbol resolution errors in the main code window. Often, these symbols
would have been resolved correctly, but the IDE is misidentifying issues in the code due to differences between
the code analysis toolchain and the one used for the final build process. For instructions on how to disable these
errors, see Section
Eliminating False Code Analysis Errors
7.4
Part 2: Understanding the Flow of the WICED Project
EZ-BT WICED Module contains ROM (Read Only Memory), RAM (Random Access Memory), and Flash memory. The
ROM area of the module contains the full Bluetooth stack. The RAM area is used for applying patches to the ROM-
stored stack as well as for running applications. Flash memory in the device is a nonvolatile memory, which stores the
application. For devices without internal flash, a host device is required to load the application program into RAM.
The application focuses on application-specific functionality while the stack deals with the low-level details. For
example, the stack transparently handles a GATT Client read request or discovery. Also, the application provides
various configuration details for the stack such as advertisement content and interval or output power during
transmission.
The following main steps are required to develop an application for an EZ-BT WICED Module:
▪
Define the data to be exchanged between the Client/Master and Server/Slave and prepare a database for BLE
and Bluetooth BR/EDR. (In this example, this is already accomplished during the merging process described in
Section 7.2
▪
Determine whether additional devices such as a UART-connected MCU or an SPI-connected peripheral sensor
will be included in the solution. The UART, SPI or GPIO configurations of the application depend on the connected
Peripheral devices. In this example project, a button and a LED are configured as part of the application.
▪
Adjust the application configuration to provide the parameters required by the application. Common changes
include advertisement parameters, and device name. In this example project, BLE peripheral advertises with the
name “Hello” and Bluetooth BR/EDR slave shows up as “spp_test” during inquiry process.
▪
Define and code the functions for the Bluetooth Stack callbacks required by the application. The application
typically requires notifications from the stack when certain Bluetooth events occur such as connection
establishment, disconnection, GATT write operations, or bonding.
Three main firmware blocks are required for designing Bluetooth applications using the WICED Studio SDK:
1. System initialization
2. Bluetooth stack event handlers
3. Bluetooth service-specific event handlers
The following sections discuss these blocks with respect to the design that was configured as part of the merging
process in Section 7.2
. Most of the functions involved achieve the required functionality. However, some of the
functions need to have additional code added to achieve the specific behavior that your application requires.
Unlike other platforms, the WICED Studio SDK Bluetooth stack does not require or provide an application-
level “main
loop” function that repeats forever. Instead, the main loop is handled internally along with low-power transitions, and all
application behavior must be fully event-driven based on interrupts triggered by timers, wireless (Bluetooth) activity, or
wired (GPIO, UART, etc.) activity.
