4 Replies Latest reply on Oct 21, 2020 5:37 AM by LePo_1062026

    PSoC5LP : Behavior of emFile component

    MaMi_1205306

      Dear Sirs and Madams,

       

      Please tell us some of the behaviors of the emFile component we are considering.

       

      1.

      This component does not have a Start and Stop API.

      So is it correct to recognize that it is automatically booted within the boot process?

       

      2.

      Does the emFile component access the SD card after it launches automatically?

      And does the operation change when the SD card is inserted and when it is not inserted?

       

      3.

      We are using Hibernate mode with PSoC5LP.

      Call the emFile pin to goes 'L' and emFile_Sleep as shown below.

       

      emFile_Sleep();

      CyDelay(10);    //This API is absolutely necessary

      SD_PIN_DETECT_Write(0);

      emFile_SPI0_CS_Write(0);

      emFile_mosi0_Write(0);

      emFile_sclk0_Write(0);

       

      Calling CyDelay (10) or CyDelay (5) will successfully enter Hibernate mode.

      However, if you set this CyDelay to 1ms, you will not be able to enter Hibernate mode.

      Do you know some reasonable processing time to stop emfile?

       

      We think that the time between 'emFile_Sleep();' and 'SD_PIN_DETECT_Write(0);' is very important.

       

      Alternatively, the SPI UDB data of SD card is backed up in the emFile_Sleep API.

      Is it not desirable to change the SD card IO with the Pin_Write API?

       

      Regards,

        • 1. Re: PSoC5LP : Behavior of emFile component
          AikoO_51

          For Question1, The emFile isn’t getting operated with boot process automatically, but by written project.

           

          According to emFile component datasheet, the emFile library routines automatically initialize and enable the emFile component. As file system APIs of the emFile library, it’s existing to initialize File system of emFile.

           

          For file system APIs of the emFile library, there are descriptions in the emFile User Guide, Chapter 4.

          It must be included the FS.h header file in your main.c file to use file system APIs.

           

          You can follow a code example in PSoC Creator “emFile_example”, which is also used file system APIs.

          • 2. Re: PSoC5LP : Behavior of emFile component
            LePo_1062026

            MaMi,

             

            Aiko probably is a better person to address most of your questions. However, I give it a try.

             

            1.

            This component does not have a Start and Stop API.

            So is it correct to recognize that it is automatically booted within the boot process?

            emFile component is really a 'middleware' library.  When you insert the emFile component it is 95% SW API calls.  However, it does allocate an internal SPI comm component.  As a library, you don't need a Start/Stop.  Apparently they worked out that on the first call to a media access API call, they must Start() the SPI comm component.

             

            Once emFile component is compiled during the Application Build phase, the SPI comm component is built and loaded at boot time.  I am not aware of any other emFile code being run at boot time.

             

            2.

            Does the emFile component access the SD card after it launches automatically?

            And does the operation change when the SD card is inserted and when it is not inserted?

            To my understanding, emFile SD access only occurs when your application code makes API calls.  Therefore I am not aware of any SD accesses not requested by your application.

             

            It is my understanding using the latest emFile version available for the PSoC5 there is no mechanism IN emFile to determine an eject or insertion of the SD card.  It is my understanding that emFile does perform some caching of file/directory information when the SD is accessed.

             

            There are two ways to address the lack of eject/insertion:

            • emFile provides some API calls to 'flush' cache.  This allows the next SD access to read fresh info in the case of a new insertion or read if a SD card is available.
            • Segger (author of emFile) has recommended in the past to read your SD "card present" switch using a PSoC input.  You can poll this simple input or attach a ISR.  When you receive an ISR, you can 'flush' cache on an eject or read the root directory on an insertion.

            3.

            We are using Hibernate mode with PSoC5LP.

            Call the emFile pin to goes 'L' and emFile_Sleep as shown below.

             

            emFile_Sleep();

            CyDelay(10);    //This API is absolutely necessary

            SD_PIN_DETECT_Write(0);

            emFile_SPI0_CS_Write(0);

            emFile_mosi0_Write(0);

            emFile_sclk0_Write(0);

             

            Calling CyDelay (10) or CyDelay (5) will successfully enter Hibernate mode.

            However, if you set this CyDelay to 1ms, you will not be able to enter Hibernate mode.

            Do you know some reasonable processing time to stop emfile?

             

            We think that the time between 'emFile_Sleep();' and 'SD_PIN_DETECT_Write(0);' is very important.

             

            Alternatively, the SPI UDB data of SD card is backed up in the emFile_Sleep API.

            Is it not desirable to change the SD card IO with the Pin_Write API?

            When the emFile_Sleep() is executed, it must do the following:

            • Flush all queued outgoing cache to the SD card.
            • Cache all queued incoming data to RAM from the last Read operation.
            • Wait until the SPI comm is "DONE"
            • Preserve the SPI comm state.
            • Turn off any emFile specific Timers.

            Once the above is complete, then a low-power state is possible.

            I don't know if emFile_Sleep() is a blocking command or not.  If not blocking, then a CyDelay() may be necessary.

             

            About writing to the SPI comm component pins before sleep:

            Is it not desirable to change the SD card IO with the Pin_Write API?

             

            Normally the SPI comm is configured with the pins in the inactive state when stopped or 'done'.   Are you seeing excessive current draw in Hibernate mode?

            What is the current draw with your pin Write commands

            Suggestion:  Get rid of the pin Write commands after the emFile_Sleep().  Check the current draw.  This will give you empirical data to make a decision.

             

            Len

            • 3. Re: PSoC5LP : Behavior of emFile component
              MaMi_1205306

              Len-san,

               

              Thank you for your always appropriate comments.

              So it will be helpful.

               

              1.

              I understand that it is starting automatically in the library.

               

              2.

              I didn't know that emFile wasn't accessing SD unless I called it with the API.

               

              3.

              I checked the contents of the enFile_Sleep API.

              We understand that only the serial communication settings are saved during the sleep process.

              We think it's probably due to the time it takes to store UDB settings with non-blocking code.

              It was also possible to judge from the fact that the process of writing to the pin after emFIle_Sleep did not reach the expected value.

               

              We think that writing to the pin after emSleep API is causing the problem behavior, so this process should be commented out.

               

              Regards,

              • 4. Re: PSoC5LP : Behavior of emFile component
                LePo_1062026

                MaMi,

                 

                I hope to always be helpful.

                We think that writing to the pin after emSleep API is causing the problem behavior, so this process should be commented out.

                Segger doesn't provide source code for the emFile library.  Therefore you can't directly find out what is going on in the emFile_Sleep() call.

                (If you want an adventure, you can reverse-engineer the assembly code)

                 

                Commenting out the pin API calls is a good idea.   When sleeping, check the pin states are where you need them. 

                 

                Another test you can use is to take a 1K resistor, place one end on the signal and the other end first on VDD then on GND.   When you short the resistor to VDD, measure the voltage across it.   When you short it to GND, measure the voltage.   This test will give strong clues how the emFile_Sleep() sets these signals. 

                 

                Len