EMFile record time is too long some times

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
shil_1288831
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins

Hi,

I'm using Psoc 5LP with EMFile component.

I record 400 bytes every 36mSec.

We're measuring the record time from the begining till the record ends.

Most of the times the record time is 10mSec, but some times the record time is between 1sec -3.5 sec.

That means we're losing data to record.

2 questions:

1. why does it happen?

2. How can we make the record time to be constant about 10-20 mSec and not in sec ?

Thanks

Shmuel

0 Likes
26 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Shmuel,

The maximum data of an SD card is 12.5Mbps.   400 bytes in 36msec is definitely within that spec.

What is your SPI clock rate?

Are you using a RTOS like FreeRTOS?

How often does it occur in a 24 hour period?

Without your project, it difficult to make additional guesses on my part.

Suggestion:   You may want to place a "framing" pulse with a spare GPIO before and after the Data_Write function. Monitor this framing signal with a scope.  In addition if you can place another set of scope monitors on the CLK and DO lines of the SD card.   Maybe from these signals, you can find a further clue as to what is going on.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

I didn't find how to attached the project.

I also attached a screen shoot of the write signal.

The SPI clock is 8Mhz Not using RTOS.

The time it accurse is not constant. It can happen after 20 seconds and it can happen after 2 minutes.

Thanks Shmuel EMfile.jpg

0 Likes

Shmuel,

I assume you know how to archive your project.

To attach this archive you need to do the following:

  1. Select "Reply" in the bottom right to a post. 
  2. Select "Use advanced editor" in the upper right of the reply dialog. 
  3. Select "Attach" in the bottom right of the new dialog window. 
  4. Find the project archive file on your computer and select "Open"

The archive will be uploaded to this discussion.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

Tahnks

0 Likes

Shmuel,

I downloaded your project.   It appears you stripped it of certain features such as the ADC functions.  This may not matter for this issue.

It will take a few days for me to get my PSoC5 kit working with an SDCard HW.

In the meantime, I noticed something.

In your close_file_interrupt ISR you perform a FSClose() depending on certain other conditions.  In the emFile middleware SW, this function may become a blocking function.   In general it is not wise to execute anything that is potentially a blocking function inside an interrupt.  The general rule-of-thumb is when executing an ISR, "get in and get out quick".   When executing an ISR, all other interrupts are disabled from executing.  If in the ISR you execute a function that 'blocks', it is hard to predict in all cases when the function will return.

In the case of the emFile middleware SW, it uses ISRs to perform file Reads and Writes as well as other SPI-related functions.   When you execute the FClose() there might be internal caches that need to be flushed.   Additional 2KHz strobed telemetry data captures may have to wait until this FClose() operation is complete.

This is a fairly simple debugging method to detect if the > 1sec gaps are coming from the close_file_interrupt ISR  and the FClose().

In  CY_ISR(close_file_interrupt)  place a call to write a '1' to a GPIO pin just before executing FClose().  Lastly, place a call to write a '0' to the same GPIO pin just after the FClose().   This is called a framing pulse.   You can use the framing pulse to know when you start and finish the FClose() call.   If the > 1sec delay is coincidental to the FClose() then you have a great clue as to the problem.

In general, the technique to solve it is to use a signaling bit to pass from the ISR to the main() loop.   This is just like you do with the readyForRecord signaling bit in the T2_kHz_Int ISR.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

I eliminate the FClose from the design, and still the long writing time occur.

Do you have more offers?

Thanks

Shmuel

0 Likes

Shmuel,

I'm still working to put together a PSoC5 system with an SDCard.  I hope to have one working by Monday.

The ADC function you use, is it serviced by polling the conversion completion or by an ADC ISR?

If an ISR, what is the conversion rate?

I need to make sure I have all the ISRs you are using to accurately represent your results.

Eliminating the FClose() was a good idea to see if that was the culprit.  Apparently not.

You can put a framing pulse in your T2_kHz_Int ISR.  This will verify if this ISR is not occurring during the SPI blank event.  It might provide some clues.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

The ADC ISR is not relevant to the problem.

I cleaned the project, that I sent you, from irrelevant interrupts and still the phenomenon occur.

The project you have is only focus on the EMfile problem.

Thanks for the fast response

Shmuel

0 Likes

Shmuel,

I got my SD Card interface working on on CY8CKIT-059.

I'm using the project you sent without modification (except for the pins I need for the SDCard interface.).

I've run your project application for more than two hours.  I cannot get a delay in SPI communication more than 29.0 msecs.  .Apparently the stripped down version of your project stripped out the issue also.

Something else is contributing to the delay of > 1 sec that you are seeing.   Are you able to share a less minimized version of your project with the forum?

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

The same project that you're running is the same one that I'm running and having the problem.

Can it be hardware problem (design or pinout)?

Thanks

Shmuel

0 Likes

Shmuel,

HW differences between yours and my system:

  • Changing two of the pins assignments to work with my SDCard interface.
  • I don't have any "ref_2_5V" or "Power_12V_Sample" input stimulus.  These are left floating.
  • I'm using a CY8CKIT-059 as the base.  What PSoC5LP HW are you using?
  • I'm most likely using a different SD card than you.   Suggestion:  Try a different one if you have it.

Other than the SDCard pinout change, I let all pins connections to be the same.

SW differences:

  • I made no changes to your source code.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Can you tell me what kind of sd card you're using (company name) and size (Gbit)

Thanks

Shmuel

0 Likes

Shmuel,

I've used two SD cards with the same results.

  • Toshiba 32MB
  • Dane-Elec 2GB.

It MAY be a factor of the SD card but this is probably not a major concern.

Remember the framing pulse idea I mentioned earlier?

It might be wise to create many framing pulses in your code around different function calls.   This way you can monitor if these functions complete their operation in a reasonable amount of time.

What I am using is a scope with a pulse width trigger.   Any SPI_CLK that is low longer for 30msec triggers.   I get no triggers.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Please sample P0.7 becuase there we export the write time of the SD card.

Thanks

Shmuel

0 Likes

Shmuel,

I've been using P0.7 as my trigger for that last four hours.   I still can't trigger on a low pulse > 28msec.

Something is different between your and my setup.  I asked earlier:  What PSoC5LP HW are you using?   I'm using a CY8CKIT-059.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Thanks again for your effort to help me with this problem.

You need to put the trigger at P0.7 on high pulse >28mSec, because when the write holds it high.

Thanks

Shmuel

0 Likes

Shmuel,

Thank you for the clarification.   I have verified that the normal data dump occurs every 36ms.   It takes about 14ms for most FS_Write() operations.   Occasionally it takes longer due to some additional SPI info being exchanged.   I have recorded an FS_Write() pulse timing of 199ms.   So far this is the longest operational time for this function.  

Any FS_Write() timing greater than 36ms risks loss of data recorded.  This is your concern.

I have written your issue to a contact I have at Segger the company that supplies emFile.  Hopefully he can shed some light as to what is happening and possibly a solution.

The emFile middleware library is very sophisticated.   It has internal buffers and caches.   There may be some internal logic that is being used to flush the cache or possibly even perform needed read operations for the appending functions.(?)

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

I happy that finally we're seeing the same phenomenon.

I'm waiting for your solution.

 

Thanks

Shmuel

0 Likes

Hi Len,

Do you have any solution to the problem.

Shmuel

0 Likes

Shmuel,

Do you have any solution to the problem?

I wish I did.

I'm still waiting from my contact at Segger.

Sadly, I don't have the source code so that I could reverse-engineer the issue.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Shmuel,

I finally received a reply from my contact at Segger.  He indicated to place a thread on the Segger support site for this issue.

Here is the link to the thread.

https://forum.segger.com/index.php/Thread/7640-emFile-V3-22-Data-dumps-FS-Writes-at-36ms-intervals-s...

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Do we have a solution to the problem?

Thanks

Shmuel

0 Likes

Shmuel,

As you can tell from the link to the thread I supplied, no answer yet.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Shmuel,

Here's a link to a reply from someone at Segger.

SEGGER - Marius - Members - SEGGER - Forum

See if the suggestion applies to you.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
RoBO_1287886
Level 4
Level 4
First solution authored 25 replies posted 10 replies posted

We have tested EmFile and this one https://github.com/honet/PSOC5DMASDSPI on PSoC5LP.

The latest version proposed seems largely faster.

We are using a CLK for SPI at 18MHz (it's the fastest possible).

regards,

Robin.

Robin,

Thanks for letting us know about an emFile alternative.   Hopefully this might address the issue Shmuel was having with emFile.

The issue with emFile was that it used a file caching scheme.   The algorithms to dump the cache caused the file system to in effect slow down until the caching was completed.  At the data rate he was trying store (11KB/sec), occasionally some of the data would be lost.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes