No data saved to SD Card, only after a long run period

Hello,
I'm currently using the Activity Board WX, with a 32 GB SD card loaded. I have a program that is saving data packets to the SD card. If I run this for several hours, it works great and I can grab all my data. However, if I let it run overnight, the SD card comes up with the appropriate file, but no data in it. The data packets are about 100 bytes each, saved at 1 second intervals, so it shouldn't be getting anywhere near maxing out the SD card. What could be causing this? Thanks,
Matt

Comments

  • Peter JakackiPeter Jakacki Posts: 8,725
    edited 2019-10-10 - 05:43:25
    Welcome to the forum Matt.

    Normally you would receive a prompt reply from some helpful forum member but as with any forum and any questions, they can only be answered by someone WHEN they have sufficient information. Of course we can play a back and forth game of asking for more information or you could just provide that information in the first place. None of us have a clue as to what software you are running and so we can't answer your question. Therefore it is always best to post the code either directly using the code tags ( 'C' in the forum compose menu) or zip the files. Sometimes if may be hardware in which case send a clear photo or two and also any links that might be needed.

    If you do these things you usually get a prompt response from one or more members.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • 100 bytes per second is 100 x 60 x 60 x 24 bytes per day, or 8.64Gb. If your SD Card is formatted as FAT32 the file size limit (not the card size limit) is 4Gb. So you would exceed that in just under 12 hours.

    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • RossH wrote: »
    100 bytes per second is 100 x 60 x 60 x 24 bytes per day, or 8.64Gb. If your SD Card is formatted as FAT32 the file size limit (not the card size limit) is 4Gb. So you would exceed that in just under 12 hours.

    8.6MB/day

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • I think 100 bytes/sec * 86400 sec/day would be 8.64 Megabytes per day, correct?

    Which is far, far below the 4 Gigabyte FAT32 file size limit.

    Yet this doesn't explain why the SD card isn't recording correctly while running overnight.

    It could have something to do with opening the file, moving the file pointer to the existing data, appending to it, then closing the file.

    It could be that as the file gets larger there's a problem with fseek() working correctly. I had a problem similar to this with a FreeDOS based data collection device at work.

    We worked around it by only running the unit for several hours, then stopped the recorder, downloaded the data, then restarted.

    I know that isn't a solution, as we don't know what the cause of the problem is that Matt is experiencing, but perhaps a review of what functions he's using to write to the card fopen(), fwrite(), fseek(), fclose(), etc, might spark some ideas...
  • .
    RossH wrote: »
    100 bytes per second is 100 x 60 x 60 x 24 bytes per day, or 8.64Gb. If your SD Card is formatted as FAT32 the file size limit (not the card size limit) is 4Gb. So you would exceed that in just under 12 hours.

    8.6MB/day

    Oops! :)
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • JRetSapDoogJRetSapDoog Posts: 803
    edited 2019-10-10 - 07:02:52
    Strange things happen sometimes. A weird thing that I've experienced is that if I mount, read and unmount a card repeatedly, things will fail on average after thirty-something cycles (I verified this many times). And I was only reading the card, never writing to it. But if I kept it mounted, I could read it thousands and thousands of times without problem. That was with two no-name 8 GB cards from the same source (using Kye's driver code for the P1). Never got around to trying cards from another manufacturer, and I don't know if the problem was even due to the cards. But those cards have controllers in them, and it's hard to say what goes on behind the scenes. And I wonder how much manufacturers would care about problems with SPI access anyway.
  • Are you correctly closing the file and/or unmounting the card before removing it or turning the power off?

  • mattorvis, are you programming in C or Spin? Please post your code.
  • the FSRW driver is probably the most tested SD code around.
    But, I'm not sure I'd trust even it for continuous appending to a file...

    I'd for sure start with a freshly formatted sd card. That may fix whatever problem you are having.

    If it were critical, I'd add an SPI flash chip to the system and first write to it and then copy to uSD and then verify the write and then start over...
    Prop Info and Apps: http://www.rayslogic.com/
  • If you have some hub memory free, you could use it as the buffer, instead of adding an SPI chip.
    But, I'd write to a new file each time instead of trying to append.
    I wouldn't trust append...
    Prop Info and Apps: http://www.rayslogic.com/
  • Append pointer overrun ?

Sign In or Register to comment.