User's Guide

Getting Started
EZ-Serial BLE Firmware Platform User Guide, Doc. No. 002-11259 Rev. *E 26
Layer Details
Automatic
(RAM)
Description:
Automatic settings are set by the firmware based on detected external behavior, and EZ-Serial uses these values to
augment the settings in the runtime configuration block. Currently, only one setting falls into this category:
• API parse mode (binary or text mode depending on initial packet byte)
Content:
These values contain a very limited subset of auto-detected configuration settings, and do not include most configuration
data or any GATT structure or value data.
Data retention during chipset reset: NO
These values are not retained during power cycles and chipset reset conditions.
Data retention during DFU: NO
These values are not retained during the DFU process, which involves a chipset reset prior to image transfer.
2.5.2 Saving Runtime Settings in Flash
Storing settings in flash memory is critical to allow predictable, long-term customized behavior without needing to
reconfigure each time. EZ-Serial provides two ways to accomplish this:
1. Use the system_store_config (/SCFG, ID=2/4) API command to write all current runtime-level settings to the
boot-level configuration. This applies a snapshot of the current configuration to flash in one step. It is simpler
than the alternative if you are unsure which settings have changed between boot-level and runtime-level values,
or if you want to test out a new set of options before making them permanent.
2. Set the “flash” memory scope bit in the binary command packet header when writing new configuration values
with relevant commands, or append the ‘$’ character to command names in text mode. This is simpler than the
alternative if you know exactly which settings need to be changed, since it does not require the final use of the
system_store_config (/SCFG, ID=2/4) API command afterward.
Note that while the flash memory scope bit (in binary mode) or ‘$’ character (in text mode) may be used with any
command, doing so is only relevant for commands which either read or write configuration values directly. For other
commands, these flags will be silently ignored. See the API reference material in Chapter 7 (API Protocol Reference) for
details.
To ensure the longest flash memory life, writes to flash should be as infrequent as possible in production-ready designs.
Settings that must be changed frequently should be modified in RAM and only written to flash if required. Note, the
internal chipsets used in the EZ-BLE modules that run EZ-Serial have a minimum flash endurance rating of 100,000
cycles.
2.5.3 Protected Configuration Settings
A small number of configuration values have the potential to put the module into a state where it is no longer possible to
communicate over the serial interface as intended. While it is always possible to completely revert to factory default
values using the FACTORY_TR and CYSPP pins while booting the module, logical access to these pins for this purpose
is not always readily available, and a complete factory reset may be too disruptive for your application.
To help avoid this potential problem, a few settings are classified as protected. This means that they must be changed at
the runtime level only (RAM) before they may be applied to the boot-level (flash) area. Currently, only one command
affects protected settings:
• system_set_uart_parameters (STU, ID=2/25)
The changes that are most likely to cause an unintended communication lockout are serial transport reconfigurations,
such as selecting a baud rate that is not supported by the host. To store new values in flash for protected configuration
settings, you must either send the same command twice with the flash memory scope bit/character used only the second
time, or else use the system_store_config (/SCFG, ID=2/4) API command to write all runtime-level settings to the boot
level after first setting the new value in RAM only. This forces the flash write to occur using the new configuration, which
can only occur if communication is still possible.