The Cypress Bluetooth SoC device can either be used in controller mode or embedded mode.
In controller mode, the Cypress Bluetooth SoC device runs the Bluetooth controller stack and the Bluetooth host stack is run on an external host MCU. The Cypress Bluetooth SoC device uses the Host Controller Interface (HCI) to communicate with the host controller.
In embedded mode, both the Bluetooth host stack and the controller stack are run on the Cypress Bluetooth SoC device. All the components of the controller stack and most of the components in the host stack reside in the device ROM. The user application, which can call APIs to access the ROM code, is programmed into the flash. If no code is programmed into the flash and the device is powered ON, it behaves like a Bluetooth controller that is controlled by HCI.
The Cypress Bluetooth SoC device uses “patches” to ROM code to modify the behavior and fix bugs. These patches can be built into a core patch file (called general patch in the remaining part of this document) that is included in all ModusToolbox builds, or they can be built into optional patch libraries (called patch libraries in the remaining part of this document) that are application-specific, such as patches that pertain to audio or mesh network applications only. This approach optimizes the use of patch RAM by using only the patch libraries that are needed for a given application.
Cypress BT devices support Over-The-Air (OTA) updates of the application code. More details on OTA can be found in the \ModusToolbox_1.1\libraries\bt_sdk-1.1\docs\BT-SDK\WICED-Firmware-Upgrade-Library.pdf and \ModusToolbox_1.1\libraries\bt_sdk-1.1\docs\BT-SDK\WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf.
Programming the device does more than just copy the patch and application code to flash. It also uses commands to configure the structured data, cause the CPU to make function calls, configure hardware registers, etc. The default way to download firmware is through boot loading over the HCI UART. The device ROM contains a piece of code which can accept data through HCI commands from an external device (PC or MCU) and store it in flash. When the application code is downloaded, the host MCU (or PC) first transfers a piece of code called minidriver to SRAM; the minidriver then accepts further data through HCI commands and stores it to on-chip flash (OCF). More details about the minidriver can be found in Programming Guide.
Figure 3. Cypress Bluetooth SoC Firmware Download Flow