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.

TDA2PXEVM: SD Card folder creation issue with PSDK3.3

Part Number: TDA2PXEVM
Other Parts Discussed in Thread: TEST2

Hey,

I am using tda2pxevm and created a usecase where I encode captured data and send the encoded frames to nulllink where I copy the encoder output buffer (NULL_LINK_COPY_TYPE_BITSTREAM_MEMORY) and then write those frames to sd card.

Every filename includes the timestamp of the respective frame. I only record 1 frame each 30seconds.

Simply writing those frames to sd card work fine, every frame is labeled with the respective timestamp.

Now I want to create directories for every test. This means everytime the usecase is called I want to check if a directory (for example "test1") is already there and if so another directory ("test2" and so forth) should be created.

I already approached it in several ways but here is how I do this now in a very simple and basic way.

So if it is not possible to change the directory as planned, I will create this directory since it is not there yet, otherwise it should be able to change to that directory. 

I then use this path with Utils_fileWriteFile function.

This works for like 2 folders but then it does something of which I just can´t figure out why and how exactly it is happening. It desroys my appimage and mlo file?! it suddenly shows both of them are 0kb big and I obviously can´t start the application again.

On the other hand if I create the different folders myself and just switch after couple of minutes to a different folder I want the frames to be stored in(programmed in usecase) it works without any problem.

I somehow think that the api is buggy and that the mkdir functions don´t setup the directory trees properly.

Could you clarify where I might be making mistakes or if for any reasons the api might not even be able to do stuff like this?

best regards,

Nicolas Rausch

  • Sorry forgot to insert my code.

    Here it is:

    (only the part where I check for existing directories and create new ones)

  • Sorry it is PSDK3.5 that I am using, not 3.3 as mentioned in the title!

  • Hi Nicolas,

    I had a look at your code and I am a little bit concerned about if it will work as expected. Here is what I think will happen:

     - on first call we try to enter "test1", it fails so we proceed and create it.
     - on second call first we try to enter "test1" - it is successful, so we go on to the following "eles if" where we try to enter "test2", but note that we are already in "test1" directory so actually try to enter "/test1/test2" - it fails so we go to the root dir and create "test2"
     (now we have "test1" and "test2" in the root dir as we wanted)
     - on third and consecutive calls the flow will be the same as second - we enter "test1" successfully, try to enter "test2" from within it, fail, go to the root and try to create "test2" which already exists.
     
    Can you check if my findings are correct or I miss something.


    Note that calling mkdir with existing directory ideally should just return some error and not cause the problems with the other files, but let's first try to check if the function logic works as expected.

    Regards,

    Yordan

  • Hi Nicolas,

    Please ignore my previous post - I had a look at ChainsCommon_Osal_fileChDir() implementation and it seems to add "/" to the dirname so it always try to enter a subdirectory of the root dir, and your function should work as expected.

    I will ping VisionSDK experts to look at this, they will respond here soon.

    Regards,

    Yordan

  • Allright,

    thank you!

    best regards,

    Nicolas Rausch

  • Hi,

    Your code seems ok.

    What is the issue are you facing with this.

    Till test 5 it will be able to create and should work fine.

    Regards,

    Anuj

  • Hi Anuj,

    there is a issue if we boot from SD card and run some tests.

    The MLO (opp_plus) and Appimage files are destroyed after this.

    If we run the software with debugger and in debug mode there is everything ok.

    See pictures:

     

    Before:

     

    After:

     

    Best Regards,

    Alex

  • Hi,

    In your code you are creating directories only till test5 folder.

    Then how test7 folder is getting created in your sd card.

    Please add '\' with the folder name with File_mkdir().

    Can you try to create folder 1 by 1 and check after which folder this issue is observed.

    Try this multiple time and check whether its always at same time or its occurring randomly.

    Regards,

    Anuj

  • Hi Anuj,

    I modified the code a bit to get more then 5 test folders.

    Adding for example "\test1" in combination with File_mkdir() didn't create a folder.

    If I run one test turn of the hardware and check the sd card there is everything ok.

    But if I run more then one test in a row the folder creation fails and destroy the other files.

    Regards,

    Alex

  • Hi,

    Can you create a test folder at top level and then  create all your test folder under that.

    Means test/test1 , test/test2 etc.

    Can you check that?

    Regards,

    Anuj

  • Hey,

    I already tried that.

    In this case the appimage and MLO files don´t get corrupted, but inside the main test folder the directories (test1,test2....) get corrupted.

    best regards,

    nicolas rauch

  • Hi,

    This could be a issuen in bios api.

    Can you just create a thread in bios forum that f_mkdir() api is giving weird results.

    Please mention bios version which has been used with VSDK.

    Regards,

    Anuj

  • Hi,

    This is a fatFs driver api which is a third party driver.

    So we have not tested this on regression.

    Can you first try to use a brand new  sd card which has not been formatted even once.

    Even if you see this issue can you please step through f_mkdir function and tell us what going wrong in nonworking case compared to working case

    Regards,

    Anuj

  • Hey,

    the issue is apparently with the _USE_LFN in the ffconf.h.

    The mode is set to 1 by default, but when I set it to 0 to disable long filenames and stick to the 8.3 format everything works fine, but I need longer filenames.

    Also when I used mode 1 with short names the issue appear.

    Switching to case 1 or 2 results in the errors that I am describing.

    You can take a look at the fatlib files to check that.

    best regards,

    Nicolas Rausch

  • Hi,

    Its a 3rd party driver which we use for filesystem.

    And we use it for very minimal requirements.

    Such regressive testing is not done by us.

    Regards,

    Anuj