SWRA657 June   2020 CC3100 , CC3200

 

  1.   SimpleLink Wi-Fi CC3100, CC3200 Serial Flash
    1.     Trademarks
    2. 1  Introduction
    3. 2  How File System Content Gets to the Serial Flash
    4. 3  File System Guidelines
    5. 4  User File Mathematics
    6. 5  System and Configuration Files
      1. 5.1 Description
      2. 5.2 Memory Consumption
        1. 5.2.1 CC3200 Use Case
        2. 5.2.2 Host Driver Mapping
        3. 5.2.3 Minimum Flash Size
    7. 6  Implementing File System Features From Host Processor
      1. 6.1 Overview
      2. 6.2 File Listing
        1. 6.2.1 Requirements
        2. 6.2.2 Procedure
      3. 6.3 Free/Occupied Space
        1. 6.3.1 Requirements
        2. 6.3.2 Procedure
      4. 6.4 File Appending
        1. 6.4.1 Requirements
        2. 6.4.2 Procedure
    8. 7  Factors to Consider in Designing With Serial Flash
      1. 7.1 Serial Flash Vendor and Part Number Selection
      2. 7.2 Supported Flash Types
      3. 7.3 Frequent Write Operations
        1. 7.3.1 Serial Flash Access by the Wi-Fi System"
        2. 7.3.2 Seral Flash Access by the WiFi System
          1. 7.3.2.1 System Files
          2. 7.3.2.2 User Files
      4. 7.4 Sudden Power Off (power removal during a write/erase phase)
        1. 7.4.1 Battery Powered Systems
        2. 7.4.2 Line Powered Systems
    9. 8  Design Recommendations for Ensuring the Integrity of the Power Supply to the Serial Flash
      1. 8.1 Overview
      2. 8.2 Key Points
      3. 8.3 Brown-Out Mitigation Techniques for New Self-Hosted CC3200 Designs
    10. 9  Recommended Best Practices
    11. 10 Implications of Data Integrity Compromise to CC3100/CC3200
      1. 10.1 Recovery
    12. 11 References

6.4.2 Procedure

There are several options to implement file appending from the 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 two 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 (file1_counter> file2_counter).
  4. 4. Now, if 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 does not use more space than a regular fail-safe file. The main difference is that this method implements fail-safe functionality in the host application. Additionally, write operations and flash erases are kept to a minimum.

Figure 4 illustrates the procedure:

swra657-file-appending-flow.gifFigure 4. File Appending Flow