CC3100 & CC3200 Serial Flash Guide

From Texas Instruments Wiki
Jump to: navigation, search
Cc31xx cc32xx return home.png

Introduction

Many embedded systems contain a serial flash component to store firmware, configuration files and user data for usage by a microcontroller/processor. The processor sporadically writes data into this serial flash for updating the contents. Inclusion of serial flash memory poses unique challenges for the system designer
• A typical serial flash guarantees a data endurance of 100K write cycles per sector and 20 years data retention. The write endurance and data retention characteristics must to be taken into account by the application developer
• The serial nature of reads and writes results in long access times and this raises the challenge of maintaining a stable system supply voltage for the duration of the access.

This document provides guidelines and recommendations for system designers working with CC3100/CC3200TM file system.

How file system content gets to the serial flash

Before diving into file system structure, it is highly important for designers to realize how content can be created on the serial flash.
There are several ways for files to be created on the serial flash. The following table describes the various options:

Application/tool Device state Content delivery channel Content type Package/example
Uniflash Boot loader UART User, system and configuration files CC31xx & CC32xx UniFlash
SimpleLinkTM file system API Operational UART/SPI User files
  • File operations – SDK
  • OTA
  • Host programming
SimpleLinkTM non file system API Operational UART/SPI System and configuration files Any SDK example
SimpleLinkTM Device internals Operational Device internals N/A

File System guidelines

As the file system may be used by customers for their own purposes, it is essential to understand the constraints and recommendations so the file system is designed and maintained properly.

The guidelines are:

  • Minimal flash resolution is 1 block which is 4KB
  • The File System by itself requires 3 blocks (12KB)
  • There are 2 reserved blocks that cannot be used by the user
  • Total number of files is limited to 128 files, including system and configuration files
  • Maximal size of a file is 1MB
  • Maximal size of the serial flash is 16MB
  • Each file by minimum consume:
    • 1 Block (4KB) for file with no fail safe support
    • 2 Blocks (8KB) for file with fail safe support (twice the original size)
  • It is required to set the maximum size attribute upon file creation (the file system reserves space). In this case, the actual size of the file is irrelevant as file system occupies the allocated space
  • File size cannot be enlarged after the file has been created
  • File attributes (currently, only fail-safe) cannot be modified after the file has been created
  • There is no fragmentation in the file system. It means that an existing file which is removed would leave a "hole" in memory. This "hole" may be reallocated by the file system if the new file can fit into it
  • When file is created, the minimal memory “hole” that can hold the file is searched for
  • Actual size of a file may increase depending on its size. The mapping can be found under User file mathematics
  • Each file has a header which enlarges the actual size of the file. The overhead is 440 bytes. If the file size is very close to a multiple of block (4KB), additional block may be allocated. For example, a file of actual size 4000 bytes would result in allocating 2 blocks as 4000+440 > 4096. More information can be found under User file mathematics
  • Some system/configuration files may be created internally by the device. More information can be found under System and Configuration files
  • Some system/configuration files may be created implicitly from the host processor by invoking non file-system APIs. More information can be found under System and Configuration files

User file mathematics

Since users make use of the file system to store files, it is essential to be able to calculate accurately the occupied memory space per file. The total occupied size on flash is a function of the file content length (or the maximum size upon creation), file attributes and file system metadata.

The flow below describes the process for calculating how much memory is actually consumed on the serial flash.

file size calculations

Few examples illustrating the procedure:

File size (bytes) Page size Round to page Add header and round to block Allocated size via sl_FsGetInfo()
10 256 256 (1 page) 4096 (1 block) 3656
250000 1024 250880 (245 pages) 253952 (62 blocks) 253512
1000000 4096 1003520 (245 pages) 1007616 (246 blocks) 10007176

NoteNote: calling sl_FsGetInfo() provides the allocated size not including the 440 bytes header

System and Configuration files

Overview

Configuration and system files can be implicitly created by the user or internally created by the device. Since these files are essential for proper device operation, it is important that the user understand the meaning of each file and when it is required. Failing to preserve enough space for system/configuration files may cause system unexpected behavior.

Description

This paragraph describes in details the meaning of each system or configuration file.

Artifact Description
FAT File allocation table. Created upon format operation, either from Uniflash or via Image Programming. FAT is device unique so serial flash devices cannot be cloned and work on another SimpleLinkTM device
Reserved blocks Reserved blocks for future use
/sys/servicepack.ucf Holds firmware patches to all internal cores, Network processor, MAC layer and PHY layer. This is the only file that is secured and authenticated in the system
/tmp/phy.cal Calibration file created automatically by the device. Calibration is performed sparingly, typically when coming out of Hibernate and only if temperature has changed by more than 20°C or upon power cycle
/tmp/fcon.frm Fast connect frame. Holds all beacon information of the last connected access point. Created upon successful connection to an access point
/tmp/fcon.ssid Fast connect profile. Holds selected profile information of the last connected access point (as if a profile is added by the user). Created upon successful connection to an access point
/tmp/table.arp ARP table file. This file holds up to 8 entries. The table is updated upon ARP response reception to the device IP address
/sys/date_time.cfg Holds the system time and date. Mainly used with to validate expiry time of certificates during SSL connections
/sys/rxfltr.ini Holds all RX filtering information. The Rx-filters module enables the user to simply define a set of rules that determine which of the received frames are transferred by the SimpleLinkTM device to the host, and which frames are dropped. The Rx-filters can be activated during AP-connection and during promiscuous mode
/sys/infoele.cfg Holds user defined information element. The information element is transmitted when the device is either in AP mode or Peer2Peer group owner mode. The size is limited to 252 bytes
/sys/macadd.bin Holds the user defined MAC address of the device. If this file exists, the device internal MAC address is bypassed
/sys/stacfg.ini Holds device configuration when it is either in station mode or Peer2Peer client mode. The list of APIs related to stacfg.ini can be found under Host Driver mapping
/sys/ap.cfg Holds device configuration when in access point mode. The list of APIs related to ap.cfg can be found under Host Driver mapping
/sys/p2p.cfg Holds device configuration when Peer2Peer mode (client or group owner). The list of APIs related to p2p.cfg can be found under Host Driver mapping
/sys/mode.cfg Holds device general configuration, unbound to device mode. The list of APIs related to mode.cfg can be found under Host Driver mapping
/sys/pref.net Holds up to 7 stored profiles. Profiles may be stored explicitly from user application or implicitly during Smart Config provisioning. SimpleLinkTM device scan the stored profile list only if connection policy is set to Auto mode
/sys/pmcfg.ini Holds the power policy configuration of the device. The list of APIs related to pmcfg.ini can be found under Host Driver mapping
/sys/ipcfg.ini Hold IP configuration of the device. The list of APIs related to ipcfg.ini can be found under Host Driver mapping
/sys/devname.cfg Holds the device name and URN. The list of APIs related to devname.cfg can be found under Host Driver mapping
/sys/dhcpsrv.cfg Holds DHCP server information. The list of APIs related to dhcpsrv.cfg can be found under Host Driver mapping
/sys/httpsrv.cfg Holds HTTP server information. The list of APIs related to httpsrv.cfg can be found under Host Driver mapping
/sys/mdns.cfg Holds mDNS client information. The list of APIs related to mdns.cfg can be found under Host Driver mapping
/sys/smartconfigkeys.cfg Holds Smart Config keys in case the provisioning procedure is secured (access point credentials are encrypted during provisioning).

Memory consumption

The following table illustrate the memory consumption for each of the system components.

Filename/Artifact Description Fail safe #blocks
FAT File allocation table. Created upon format operation N/A 3
Reserved blocks Reserved blocks for the system N/A 2
Total 5
/sys/servicepack.ucf Firmware patches yes 66
/tmp/phy.cal PHY calibration yes 10
/tmp/fcon.frm Fast Connect frame (beacon info) yes 2
/tmp/fcon.ssid Fast Connect profile yes 2
/tmp/table.arp Arp Table yes 2
/sys/date_time.cfg Date Time yes 2
/sys/rxfltr.ini Rx Filters yes 2
/sys/infoele.cfg Info Element file yes 2
Total 88
/sys/macadd.bin MAC address yes 2
/sys/stacfg.ini Station configuration yes 2
/sys/ap.cfg AP configuration yes 2
/sys/p2p.cfg Peer2Peer configuration yes 2
/sys/mode.cfg WLAN Mode yes 2
/sys/pref.net Preferred networks yes 4
/sys/pmcfg.ini Power Management yes 2
/sys/ipcfg.ini IP configuration yes 2
/sys/devname.cfg Device Name yes 2
/sys/dhcpsrv.cfg DHCP Server configuration yes 2
/sys/httpsrv.cfg HTTP Server configuration yes 2
/sys/mdns.cfg mDNS configuration yes 2
/sys/smartconfigkeys.cfg SmartConfig Keys yes 2
Total 28

CC3200 use case

CC3200 is a special case since its image (application code running on the internal processor) should be taken into account as well. The occupied space depends on the OTA (Over-The-Air) scheme.
The following table illustrates two OTA schemes, MCU image with fail-safe option and OTA as taken from the OTA SDK add-on.

Filename/Artifact

Description

Fail safe

#blocks

/sys/mcuimg.bin
MCU application image running on the internal CM4
yes
128
Total


128




MCU boot info
Boot information for image selection
no
1
/sys/mcuimg.bin (MCU application bootloader)
MCU application for image selection
no
1
MCU image 1
1st image – the default image
no
64
MCU image 2
2nd image
no
64
MCU image 3
3rd image
no
64


Total


194


Host Driver mapping

As described earlier, some files are created internally and some can also be created implicitly by invoking host driver APIs.
It is mandatory to understand the mapping so users are able to design their memory budget such that enough space is preserved for all required system/configuration components.

Filename/Artifact

Created by API()

Read period

Write period

#blocks

FAT
N/A
  • When Exit Reset
  • When Exit HIB


  • @Format
  • Every Added/Remove File


3
Reserved blocks
N/A
N/A
N/A
2
/sys/mcuimg.bin
Refer to OTA
  • When Exit Reset
  • When Exit HIB


When updating APP
OTA dependent
/sys/servicepack.ucf
Refer to OTA. sl_FsOpen(),sl_FsWrite() and sl_FsClose()
  • When Exit Reset
  • When Exit HIB


User Initiated
66
/tmp/phy.cal
N/A
  • When Exit Reset
  • When Exit HIB


At least once, Upon temperature change when coming out of hibernate or upon power cycle
10
/tmp/fcon.frm
  • sl_WlanConnect()
  • sl_WlanProfileAdd()
  • sl_WlanSmartConfigStart()


Upon successful AP connection
When AP changes
2
/tmp/fcon.ssid
  • sl_WlanConnect()
  • sl_WlanProfileAdd()
  • sl_WlanSmartConfigStart()


Upon successful AP connection
When AP changes
2
/tmp/table.arp
N/A
Upon successful AP connection
ARP response to the device IP address
2
/sys/date_time.cfg
sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION, SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME, …)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/rxfltr.ini
sl_WlanRxFilterAdd() with sl_WlanRxFilterSet(SL_ENABLE_DISABLE_RX_FILTER,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/infoele.cfg
sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID,WLAN_GENERAL_PARAM_OPT_INFO_ELEMENT,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/macadd.bin
sl_NetCfgSet(SL_MAC_ADDRESS_SET,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/stacfg.ini
  • sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, WLAN_GENERAL_PARAM_OPT_SCAN_PARAMS,…)
  • sl_WlanPolicySet(SL_POLICY_CONNECTION, SL_CONNECTION_POLICY(),…)
  • sl_WlanPolicySet(SL_POLICY_P2P, SL_P2P_POLICY(),…)
  • sl_WlanPolicySet(SL_POLICY_SCAN,SL_SCAN_ENABLE,…)


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/ap.cfg
  • sl_WlanSet(SL_WLAN_CFG_AP_ID, WLAN_AP_OPT_SSID,…)
  • sl_WlanSet(SL_WLAN_CFG_AP_ID, WLAN_AP_OPT_CHANNEL,…)
  • sl_WlanSet(SL_WLAN_CFG_AP_ID, WLAN_AP_OPT_HIDDEN_SSID,…)
  • sl_WlanSet(SL_WLAN_CFG_AP_ID, WLAN_AP_OPT_SECURITY_TYPE,…)
  • sl_WlanSet(SL_WLAN_CFG_AP_ID, WLAN_AP_OPT_PASSWORD,…)


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/p2p.cfg
  • sl_WlanSet(SL_WLAN_CFG_P2P_PARAM_ID, WLAN_P2P_OPT_DEV_TYPE,…)
  • sl_WlanSet(SL_WLAN_CFG_P2P_PARAM_ID, WLAN_P2P_OPT_CHANNEL_N_REGS,…)


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/mode.cfg
  • sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, WLAN_GENERAL_PARAM_OPT_STA_TX_POWER,…)
  • sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, WLAN_GENERAL_PARAM_OPT_AP_TX_POWER,…)
  • sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, WLAN_GENERAL_PARAM_OPT_COUNTRY_CODE,…)
  • sl_WlanSetMode()
  • sl_EventMaskSet()
  • sl_NetAppStart()
  • sl_NetAppStop()


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/pref.net
  • sl_WlanProfileAdd()
  • sl_WlanProfileDel()


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
4
/sys/pmcfg.ini
sl_WlanPolicySet(SL_POLICY_PM,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/ipcfg.ini
  • sl_NetCfgSet(SL_IPV4_STA_P2P_CL_STATIC_ENABLE,IPCONFIG_MODE_ENABLE_IPV4,…)
  • sl_NetCfgSet(SL_IPV4_STA_P2P_CL_DHCP_ENABLE,IPCONFIG_MODE_ENABLE_IPV4,…)
  • sl_NetCfgSet(SL_IPV4_AP_P2P_GO_STATIC_ENABLE,IPCONFIG_MODE_ENABLE_IPV4,…)


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/devname.cfg
sl_NetAppSet (SL_NET_APP_DEVICE_CONFIG_ID,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/dhcpsrv.cfg
sl_NetAppSet(SL_NET_APP_DHCP_SERVER_ID,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/httpsrv.cfg
sl_NetAppSet(SL_NET_APP_HTTP_SERVER_ID,…)
  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/mdns.cfg
  • sl_NetAppSet(SL_NET_APP_MDNS_ID,…)
  • sl_NetAppMDNSRegisterService()
  • sl_NetAppMDNSUnRegisterService()


  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2
/sys/smartconfigkeys.cfg
Creation via Uniflash only.

Invocation via sl_WlanSmartConfigStart()

  • When Exit Reset
  • When Exit HIB
  • User Initiated


User Initiated
2


Flash minimal size

The minimal size of a flash is determined according to the memory space occupied by all system and configuration files.
As described earlier, user can either reserve the entire space or customize and reserve only the required space. In the latter case, extra caution should be taken since not preserving enough space may cause system unexpected behavior.

The following table marks the full memory consumption in case all system and configuration files are used.


CC3100

CC3200

File system artifacts (FAT, reserved blocks)
20KB
20KB
ServicePack
264KB
264KB
System & Configuration
200KB
200KB
MCU scheme with fail-safe
N/A
512KB
MCU scheme from OTA example
N/A
776KB
Total
484KB
996KB/1260KB

NoteNote:

  1. 996KB is for MCU scheme with fail-safe option whereas 1260KB is for MCU scheme from OTA example where all MCU images are created with no fail-safe. The decision mechanism is implemented in host.
  2. If the “Over The Air” example provided by TI is used as a reference, then the MCU application binaries need not be created as “fail safe” ,as the primary and back-up images are stored as distinct files in the file system
The user has to select a flash large enough to fit the application code and required data files. Note that flash devices are available in the sizes, 8Mbit, 16Mbit, 32Mbit, 64Mbit and 128Mbit.

Implementing file system features from host processor

Overview

Users may find it frustrating that SimpleLinkTM host driver does not expose some file system capabilities that are considered “built-in”. These features include file listing, occupied/free space and file appending. The reason these features are not part of the file system is stemming from the fact that the file system was originally designed to serve only the internal cores of the device. Since it is impossible to add such features as patches, the current production devices would lack these services from the device. However, this paragraph offers guidelines on how to implement such features in host application.

File listing

Requirements

  • Users should keep and maintain a list of all user filenames created from host
  • Full list of all system and configuration filenames is required. It can be found under System and Configuration files paragraph
  • If allocated size per file is also required:
    • Users should keep and maintain for each user file its allocated size (either the size of the content or the maximum size argument)
    • Full list of all system and configuration file sizes is required. It can be found under System and Configuration files paragraph
  • Knowledge of how to accurately calculate the occupied memory space per file. It can be found under User file mathematics

Procedure

The procedure for listing the files and their respective allocated space is as follows:

  1. For every user file created, keep the following information
    1. Filename
    2. Calculate file size according to User file mathematics
  2. Loop over all user files and print
    1. Filename
    2. Calculated size
  3. Loop over all system/configuration files, invoke fsGetInfo() API and conclude:
    1. If return value is SL_FS_ERR_FILE_NOT_EXISTS, file does not exist and thus should not be printed. Else, the file exists and should be printed along with the allocated size
    2. If return value is SL_FS_ERR_TOKEN_IS_NOT_VALID, it means the file is secured but exists. This return value applies to the following 3 files:
      1. /tmp/fcon.frm
      2. /sys/pref.net
      3. /sys/smartconfigkeys.cfg
In this case, the file exists and should be printed along with the allocated size.

The following figure illustrates the procedure:

File_listing_flow

Free/occupied space

Requirements

  • Users should keep and maintain a list of all user filenames created from host
  • Users should keep and maintain for each user file its allocated size (either the size of the content or the maximum size argument)
  • Knowledge of how to accurately calculate the occupied memory space per file. It can be found under User file mathematics
  • Full list of all system and configuration filenames and sizes are required. It can be found under System and Configuration files paragraph

Procedure

The procedure for calculating free/occupied space is as follows:

  1. Initialize the free space to the size of the flash (as formatted by Uniflash) and the occupied space to 0. Units are blocks (of 4KB)
  2. Account for FAT and the reserved blocks
    1. Decrease free space by 5 blocks
    2. Increase occupied space by 5 blocks
  3. For every user file created, calculate the allocated size (refer to User file mathematics)
  4. Loop over all user files and for every file apply
    1. Decrease free space by the allocated size in blocks
    2. Increase occupied space by the allocated size in blocks
  5. Loop over all system/configuration files, invoke fsGetInfo() API and conclude:
    1. If return value is SL_FS_ERR_FILE_NOT_EXISTS, file does not exist and thus counters should remain, else, if no error is returned, followings should be updated:
      1. Decrease free space by the allocated size in blocks
      2. Increase occupied space by the allocated size in blocks
    2. If return value is SL_FS_ERR_TOKEN_IS_NOT_VALID, it means the file is secured but exists. This return value applies to the following 3 files:
      1. /tmp/fcon.frm
      2. /sys/pref.net
      3. /sys/smartconfigkeys.cfg
In this case, the file exists and followings should be updated:
  1. Decrease free space by the allocated size in blocks
  2. Increase occupied space by the allocated size in blocks

The following figure illustrates the procedure:

Free_occupied_space


File appending

Requirements

No preliminary requirements.

Procedure

There are several options to implement file appending from host application. All options are based on read->modify->write.
The assumption is that the host processor does not have enough resources to read the entire file to its space so the serial flash needs to be used as a mediator.
The proposed approach is to keep 2 files that hold the same copy but in different time instances. The update/append is applied to the “older” instance (based on the “newer” instance) and upon successful update/append, it becomes the “newer” instance. So practically this approach implements rollback option in host level and does not make use of the file system fail-safe option.

The procedure for file appending is as follows:

  1. Create a file and write some content into it. The file would be denoted as file1
  2. Initialize a counter to file1 denoted as file1_counter and initialize it to 1
  3. The other instance is denoted as file2 and its counter file2_counter is initialized to 0. The “newer” file at this point is file1 and its counter indicates it (i.e. file1_counter> file2_counter)
  4. Now let’s say an update/append is required:
    1. Look for the “older” instance. If (file1_counter<file2_counter)  file1 is the “older” instance, otherwise  it is file2
    2. Open the “newer” file for read
    3. Open the “older” file for write
    4. Read from the “newer” and write to the “older”. At this point, any power fail would not corrupt the file as the “newer” instance is opened for read
    5. When reading from “newer” and writing to “older” is done, apply the followings:
      1. Update/append to “older” instance
      2. Close the “newer” instance
      3. Close the “older” instance
      4. Increase the counter of the “older” instance by 2 so it becomes the “newer” instance
  5. Go to step #4 for further operations

Note that this approach is not using more space than a regular fail-safe file. It is just that the fail-safe is implemented in host application. Additionally, the write operation which consume much time (as it involves flash erasure) is kept as minimal as possible.

The following figure illustrates the procedure:

File_appending_flow




Factors to consider in designing with serial flash

Serial Flash Vendor and part number selection

Serial flash components from many vendors may appear to be equivalent if only considering memory capacity, however close examination of the serial flash datasheets can reveal significant parametric differences between components in areas such as operating voltage and access times. The serial flash components listed in TI BOM tables for CC3100 and CC3200 reference designs should be used since these serial flash components have been system tested by TI.

In addition, the below table lists the different parts which were tested with the CC3100R1/CC3200R1 device and were found to perform reliably. TI performs a series of system level tests using these parts to ensure robustness under various operating conditions. However, this does not guarantee data integrity under extreme operating conditions as specified in subsequent sections of this document.

Vendor Part number Size Voltage power Recommendation
Adesto AT25SF081 8Mbit 2.5-3.6v Battery & Line powered systems
Adesto AT25SF161 16Mbit 2.5-3.6v Battery & Line powered systems
Winbond W25Q80BL 8Mbit 2.3-3.6v Battery & Line powered systems
Spansion S25FL208K 8Mbit 2.7-3.6v Line Powered systems
Macronix MX25V8006E 8Mbit 2.35-3.6v Battery & Line powered systems
ISSI IS25LQ016B 16Mbit 2.3-3.6v Battery & Line powered systems
ISSI IS25LQ032B 32Mbit 2.3-3.6v Battery & Line powered systems
Micron N25Q128A 128Mbit 2.7-3.6V Line Powered systems
Shanghai Fudan Micro FM25Q08 8Mbit 2.7-3.6V Line Powered systems

NoteNote: Important : The previously suggested(prior to May 2015) s-flash which was Micron part number M25PX80 and others in the same series, are no longer recommended!

NoteNote: : The operating voltage of the WiFi sub-system is limited by the operating range of the s-flash. This has to be accounted for by the user in the overall system design.

Supported flash types

For compatibility with the CC3200/CC3100 device, the SFLASH device must support the following commands and format:

  • Uniform sector erase size of 4K
  • Command 0x9F (read the device ID [JEDEC]). Procedure: SEND 0x9F, READ 3 bytes.
  • Command 0x05 (read the status of the SFLASH). Procedure: SEND 0x05, READ 1 byte. Bit 0 is busy and bit 1 is write enable.
  • Command 0x06 (set write enable). Procedure: SEND 0x06, read status until write-enable bit is set.
  • Command 0xC7 (chip erase). Procedure: SEND 0xC7, read status until busy bit is cleared.
  • Command 0x03 (read data). Procedure: SEND 0x03, SEND 24-bit address, read n bytes.
  • Command 0x02 (write page). Procedure: SEND 0x02, SEND 24-bit address, write n bytes (0<n<256).
  • Command 0x20 (sector erase). Procedure: SEND 0x20, SEND 24-bit address, read status until busy bit is cleared.

Frequent Write Operations

Serial flash components are subject to a lifetime maximum number of write/erase cycles. This should be accounted for when designing the system application software.

SFLASH write endurance limitations

A typical serial flash guarantees a data endurance of 100K write cycles per sector and 20 years data retention. The below table details the maximum number of writes per day to the same sector that will allow the device to operate for a given number of years

Desired product Life in Years Max Writes/Per Day
20 14
15 18
10 27
5 55

Max number of writes/day = 100000 / (product life in years * 365)

In a CC3100 and CC3200 system the serial flash may be written by the user application or by periodic activity of the CC3100/CC3200 on-chip firmware. The total number of writes from these two sources should not exceed the budget for maximum number of flash writes calculated from the desired product lifetime.

S-flash access by the WiFi system

The CC3100\CC3200 uses the external SFLASH required for its basic functionality.

The SFLASH content is organized by a file system and every creation or modification of a file translates to operations on the SFLASH.

The main files stored in the SFLASH are divided to two main groups:

System Files:

  • Service Pack binaries
  • System operation: Calibrations, Certifications
  • Configurations: WiFi, Device (role), Profiles, Time, Etc’
  • Networking: IP, ARP tables

Note: The system files are modified by the CC3100/CC3200 upon start-up and on an as-needed basis.

User Files:

  • CC3200 MCU image
  • HTML files
  • Temporary files – any file been used

Note: Note that the user can trigger file creations or write operations at unpredictable times

Sudden Power off ( Power removal during a write/erase phase)

All systems using serial flash are vulnerable to the effects of sudden power removal. As noted in most serial flash datasheets, a data corruption may occur if the power is removed while a write/erase operation is in progress. This can happen if the system operating voltage goes below Vmin of the serial flash (2.3V typical) before the erase/write operation is completed. A typical scenario is shown in the graph below.

S-flash Image 02.png

This scenario may occur in battery or line powered end equipment.

  1. Battery Powered Products: Removal of battery from the product without a soft shutdown.
  2. Line Powered Products: Electrical supply failure or sudden unplugging without a soft shutdown.

The sections below explain how the potential for serial flash corruption can be minimized in both types of end equipment.

Battery powered systems

In a battery powered system, there is a chance that sudden removal of power could coincide with an ongoing serial flash access. The chance of this happening can be minimized by making it difficult to remove the batteries while the product is in use, for example in a Wi-Fi weighing scale, where the user stands on the scale when it is in use. Alternatively product instructions could discourage users from removing the batteries while the product is in use. In systems desiring a higher degree of protection a soft power down push-button could also be provided that maps to a GPIO of the system processor, giving it advanced warning that the user wants to remove the battery. In such a system the processor could use an LED to indicate that soft shut down has completed and that the batteries can be removed.

Line powered systems

In a AC mains line powered system, the failure of the grid can cause the supply of the Wi-Fi subsystem to drop suddenly. In the unlikely event this coincides with the erase operation of the serial flash, there is a chance of data corruption. One of the ways to minimize the chance of a flash corruption would be to ensure that the DC voltage ramps down slowly after the input power is removed. This can be achieved with the help of bulk capacitors which hold the charge while input supply is removed. The embedded system would sense the sudden fall in the input voltage and then initiate a soft shutdown of the Wi-Fi sub-system thereby safely completing all serial flash operations before Vflash-min is reached. The charge stored on the capacitor would be used during this brief interval. Such a sequence is illustrated in the diagram below

Shutdown sequence for line powered applications

The value of the capacitor has to be estimated from the maximum time for the s-flash erase operation, voltage thresholds, and the current drawn by the system.




Design recommendations for ensuring the integrity of the power supply to the serial flash

Overview

CC3100 and CC3200 are proven robust WLAN solutions when operated in accordance with the supply and signal parameters described in the datasheet with the latest Service Pack [1.0.1.6] . This document describes design techniques to maximize system robustness including minimizing the possibility of inadvertent corruption of the serial Flash memory connected to CC3100 or CC3200 for battery powered and hybrid line/battery powered designs. The techniques described focus on ensuring the integrity of the power supply to the serial flash to avoid situations where the supply voltage may fall below the minimum threshold specified by the serial flash manufacturer which may cause corruption of flash data during write or erase operations. Depending on the nature of such corruptions systems may or may not continue to operate, and in some cases physical access to the system may be required in order to recover. This section will cover design techniques to maximize system robustness in battery powered and hybrid line/battery power systems.

Key points

  • This document applies primarily to systems that are:
    • Powered from batteries or
    • Powered by hybrid line and battery scheme
    • This includes designs where the CC3x00 connects directly to the battery and systems where a DC2DC converter is used between the battery and the CC3x00
  • If the application uses a DC2DC converter then designers should ensure the output of the DC2DC converter satisfies the supply requirements of both the CC3x00 and the attached serial flash device.
  • CC3x00 devices should be enabled only when supply voltage is greater than or equal to 2.3V. This minimum is typically determined by the serial flash minimum supply voltage and not the CC3x00 minimum supply voltage which is defined in the datasheet as 2.1V. The key point is that the supply must tolerate a CC3x00 transmit current or calibration current load, as specified in the datasheet, without sagging below 2.3V so the unloaded supply voltage may have to be greater than 2.3V to account for internal resistance effects of the supply.
  • The supply voltage applied to the CC3xxx should never exceed 3.8V, specified as the absolute maximum supply voltage in the datasheet. And corresponding absolute maximum voltage constraints from the chosen serial flash datasheet must also be followed.
  • Follow TI serial flash design guidelines for CC3x00:
  • Minimize the number of application writes to flash, especially after reset. For example make sure that application configuration writes to flash happen only at initial reset and not every time the CC3x00 is reset.
  • For maximum system robustness consider using a serial flash like the Macronix MX25R6435.This device supports a wide supply voltage range which tends to improve system immunity to supply fluctuations
  • Keep in mind that CC3x00 WLAN transmission can result in sudden increases in the loading on the power supply and this may result in a momentary decrease in supply voltage. Consult section 4.5 of the CC3x00 datasheet describing how to handle supply brown out. Specific design scenarios are described in the table below.


Design scenarios

Scenario Recommended Approach
All MCU hosted CC3100 systems Host MCU should own the task of monitoring VBAT to ensure it never drops below 2.3V even under full load conditions.
Legacy Self-hosted, standalone CC3200 For legacy systems using SDKs prior to Service pack 1.0.1.6 and SDK 1.2.0 the CC3200 initialization sequence will turn on the internal network processor and may initiate Wi-Fi activity prior to application execution on the MCU. This can cause a sudden increase in the power supply loading. In these systems if there is a possibility that such loading can cause the supply voltage to sag below 2.3V then the supply voltage should be monitored by a device external to CC3200.
New Self-hosted, standalone CC3200 For new systems using Service Pack 1.0.1.6 and SDK 1.2.0 or later then the CC3200 initialization will not turn on the internal networking processor function so the CC3200 application can start running prior to Wi-Fi activity.

In such a scenario the application code can use the CC3200 A2D converter to monitor battery voltage but keep in mind the A2D accuracy needs to be factored into any decision to activate the NWP for normal operation or not. For more details on optimal detection and handling of consecutive resets owing to supply brownout to maximize system robustness see the last section of this document.

Other comments on circuit and software design: For systems requiring an external DC2DC power converter the TI TPS61029 may be worth considering. An example TI design showing this device in the supply for a CC3200 is located at http://www.ti.com/tool/TIDA-00372


Brown-out mitigation techniques for new self-hosted CC3200 designs

This section describes how to mitigate the effects of a substantially discharged battery on a self-hosted CC3200 system. It is assumed that the CC3200 device is the main controller and has the ability to control all high power components in the system and that Service Pack [1.0.1.6] and SDK [1.2.0] or later have been installed.

The problem: The brownout problem can occur when operating with a substantially discharged battery which has enough energy to power up the CC3200 processor, but not enough to power the Wi-Fi transmitter. This can cause a loop where the CC3200 device powers up, reaches the point where it does some high power activity, this activity causes the battery voltage to drop below brown out threshold causing a reset. Once reset, the device consumes no power, the voltage rises back above brown out threshold and the device powers up again.

The solution: The suggested approach to avoid the above cycle is to use the secondary bootloader (like the one used in over-the-air updates) to load the user application and keep track of whether the application was loaded successfully (without causing another brown out event). This is done by keeping a counter in an on chip register (OCR) which will most likely be retained if voltage drops due to excessive power usage. The power up flow should be as described in the scheme below:


Recommended best practices

The following list of best design practices can help improve the overall reliability of the serial flash by minimizing frequent writes

1. Avoid frequent usage of API functions that write to the SFLASH
2. The creation and deletion of files also require updates to the FAT table – as a good practice avoid deleting files when not required, rewrite can be done over existing file. This will reduce unnecessary access to the FAT table
3. Avoid accessing the SFLASH when the voltage is below the minimum SFLASH operation voltage
4. Make sure you choose your SFLASH based on the system you are developing – for example when using a SFLASH rated for 2.7 V you must ensure that supply remains above 2.7V
5. Adding an indication before power off (graceful shutdown) and making a call to sl_stop in the program is always the best approach


Implications of Data integrity compromise to CC3100/CC3200

The CC3200 system may become inoperable if the MCU image is corrupted. In the case of the CC3100 or CC3200, where the FAT or service pack are corrupted, the device may start up with a ROM image instead of the correct service pack. There is also a chance that the device would lock-up without any valid response.

Recovery

To recover from serial flash corruption the serial flash has to be reformatted and reprogrammed using the UART interface

Links