Shop OBEX P1 Docs P2 Docs Learn Events
My conflicting SD card object, fsrw, FloatString, Simple_Numbers - what am I do — Parallax Forums

My conflicting SD card object, fsrw, FloatString, Simple_Numbers - what am I do

ElectricAyeElectricAye Posts: 4,561
edited 2008-09-18 20:02 in Propeller 1
Hi all,

I've got a problem that appears to be two methods or objects conflicting with each other.· I had successfully tested several sections of a larger program but when I recently put all the pieces together,·the whole system would·crash after about 1.5 minutes of running okay in real time.· I have spent the past couple days·searching for the source of the conflict and managed to boil·down the larger program to a small program that displays the exact problem as the larger version.

The larger program reads real time from a DS1307 and temperature from two DS18B20s, then writes the date, time, and temperature to an SD card.· Tested in parts, everything seems to work okay.· But when the date and time and temperature are all written to the SD card using the same program, the thing crashes after roughly·15-30 iterations of an inner repeat loop.· The error is very repeatable, meaning it will crash at the same point every time.· For debugging purposes, I stripped out the DS1307 and DS18B20s, simulate them in the code and still get the same crash.· I have tried two different SD cards and got the same problem.· I've got a wall wart giving me 7.5 volts at 300mA, so I don't think it's a power problem.·

I have attached a Spin file of the stripped down program that displays the crash.·
The inner loop in which the crash takes place starts at line 153.· It originally was designed to read date, time, temperatures, and write them to the SD card every couple of seconds.· Outside that loop is another repeat loop designed to close the current SD card file and open up a new one with a different name.· The crash always takes place inside the inner loop and never seems to happen in the outer loop.

If I use only the·temperature-writing portion of the code (lines 210-221), and do not write date and time, then things seem okay.· And vice versa.· But all together the whole thing crashes, the SD card stops writing data and the video goes blank.

I'm guessing some sort of memory space byte operation is conflicting with another or I'm screwing up a formatting thingy that the Propeller simply can't stomach anymore after 20 or so iterations.· I have gazed at the various object codes until I'm half blind but I don't know enough about all of this to see what's conflicting with what.·· Thus, I am throwing myself at the mercy of the forum.·

whimpering in despair,
Mark
cry.gif

Comments

  • mirrormirror Posts: 322
    edited 2008-09-16 07:13
    Time how long each SD card operations takes!

    You may be running into a point where the re-write of a sector requires that all the other associated sectors be deleted in order to do the write. The sectors are grouped into clusters (not FAT, but hardware) of about 32K each - it varies per SD card. If a sector needs to be erased (in order to be rewritten) then the rest of the cluster gets erased at the same time. It can take several times longer to do one of these "re-writes" (20x or more longer).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • BradCBradC Posts: 2,601
    edited 2008-09-16 07:32
    All the sd routines can end with an ABORT if there is a problem. You don't ever check for that.

    However, even if they were to abort (which would stop your main cog) the tv_text driver should keep refreshing the display.. so that's not it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Mike CookMike Cook Posts: 829
    edited 2008-09-16 13:07
    Maybe this might be of some use. Here's an archive of code that I've been playing with.

    Reads the time from a DS1307, Temperature from 2 DS1820's, writes this data to an SD card, and also transmits this data via XBEE RF module. All Hardware definitions are in the CON section and the DS1820·serial numbers·are located in the DAT section. The code has not been optimized but seems to be pretty stable, been running since 1-17-08, logging temperature. Also attached is a sample data file that is written to the SD Card.

    The SD routines are from Mike Green's FemtoBasic.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Mike
  • ElectricAyeElectricAye Posts: 4,561
    edited 2008-09-17 02:50
    Thanks, you guys, for your thoughts.· And thanks, Mike Cook, for posting your code.·

    I found that by abandoning the use of FloatString and by using Simple_Numbers instead to write the temperatures (multiplied by 100), the strange crash has disappeared (at least insofar as I've tested it).· That will work for now.

    scool.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    It might be the Information Age but the Eon of Ignorance has yet to end.
  • computer guycomputer guy Posts: 1,113
    edited 2008-09-18 06:17
    Just wondering what crystal are you using?
    Or what dev board?

    5Mhz, 6MHz, etc.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Building Blocks To The Propeller Chip A web site designed to help people who are new to the propeller chip.

    Guitar Hero controller using the prop (WIP) --> HERE
  • ElectricAyeElectricAye Posts: 4,561
    edited 2008-09-18 12:31
    Computer guy,

    I'm using the Propeller chip, crystal, and board that came with the educational kit. The crystal is 5 MHz. The chip is the DIP version.

    Thanks for your interest,
    Mark
  • hippyhippy Posts: 1,981
    edited 2008-09-18 20:02
    ElectricAye said...
    I found that by abandoning the use of FloatString and by using Simple_Numbers instead to write the temperatures (multiplied by 100), the strange crash has disappeared (at least insofar as I've tested it). That will work for now.

    Excellent - You at least now have a repeatable bug which you can fix / cure at your leisure. Make sure you take a snap shot of the complete project ( your own plus all included object files ) if you are going to do further work on your datalogging code.

    When you come back to it, you can debug in more depth; determining which FloatString causes a problem and then analyse how that's different to what does work.

    The key to successful debugging is being in a position like this so it's is very good news.
Sign In or Register to comment.