Shop OBEX P1 Docs P2 Docs Learn Events
Memory stick Datalogger lock up problem. — Parallax Forums

Memory stick Datalogger lock up problem.

jruthroffjruthroff Posts: 38
edited 2014-01-16 18:47 in BASIC Stamp
I'm using the attached code to pull down the temperature from an LM34, digitize it with an ADC0831, and storing it on a USB stick using the Parallax Memory Stick Datalogger.

The problem I'm having is random lock-ups of the system. In 10 tries of attempting to log 100 temperature data points, I've only been able to have the process complete twice.

The normal failure mode is for the debug terminal to stop right after displaying "count = XX", where XX is some random count of the samples logged.

The project is built on a BOE and powered by a bench top power supply. I've tried formatting the drive before each run, this doesn't seem to help.

Any thoughts?

Thanks,

John
bs2
bs2
Temperature_Datalogger.bs2
7K

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-01-06 14:01
    Unless I am mistaken it appears that you're not writing enough bytes out with the WRF command. That is, you specify 9 bytes in the first section, which includes 5 bytes of the counter, 2 bytes of * and the CR/LF.

    However in the next WRF command you're specifying 7 bytes, but I only see 5 being sent.
  • jruthroffjruthroff Posts: 38
    edited 2014-01-06 17:45
    Hi Chris,

    Thanks for that input. I've changed the second WRF command to specify 5 bytes. I'm testing now...so far one success and one failure.

    I guess I think it would either work or not work (i.e., fail right away), but it doesn't work that way I guess :-).

    I wonder...do you think the brand of the USB drive should make a difference? I'm using a "non recommended" drive, and it wouldn't be putting me out that much to get one of the suggested drives. Has the list of recommended drives been expanded?

    Thanks, again,

    John
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-01-06 20:21
    John,

    To be honest I never really thought much of the "recommended" list of drives. Thumb Drives with "secure" software and other such "special" drives are the only ones I have had issues with. Formatting is important. Other than that I don't think FTDI has limited the range of usable USB drives much. I didn't look in your code past the first error. It is possible there are more that I missed or something in the logic that causes an eventual failure. I supposed I could just try your code on my end and see what happens. If I have time tomorrow I will see if I can. It's been awhile since I have used one.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2014-01-06 22:32
    I too have had good luck in general with flash drives. Mostly though I stick with Sandisk Cruzer Blade.

    In text mode there is no need to enter the number of characters in hex. No matter what surest cause of a lockup and strange results is to get the count of characters wrong after the WRF.

    SEROUT TX\CTS, Baud, ["WRF 9", CR, DEC5 counter, "**", CR, LF]
    there is no need for a CR after LF, which is the 9th character. Having an extra CR after the LF does not hurt anything but it does generate an extra OK response from the monitor.

    Or put everything on one line...
    SEROUT TX\CTS, Baud, ["WRF 14", CR, DEC5 counter, "**", CR, LF, DEC3 adcVal, CR, LF]

    Or this too is okay
    SEROUT TX\CTS, Baud, ["WRF 14", CR]
    SEROUT TX\CTS, Baud, [DEC5 counter, "**", CR, LF]
    SEROUT TX\CTS, Baud, [DEC3 adcVal, CR, LF]
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-01-07 10:38
    Tracy,

    I got the impression he was writing the CR/LF out to the file in this section, which would account for 9 characters. 5 for the counter, the two * symbols and the CR/LF, making the last CR the command terminator. The datasheet specifies the CR to terminate the command. Are you suggesting we don't need the CR at the end of the command?
    DEBUG "Writing data separator now... ", CR
  SEROUT TX\CTS, Baud, ["WRF ", $00, $00, $00, $09, CR, DEC5 counter, "**", CR, LF, CR]
    Vinculum Firmware Guide wrote:
    ‘WRF’<sp> <size in hex(4 bytes MSB first) ><cr> <data bytes of size><cr>
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2014-01-07 11:19
    Hi Chris,

    Yes, this command does not have a terminator. It goes by the count only. What data sheet are you referring to? I am referring to Vinculum Firmware User Manual v2.4 rev 3, section 6.2.7 on Write to File (WRF).
    Screen shot 2014-01-07 at 11.17.09 AM.jpg


    Plus my own experience--Never add an extra CR.
    Screen shot 2014-01-07 at 11.17.09 AM.jpg
    1024 x 615 - 93K
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-01-07 14:31
    Tracy, I am referring to what we have on our website, which appears to be V1.07, page 11. Perhaps we need to update that. =/ Yep, that file is listed as preliminary and subject to change. DOH!
  • jruthroffjruthroff Posts: 38
    edited 2014-01-07 16:50
    Ok, I've removed the "extra" CR and am testing now. If it doesn't work out I'll try the other suggestions mentioned. Thanks for looking into this, it'll be really great if this works. I'll keep you all posted on how it turns out.

    Regards,

    John
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2014-01-07 20:16
    The extra CR in and of itself won't make a difference. The monitor will interpret it as a command and will return an extra prompt. Benign.

    Again--You have to get the count right. Some excess characters are not so benign. Suppose the WRF instruction says it is going to send 20 characters, but you actually send 25. The monitor will attempt to interpret the extra 5 characters as commands, and will usually error out. But sometimes what you send may actually be a monitor or disk command that does something you didn't want such as change the baud rate or put the drive to sleep or move the file pointer. Bummer. Sending too few characters can end up in lala land too. The monitor accepts as data what you thought were going to be your next commands and puts them as data on the the thumb drive. When it does get the number of characters you had specified, it likely ends up out of sync, with garbage going as commands to the monitor, ouch, lockup.

    For debugging you can print out what is returned from the Purge and Get_Serial_Bytes operations. DEBUG out everything that the drive sends back:
    SERIN RX\RTS, Baud, 500, No_Data, [ioByte]
    [COLOR=#ff0000]IF ioByte=13 OR ioByte=10 OR (iobyte>31 AND ioByte<127) THEN
      DEBUG ioByte  ' echo the ascii drive responses
    ENDIF[/COLOR]
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-01-08 11:24
    Tracy,

    That's why I was concerned about the CR...I was thinking if it's not supposed to be there on the current firmware then it would be an extra character that would be parsed. As you pointed out, perhaps just causing an extra "OK" prompt, however if characters were missing it could seen as data or something else. I need to download the latest manual and firmware and get my knowledge and devices up to date. Been busy testing out the XBee Wi-Fi modules and side-tracked on that. Which by the way, also needed updated firmware.
  • xanatosxanatos Posts: 1,120
    edited 2014-01-16 18:47
    Hi... I've used these items extensively. While I'm not in front of my code right now, one thing I know for certain is that you absolutely have to specify the exact data length you will be writing to the drive. Be short or long by one bit and the op will fail... just my first gut thought.

    For what it's worth, once you figure these things out... they are bulletproof. I use them in my DieselDock product, and they are flawless.

    I have a thread on here somewhere with code that may help. If you haven't figured out the issue by the time I get back to my office, I can find the links.

    Dave
Sign In or Register to comment.