7 years, 2 months ago.

Simple DMA Trigger Error In SDFileSystem-RTOS

Hello Erik,

I have your SDFileSystem RTOS library but i have an issue regarding Simple DMA Trigger Error. I am using Nucelo F401RE board to save the sensor data in to SD card using Sd card Filesystem RTOS. But found an error in the library as attached in the image. Could you please update the library that can be used for Nucleo F401RE board. Thank you.

/media/uploads/sandeepmalladi/mbed_rtos_sd.png

Thank you Erik for your suggestion and its working as per the suggestion you had provided me. By setting FLUSH_ON_NEW_SECTOR to 0 speed of the saving data has been increased and i am able to store 3200 samples. But i did not get any clue of how its happening. I have one more question that will there be an effect if i do the setting as you had suggested further in future. Thank you.

posted by san m 21 Feb 2017

1 Answer

7 years, 2 months ago.

SimpleDMA does not support STM MCUs. Long ago I did start on support for them, however they have much more limitations compared to NXP and Freescale MCUs for their DMA. It is some time ago, but from what I remember STM has two DMA modules. That sounds good, however each of their DMA modules can only handle a limitted number of peripherals. So you need in a library to figure out which DMA module is used for which peripheral. And there are also limitations in what they can transfer to/from memory. I believe in the end you can do most of the things that the NXP/Freescale ones can do (and since you have two, you have some extra flexibility I suppose), however making a library for it was alot more complicated than for NXP/Freescale.

Thank you erik for your quick response Is there any alternate way to use RTOS & SDFilesystem by which i can store large number of samples in to sd card. my Main intension of using RTOS is I would like to store 3200 samples / second from ADXL. As i have used tickers in previous version but limitation of higher data rates i was able to achieve 1600 samples using mbed tickers. Where tickers are serial way of execution. One after the other is being operated. Until 800 samples per second it works fine when it happens to go to 1600 and 3200 problem comes. So i decided to switch to RTOS so that it would be flexible enough to execute in threads. Can you please provide me any suggestion how to save data on to SD card using RTOS at regular interval of time? I.e. for every 10 sec i need to create a file and save the data in to it and after that another new file is created after every 10 secs.

posted by san m 20 Feb 2017

Note that this libary does not increase the speed at which SDFileSystem operates. What it does do is make sure you can do other things while it is writing to the SD card. So if you spend 50% of your time writing to the SD card, and 50% of your time doing other stuff, it would definately help. If you spend 90% of your time writing to the SD card, it would do little.

You can have a look at: https://developer.mbed.org/users/neilt6/code/SDFileSystem/, which is improved version of regular SDFileSystem. Especially check if you can increase the SPI speed (an option in its constructor), which should help you.

Next in the SDFileSystem library, you got the FATFileSystem, with in there this file: https://developer.mbed.org/teams/mbed-official/code/FATFileSystem/file/e2ab678eb692/ChaN/ffconf.h. Now I have never checked this for the SDFileSystem! However for the USB flash drive library, which uses the same FATFileSystem, I could get a quite significant speed improvement by setting the last setting, FLUSH_ON_NEW_SECTOR to 0.

posted by Erik - 20 Feb 2017

Thank you Erik for your suggestion and its working as per the suggestion you had provided me. By setting FLUSH_ON_NEW_SECTOR to 0 speed of the saving data has been increased and i am able to store 3200 samples. But i did not get any clue of how its happening. I have one more question that will there be an effect if i do the setting as you had suggested further in future. Thank you.

posted by san m 21 Feb 2017

To be fair: I also don't know exactly why it works as it works. I enabled debug statements when I looked at it for the USB flash drive library, and what I saw was that if you wrote a large file with that setting enabled (as default), it would after each sector it wrote, read other sectors (probably with file system information), and then write the next sector, etc. While when disabled, it would simply write all sectors consecutively without (many) read operations in between. Only when the file was closed and/or a new one was opened it would update the other sectors with where I assume was filesystem and directory information.

posted by Erik - 21 Feb 2017