SparkFun Forums 

Where electronics enthusiasts find answers.

Tips and questions relating to the GPS modules from SFE
By NukWaste
#35407
The GPS Logger 2.4 will write the first time after a format
It fails once I edit the GPSCONFIG.TXT file with programmers editor( ultraedit). If I edit the file with EDIT.EXE in WinXP it usually doesn't happen.

I suspect that ultraedit writes the file to the SD card in a way such that the module code can no longer read it. I'm using the .94 debug version from gps_logger_mg@tanundra.com to see the error.
-----------------------------------------------------------
gps_logger_mg v0.94: system firmware (hardware v2.4).
copyright (c) 2007 gps_logger_mg@tanundra.com. all rights reserved.
app_init
card_init
app_init: failed - fat_init, error=-6
-----------------------------------------------------------
By mg
#35465
That's a CARDREADFAILED error, and the debug shows that it's being generated from fat_init: i.e. when the FAT module looks for file system and partition information on the card. This occurs before it ties to read and parse the config file (config_init), so shouldn't have anything to do with the type of editor used.

Can you confirm that after you see that error, that you can pull the card out and put into a windows machine and read its contents (including the config file)?

Did you freshly format the card to FAT16 before use, or was it preformatted in some way? If you did format it, on what machine and with what parameters? I'd recommend to freshly format it under Windows.

My only thought is that the filesystem has been formatted/configured in a way that the firmware doesn't understand it - which is possible because the firmware has been developed and tested with cards formatted under Windows and perhaps a nuance with a card formatted elsewhere is causing a problem.
By NukWaste
#35471
I executed 20 or 25 iterations of formating with Windows XP Pro SP2 using Fat. (Not quick format) I also used the Panasonic SD Formatter 2.0 (2.0.0.2) to format using specific SD Protocol. (Just in case) The device I used is the built - in SD Card reader with the Panasonic Toughbook. The Panasonic utility is the only formatter recommended by the SD Card Association.

http://www.sdcard.org/about/

"In January 2000, Matsushita Electric Industrial Co., Ltd. (Panasonic), SanDisk Corporation and Toshiba Corporation established the SD Card Association as a new industry-wide organization charged with setting industry standards and promoting wide acceptance for the SD Memory Card in digital applications. "

So I feel good about using both the OEM reader and the OEM software on a Panasonic OEM device. One of three organizations that established the technical and specification standards for the SD Memory Card.

I used the SD card (512mg )purchased from SparkFun (Didn't work at all - ever - PC or SF Device) SanDisk (64mg and 2gb) which worked about 80% of the time and Kingston (2gb) which worked about 5% of the time. The size of the card didn't seem to have an affect but I think this is because of my testing procedure.

Each time I went through the testing I formatted the SD Card, pulled the card out of the PC, inserted into Sparkfun device, powered up, ran for a few minutes, selected the stop button, pulled the SD Card and read with the PC.

After a few iterations I concentrated on the SanDisk Cards as they had the most success.

Almost all the time, I could read with the PC. The Sparkfun device never crashed the SD Card as long as I selected the stop button first before removing it.

If I attempted to power up the device without removing the SD Card after the first iteration (the creation of the GPSCONFIG.TXT file), I would get a -6 Error about 10 - 20 % of the time. Sometimes a -2 error. If I removed the SD Card and edited the GPSCONFIG.TXT file with a programmers editor, it would always fail with a -6. If I edited with EDIT.EXE in XP Pro SP2 It would almost always work.

My guess is that the type of editor used changes the file in some significant way either by writing to the FAT a strange way or changing the file in some significant way. I did notice that the initial edit using the programmers editor showed that the initial GPSCONFIG.TXT contained extra 0x0A s where there should have been 0x0D 0x0A.

If you like I can provide a spreadsheet detailing the exact proceedures I took with the results. (I would rerun them)
By mg
#35474
Interesting. Thanks for the thorough process you took.

In terms of stop button, yes its recommended to ensure that the current log file is closed properly. If you don't use it, and just power off, the card itself won't be damaged, just the current log file may not be fully written out. You can reduce buffer sizes and timeouts to customise your exposure to this risk.

The -2 error is a CARDENABLEFAILED. Given the variance between cards that you describe, my immediate thought is that it's the SPI timing. I've tested on three different cards (immediate details not to hand, I'm not at home) without seeing the issues you mention, but my sample set may not be wide enough.

The additional CR/LF's in the config file won't cause a problem. If there were any parsing errors of the config file, they would show up later and with different error codes.

Presumably using the original sparkfun firmware you don't see the same problem (it has different SPI code).

I notice you're using vanilla v0.94, can you try the most recent version v.094b from the blog: http://gpslogger.blogspot.com. I specifically made some SPI changes between those two versions, which could help.

Separately, I'll try to reproduce the problem by (a) sourcing and trying some other SD's, (b) looking at the timing differences between my SPI code and the sparkfun version, (c) trying the same ultraedit process.

I'm able to do (c) within the next couple of days, but (a) and (b) may take longer due to my other commitments, hopefully by the end of the week though. If v0.94b doesn't work for you, then I'd suggest for now switching back to the original sparkfun firmware until I have more news. Sorry about that!

In any case, despite the problems, I'm thankful for your testing, and I'll do my best to resolve the issues.
By NukWaste
#35475
Frankly, the reason I went to .94 was because SparkFun code was failing and not giving any data.

I will install .94b and retest with a spreadsheet documented method.

I'm also migrating to MicroSD / Transflash to get foot print down.

By the way, congradulations on Google.
By busonerd
#35478
Hi,

We have an updated version of the firmware that has fixes for the problems with the kingston card, however I'm not sure what was going on with the regular card we shipped you - if it never worked, we can return it as defective and get you a new one.

Cheers,

--David Carne
By NukWaste
#35479
What were the problems you found with the kingston card?

The SparkFun Card won't work in the SparkFun device nor my Panasonic reader. BUT, it will work in wife's camera. I would love to get it working in all of the above. I have another shipment going back to SF today. Should I put it in with that one? RMA 34268..