• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 40 subscribers
  • Views 394 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.

CC3235S: some problems about the file system

Zhiyuan HE
Prodigy 50 points
Part Number: CC3235S

Hi,

I have serval problems about the file system of CC3235S.

1. I know sl_Fsclose(fileHdl, 'A', 1) means abort function, and it will set the nonactive copy as the active one if the file is opened with FAILSAFE flag. However, it is strange when I write the test code to verify the file system, the abort function acts as the normal close(sl_Fsclose(fileHdl, certificate, signature, signature_len)). Although I can ignore this strange problem, I'm not sure wheather it will bring some other problems for me in the future.

2.I have referred the documentationintroducing file system, which shows servicepack is a special file and when the host writing the service pack, the sl_FsClose() function should receive a NULL certificate name and a NULL signature. The sl_FsClose() function returns -10363(SL_ERROR_FS_ILLEGAL_SIGNATURE) when I follow the guide, but another strange problem happens,  sl_FsClose() succeeds if i give an arbitrary string to signature, for example, sl_FsClose(fileHdl, NULL, "123", 3), sl_FsClose(fileHdl, NULL, "ab", 2), and so on.

In short, my main problem is why the documentation is different from what I tested, which is really confusing.

Some other information:

Certification File Name: dummy-root-ca-cert

signature file name: dummy-root-ca-cert-key

I'm not English native speaker, so if I didn't express clearly, please feel free to ask me, thank you.

  • 0
    TI__Mastermind 40965 points

    Hi,

    Have you ensured that you flashed the latest CC3235 servicepack from the CC32xx SDK onto the device following the instructions here:http://dev.ti.com/tirex/explore/node?node=ABEoqU9o3snoxDcmIpW0EA__fc2e6sr__LATEST

    The latest servicepack in particular fixes a filesystem fs_Close() bug that may have an impact on the behavior you are noticing.

    Please let me know if you still run into your issue after updating to the latest 4.8.0.8 servicepack.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 50 points

    Hi Michael,

    Thank you for your reply.

    My SDK version is 4.20.00.07(02 Jul 2020), so I think maybe the servicepack(sp_4.7.0.3_3.1.0.5_3.1.0.26.bin) is the lastest. In order to make sure the servicepack is flashed onto the device, I use sl_DeviceGet() and sl_FsGetInfo() to get the ouput as follow.

    In fact, if I don't flash the servicepack onto the device, everything seems as same as flashing it, except the result of sl_DeviceGet() and sl_FsGetInfo(), the fs_Close() function is still strange.

    e2e.ti.com/.../602880

    There was another question about  fs_Close() of servicepack 3 years ago but it has not been resloved. My problem is similar to this one, but the difference is that the signature provided with SDK isn't the only one to close servicepack, an arbitrary string will be OK.

  • 0 in reply to Zhiyuan HE
    TI__Mastermind 40965 points

    Hi,

    My apologies, it appears that the latest 4.30.xx.xx release isn't online quite yet. It should be released within the next week or two, and that upcoming SDK release will have a new CC323x servicepack that will most likely address your issue.

    The new SDK is still in the final stages of testing and as such cannot be provided publicly at this time. If you have an urgent need for a fix for that sl_FsClose() bug, please contact your local TI field sales team. They will be able to help provide the engineering builds of the SDK privately for test and development purposes.

    Otherwise, I appreciate your patience in waiting for the updated release. Please keep monitoring the CC32xx SDK download page, and let me know on this thread or on a new thread if this thread is locked if the new servicepack does not fix your issue.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 50 points

    Hi Michael,

    Thanks a lot, my problem is not urgent so I will wait for a new service pack. Two days later is China's national day, so I'm going to have one week hoilday and my reply will be a bit late.

    Thanks again.

  • 0 in reply to Michael Reymond
    Prodigy 50 points

    Hi Michael,

    You are right, the lastest servicepack has solved most of my problems, but I still can't use sl_FsClose(FileHdl, NULL, NULL, 0) to close servicepack when writing it. It is not a serious problem for me because I can solve it when I use a specfic signature instead of "NULL", but it will be great if you know the reason.

  • 0 in reply to Zhiyuan HE
    TI__Mastermind 40965 points

    Hi,

    Thank you for verifying that the new servicepack fixes your issues.

    As for writing the servicepack, please provide the file signature when calling sl_FsClose(). Which document are you using as reference for the expected sl_FsClose() behavior?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 50 points

    Hi Michael,

    Look at this, page 133, 

    However, I just find another document showing like this:

    page 21, 

  • 0 in reply to Zhiyuan HE
    TI__Mastermind 40965 points

    Hi,

    Thanks for pointing out the exact location where you found the note that sl_FsClose() with a null signature works for the servicepack. I will file that as a literature bug and ensure it gets corrected. Please provide the file signature of the servicepack when performing an sl_FsClose on it.

    Regards,

    Michael