- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Shmuel,
I assume you know how to archive your project.
To attach this archive you need to do the following:
- Select "Reply" in the bottom right to a post.
- Select "Use advanced editor" in the upper right of the reply dialog.
- Select "Attach" in the bottom right of the new dialog window.
- Find the project archive file on your computer and select "Open"
The archive will be uploaded to this discussion.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
I eliminate the FClose from the design, and still the long writing time occur.
Do you have more offers?
Thanks
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
Can you tell me what kind of sd card you're using (company name) and size (Gbit)
Thanks
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
Please sample P0.7 becuase there we export the write time of the SD card.
Thanks
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
I happy that finally we're seeing the same phenomenon.
I'm waiting for your solution.
Thanks
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
Do you have any solution to the problem.
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Len,
Do we have a solution to the problem?
Thanks
Shmuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Shmuel,
As you can tell from the link to the thread I supplied, no answer yet.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
"Engineering is an Art. The Art of Compromise."