Shop OBEX P1 Docs P2 Docs Learn Events
SD Card Problem - Simple Code — Parallax Forums

SD Card Problem - Simple Code

SuperCricketSuperCricket Posts: 17
edited 2009-07-18 05:03 in Propeller 1
This was just a test of using an SD card to log things with the FSRW object.

If I let the program log infinitely to a file, whenever I turn the Propeller off and eject the card the file is corrupt.

My idea was to log to a file for a bit, close the file, and open a new one. In this way I could remove the card at any time and still have files of data. So this code writes to files "1", "2", "3" and so on. I can turn off the Prop and while the last file is corrupt, I have many other files of useful data.

However after a random time period, maybe a minute or 3 minutes, the screen goes black and the Prop reboots. Sometimes sucessfully and sometimes not. So sometimes I may have 3 files, sometimes I may have 6 good files of data. Sometimes 1. It is completely random.

PUB logger

  sdfat.mount(16)
  files := 1

  repeat
    r := sdfat.popen(numtostring.ToStr(files, %000_000_000_0_1_000100_01010), "w")
    repeat 10
      sdfat.SDstr(fs.FloatToString(stuff))
    sdfat.pclose
    files += 1



One cog is running this code while the main cog is running the TV terminal simply outputting the value of "stuff." The above cog is running with a stack of like 300 longs to make sure that wasn't the problem.

Any ideas?

Comments

  • lonesocklonesock Posts: 917
    edited 2009-07-17 19:47
    Regarding the robust saving of data, as you know you can not yank the card while the file is open for write. However, rather than do N files, you could use just 2 files. Whenever you have data to log, do a

    - popen "file1" for append
    - pwrite your logging data
    - pclose "file1"
    - popen "file2" for append
    - pwrite your logging data
    - pclose "file2

    This way, both files should be identical. If the system loses power during a write the other file is still in good condition. This is not the fastest solution, of course, but it is really easy to implement.

    Regarding the reboot, I've had trouble when I had the USB cable plugged in to the PropPlug, but not to my PC. Could you describe the system setup you are using in more detail?

    Jonathan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lonesock
    Piranha are people too.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-17 19:52
    The problem is likely in what you're not showing.

    From your description, it sounds like both cogs are using the floating point library, possibly at the same time. That's dangerous.

    Without a complete copy of your code, it's impossible to tell what's going on. Use the ARCHIVE feature of the Propeller Tool to make a file that you can attach to your next message. Indicate which "library" objects you're using. If you've changed them in any way, include them as well.
  • SuperCricketSuperCricket Posts: 17
    edited 2009-07-17 20:19
    I'll grab the laptop and post my whole code in a bit. But is using the same object in multiple cogs really bad? So if I want to use floating point, numbers, etc. I have to do multiple instances like.

    cog1_numero : "numbers"
    cog1_floating : "FloatMath"
    cog1_FS : "FloatString"
    cog1_BS2 : "BS2_Functions"
    cog2_numero : "numbers"
    cog2_floating : "FloatMath"
    cog2_FS : "FloatString"
    cog2_BS2 : "BS2_Functions"
    cog3_numero : "numbers"
    cog3_floating : "FloatMath"
    cog3_FS : "FloatString"
    cog3_BS2 : "BS2_Functions"

    Seems like I will be out of memory damn quick like that!
  • SuperCricketSuperCricket Posts: 17
    edited 2009-07-17 20:45
    lonesock that is awesome I went with your idea. However it kept randomly rebooting or just going black still.

    Sure enough I just gave the floating point another instance for that 2nd cog.

    So the first cog converts the value to a floating point for display on the screen and the 2nd cog converts it to write to the file.

    It's been running for 10 minutes now no problems.

    In a year of programming the Propeller I had no idea you needed an instance of a library file for each cog. Insane.

    Thanks for the help Mike!
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-07-18 04:43
    Another possibility which will not lose any data, except perhaps corrupt the block being written. Place an existing huge blank file on the SD and just update each successive sector. This how we are using ZiCog CPM files (disks)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
    · Search the Propeller forums (via Google)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-18 05:03
    You don't need a separate instance for each cog. The LOCKxxx instructions are provided to make one of the cogs wait for the other cog to finish with the shared variables. If the timing works out in your favor, the two cogs will rarely have to wait to use the common floating point (or whatever) object, yet you can be certain that two cogs will not try to use a common resource at the same time.

    Read the chapters in the Propeller Manual on the LOCKxxx instructions and Spin statements.
Sign In or Register to comment.