4. Analyzing The Demonstration Example

This section analyzes an application example which demonstrates using the flash adapters. The example is based on the freertos_retarget sample code found in the SDK. It adds an additional freeRTOS task which is responsible for various flash operations and enables the wake-up timer for handling external events. Both the NVMS and NVMS_PARAM APIs are demonstrated.

4.1. Application Structure

  1. The key goal of this demonstration is for the device to perform a few flash operations upon an event. The button K1 on the Pro Devkit has been configured as a wake-up input pin. For more detailed information on how to configure and set a pin for handling external events, read the External Interruption tutorial. At each external event (produced at every K1 button press), a dedicated callback function named wkup_cb() is triggered. In this function a variable called flash_state is toggled. It can take two different values which are interpreted as follows:
    • flash_state = 1
      • A write access is attempted in TAG_BLE_PLATFORM_BD_ADDRESS field of the NVMS_PARAM_PART partition entry. The first byte is set to 0x00, thus validating the stored BD address.
      • A write access is attempted in NVMS_LOG_PART partition entry. A text message is stored indicating that the BD address stored in flash is valid.
      • A read access is attempted in NVMS_LOG_PART partition entry to read the status of the BD address. The read data is printed out on the serial console.
    • flash_state = 0
      • A write operation is attempted in TAG_BLE_PLATFORM_BD_ADDRESS field of the NVMS_PARAM_PART partition entry. The first byte is set to 0xFF, thus invalidating the stored BD address.
      • A write operation is attempted in NVMS_LOG_PART partition entry. A text message is stored indicating that the BD address stored in flash is invalid.
      • A read access is attempted in NVMS_LOG_PART partition entry to read the status of the BD address. The read data is printed out on the serial console.
'Flash Read/Write Operations SW FSM - Main Execution Path'

Fig. 18 Flash Read/Write Operations SW FSM - Main Execution Path

Note

It is essential for the system to enter the idle mode, that is all the OS tasks are either blocked or suspended. By default, the Background Options mechanism is enabled allowing the execution of flash memory related operations only when the system is idle.

  1. For debugging purposes, LED D2 on Pro DevKit is used to indicate a flash operation is in progress. The LED blinks once at every K1 button press, indicating that accesses to flash memory have been successfully executed. To further safeguard the code, assertions are used. At the end of each read/write access to flash memory, the APIs return the actual number of read/written bytes. If a flash operation fails to be executed, the API returns a value equal to zero as none of the requested bytes were written/read. Hence, the condition in the assertion will be false and the code execution will get stack at that point. Hence, allowing the developer to identify the point of interest during a debugging session.
/*
 * The function returns the actual number of written data.
 */

wd_log_bytes = ad_nvms_write(nvms_var, 0, (uint8_t *)log_value_1_wd,
                                                      sizeof(log_value_1_wd));

/*
 * If condition if false, the code will get stuck right here.
 */
OS_ASSERT(wd_log_bytes != 0);