• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 447 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC3220SF: Custom Factory Default Process

CC3220SF: File System Actual max Size of Secure-No Signature File

Trevor Parsh
Intellectual 660 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH

I've been digging into max file sizes for non-secure and secure files on the file system.  One thing I noticed is that the file header space for each file is 512 bytes, not 500 as TI documentation claims.  Beyond this, it seems like secure files are treated differently (again, no signature).  Either there are additional bytes stored with each file or files are saved as fail-safe even if the fail-safe flag is not set (this all I can think of).  So, why if I set my maximum file size to be (4096 - 512) bytes is the total space taken up in file system land 8192 bytes?

  • 0
    TI__Mastermind 28285 points

    Trevor,

    Can you share a screenshot of your file attributes in Uniflash? What you are describing sounds like fail safe, and if you disable it then this should not occur.

    Best,

    Vince 

  • 0 in reply to Trevor Parsh
    Intellectual 660 points

    I also write a few secure files from my M4 application and I see the same results. If I remove the secure attribute, the size is what I expect

  • 0 in reply to Trevor Parsh
    TI__Mastermind 28285 points

    Trevor,

    For the Max file size, can you reduce that in the GUI? The max size is the maximum you expect that file to ever grow. If this file will never grow, then you can reduce the overall size.

    Best,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 660 points

    I could alter the size, but that's not what I really care about too much.  I'm more curious about the fact that there is some kind of stipulation around having a file marked as secure that seems to be undocumented as far as I can tell.

    Beyond that, I do not expect the particular files that I am referencing to grow that large, but I want to basically tell the file system that the entire block of memory could be used and not have to have the file deleted/re-created if for some reason the file does grow larger than the max size in the event that I choose a max size that is less than the maximum number of bytes that may be used for a file that only requires one block of flash to be stored.

  • 0 in reply to Trevor Parsh
    TI__Mastermind 28285 points

    Trevor,

    Sorry for the delay. I'm still investigating this and will get back to you as soon as possible.

    Best,

    Vince 

  • 0 in reply to Vincent Rodriguez
    TI__Mastermind 40965 points

    Hi Trevor,

    I am trying to replicate what you're seeing with the overly large file allocations for secure files and can't seem to get the same results.

    When I create a file of exactly 4096-512 = 3584 bytes in size, it seemingly doesn't matter if I use the secure flag or not. Both a secured file of that size as well as a non-secured file of that size results in the max size/ Sflash space allocated being 3656 bytes as reported by the CC3220 filesystem after the file is written.

    Looking at the NWP source code, it looks like the header space allocated is the same between a non-secured file and a secured file. Of course, a secure file will use up more of the allocated header space, but the amount allocated is based on the max possible header size and so every file is given an equal size header.

    However, as I cannot replicate your setup, I cannot test out any ideas I have on my end. Given the information above, does it help clear up some confusion on your end, or do you have further questions that need clarification?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 660 points

    thanks for looking Michael.  This is good enough.  It bothers me that we get different results, but I was more interested in what the structure of a file stored in the file system when comparing secure and non-secure files.  What I thought should happen is what you say should happen. The file system seems to be behaving differently for me, as stated I suppose, but that is fine for now.  There really isn't time to delve deeper into this on my end. We'll just live with the way the system behaves right now