Asynchronous sd-card mounting procedure

Hello Nordic, I have a problem. I'm running the nRF9160DK with three sensors and an sd card reader. The three sensors and the sd-card reader are connected via SPI. Due to power requirements, I have only one sensor active, taking down values constantly. Once these values cross a certain threshold, a trigger event occurs and data is sampled at 32kB/s for up to 20 seconds. This is more data than the RAM can hold, and as such I need to write it to the sd-card continuously. The problem is the sd-card, if mounted, draws 2,18mA.

The idea is to cut the power to the SD-card when it's not being used, which is 99% of the time, and mount it when a trigger happens. The sensor has a buffer which overflows after around 25ms and the mounting procedure of the sd-card takes between 100-500 ms. Now, I certainly have enough RAM to save a few seconds of data while the sd-card is being mounted, if it can be done in parallel with the data reading.

And that is my question: Can this be done in parallel? Multithreading, to me, requires more than one core and dividing up the workload between the cores. However, in a single core application, maybe there is some sort of timer interrupt or the like that automatically switches between threads. Maybe DMA could be used. I'm a bit lost here and looking for ideas for how to do this, if it is possible. Any other idea would also be appreciated, maybe there is a way in software to reduce the current draw of the sd-card such that it stays mounted and the wake-up-time is greatly reduced.

Thank you for reading!

Parents
  • Hello Niclas,

    Since Zephyr is a multithread real time operating system, it supports multiple hardware architecture. So, this is handled automatically. When you start a new thread in Zephyr it runs parallel with others.  You actually do not need to have more than one core to perform multithreading. 

    ''However, in a single core application, maybe there is some sort of timer interrupt or the like that automatically switches between threads''

    Yes, from a hardware perspective, the RTC is used to wake up the processor whenever there is a task from one of the threads waiting to be executed. This is handled automatically in Zephyr. In nRF5 SDK we have Application Timer (app_timer) library (nRF5 SDK Application Timer Tutorial - Software Development Kit - nRF5 SDK guides - Nordic DevZone (nordicsemi.com). Using app_timer, it is easy to use Real Time Counter1(RTC1) peripheral to create multiple timer instances. The RTC uses the Low Frequency Clock (LFCLK). Most of the applications keep the LFCLK active for all times. So it reduces the power consumption. 

    ''The idea is to cut the power to the SD-card when it's not being used, which is 99% of the time, and mount it when a trigger happens. The sensor has a buffer which overflows after around 25ms and the mounting procedure of the sd-card takes between 100-500 ms. Now, I certainly have enough RAM to save a few seconds of data while the sd-card is being mounted, if it can be done in parallel with the data reading.''

    It seems strange that the SD card mounting makes the CPU occupied for 100-500 ms. This is also you are worrying about. Is the actual scenario of testing or some of the preliminary worries? Have you tested this? If the SD card driver is actually blocking for 100-500 ms, we would consider this as bug and that should be removed. 

    Apart from this, the SPI peripheral you use for the sensors are also able to run in parallel and they already have DMA implemented. So, CPU does not need to wake up when the data is written to RAM. So there is a thought- even though the SD card driver would block the CPU for 500 ms, the SPI should still be able to run and capture sensors data and write it to RAM ( in parallel with the SD card initialization). However this may also depend on how the SPI driver is implemented in zephyr. 

    We still have the same concern to ask you if this is a real issue or you are in planning stage?

    ''Any other idea would also be appreciated, maybe there is a way in software to reduce the current draw of the sd-card such that it stays mounted and the wake-up-time is greatly reduced.''

    Our team would assume that the  SD card has some sort of low power function, which is activated by writing some commands on it. But it is not normal to switch on and off the power to save current.

    One more thing to add that nRF9160 is a single core device which can be seen from application. It has another core that is used only for modem and can not be used by the application.

    Hope it helps. Let us know is you have more queries to know and also which stage you are in. 

    Best Regards,

    Kazi Afroza Sultana

  • The support you guys give is beyond every reasonable expectation and I thank you for such a detailed and knowledgeable response. I'm in a testing phase and have implemented modem functionality as well as sensor functions. As of now, all the code runs in sequence and no threading is done on my part but given your answer, I think I understand this better and will try out some things. As of now it looks like this, in pseudo:

    if(trigger)
       mountSDcard() *this part takes 100-500ms
       while(dataActive)
          writeToSD(data)
      dismountSDCard()

    I have tested the mounttime using logging functions.

    I thank you for all the information given, I will read through it all, do some testing and get back to you.
    As I am sure you can tell, this is untrodden waters for me.

Reply
  • The support you guys give is beyond every reasonable expectation and I thank you for such a detailed and knowledgeable response. I'm in a testing phase and have implemented modem functionality as well as sensor functions. As of now, all the code runs in sequence and no threading is done on my part but given your answer, I think I understand this better and will try out some things. As of now it looks like this, in pseudo:

    if(trigger)
       mountSDcard() *this part takes 100-500ms
       while(dataActive)
          writeToSD(data)
      dismountSDCard()

    I have tested the mounttime using logging functions.

    I thank you for all the information given, I will read through it all, do some testing and get back to you.
    As I am sure you can tell, this is untrodden waters for me.

Children
Related