MCP3208 vs FSRW.

Hugh

Hi,

As per this post, what has been working until recently failed today, the symptom being that the SD card wouldn't mount.

I have the following objects:

- FullDuplexSerial
- Debug_Lcd_AMC1602" ' This is the LCD display
- fsrw ' This is the SD card on which data is recorded
- simple_numbers ' This object handles simple numerical operations
- FloatMath ' This object deaks with the complex floating-point math
- MCP3208 ' This is the ADC object used to deal with the accelerometer data
- FloatString

As of today, if the MCP3208 object is started the SD card won't mount. I can comment-out other objects and it still won't mount - it is only the MCP3208 object that causes the problem. Yet yesterday the exact same software and hardware worked!

Could I have a duff area of RAM? If anyone has any other bright ideas regarding FSRW and MCP3208 I'd love to hear them!

Thanks in advance

Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Mike Green

Your answer will be found in the question "What did I do between the time that this system worked and when it stopped working?"

There is nothing inherent in either the FSRW driver nor the MCP3208 driver that would cause it to suddenly stop working on its own. In addition, it is extremely unlikely that an area of RAM could fail or, for that matter, an area of EEPROM or other ICs or portions of them. It's much more likely that there's a bug somewhere in your program that has somehow corrupted part of your SD card. Have you tried mounting that on your PC? Have you tried running a disk repair program against your SD card?

If you want specific help, you will have to create an archive of your source code using the Propeller Tool, then attach the archive to another message using the forum's Attachment Manager.

There might be bugs in any of the objects you've included. It's unlikely that there's a bug in FSRW only because it's been in use for a relatively long time and there haven't been new problems showing up. The MCP3208 driver is relatively new. Most likely the problem is in your code. That's the way these things work.

Post Edited (Mike Green) : 11/24/2009 9:13:18 PM GMT

David B

When you call mount, it might help to call it with the abort trap slash (I didn't see the slash in the code in your other post)

r:= \sdfat.mount(3)

I've had cases where the abort-return value got lost when I didn't.

When you do that, you should get a descriptive error code that should help debug this problem.

Hugh

Mike Green said...
Your answer will be found in the question "What did I do between the time that this system worked and when it stopped working?"

The answer to that question is 'nothing changed' and I have performed some regression testing with previous versions of the software with the same result.

The SD card works in a PC, has been reformatted as a precaution and·'FSRWTest' runs fine, returning '0' as an abort code and writing/reading data correctly. I have even replaced the Parallax Micro SD breakout board with a Sparkfun SD·breakout board·and the results are the same.

The first symptom was an occassional need for a re-boot to get the card to mount. This became a more-frequent need until it now won't boot with the MCP3208 object present.

If I comment out all of the code except that which starts the MCP3208 object and the SD·'mount' command it won't boot.

If I reverse the order in which the MCP3208 object starts and the SD 'mount' command is called, it still won't boot.

I'm at work, so can't attach the code, but it should be [noparse][[/noparse]url=http://forums.parallax.com/forums/attach.aspx?a=36622]here[noparse][[/noparse]/url]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

David B

When the mount fails, does the mount command return a non-zero error code? If so, what is it?

Hugh

David B said...
When the mount fails, does the mount command return a non-zero error code? If so, what is it?

It doesn't return anything, Dave. It just "stops".

If I change tab to the 'FSRWTest' code and load that the mount works immediately and returns '0'.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

David B

I don't know what to suggest except for some plain old-fashioned debugging.

Maybe you could put an empty "repeat" just past the "mount" call to force the program to halt after it displays the mount return status.

Then go into the FSRW code and start plugging in your own unique "abort" code, like "abort(-666)" to show you where things succeed and where they fail.

Start by adding your abort call at the beginning of the "mount" code, to verify that the code correctly captures and displays your "-666", then start moving the abort(-666) around inside the "mount" code until you find the place where "mount" stops working properly.

Hugh

I am nearly there...

Both objects are working now, but the SD data isn't right: as per the attachment, the file I want (Data3.csv) is there as a 0KB file, accompanied by many 1KB files. Even the volume label has been mangled to ASCII.

I am mounting the SD volume, opening a file for append, writing to it and then closing it. Would the sliced-and-diced data suggest anything? I know nothing about SD cards.

TIA
Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

MagIO2

Which version of FSRW are you running? And in which order do you start drivers that need COGs?

I had a problem running the FSRW 2.4. I simply tried it with the test-code and got read errors. Test code stops then.
It turned out that I have a different setup in sense of the pins I attached the SD card to. Different pins means different path-length from COG to pin. The path length seems to affect the capacity so much that the timing is no longer correct. I simply replaced the COGNEW with a COGINIT( 7 ... ) and everything works since.

I'd suggest to load the SD driver as first and replace the cognew with a coginit. That way you can test some different COGs. Maybe you have the same problem.

Format the card before doing additional tests. If directory looks so bad cluster table can't look much better.

CassLan

I agree, I had issues with mounting after upgrading fsrw (it would freeze), but I moved it to the top of my peripheral startup and it went like a breeze

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


NYC Area Prop Club

Prop Forum Search (Via Google)

·

lonesock

In addition to what MagIO2 mentioned, I have also had trouble with the fast reads if the pull-up resistor values were too low. If you have pull-up on the order of 10k on the DO (which is driven by the SD card), you may want to increase the resistance to 100k. For me personally, I use a 100k pull-up on the CS line, and do _not_ use pull-ups on the DI/DO/CLK lines (if the card is not selected it will ignore the other lines). This is obviously not an option if you are sharing the lines. (MagIO2, I can't remember if you were sharing lines, but you might want to try changing your pull-ups to 100k also...then the cog-pin relationship might not be such an issue.)

If you would like to email me your code (this user name at gmail.com), I'd be happy to look over it. Also, if you could email me a snapshot of the relevant portion of the schematic, I can look over that as well.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Hugh

Thanks Folks,

I'll have a play with the code and the resistors and then if I need to, take Lonsock up on his kind offer.

Cheers
Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Hugh

Curioser and curioser...

To eliminate wire-lengths and resitors as a possible casue I replaced the extant Parallax micro-SD board with a brand-new one - this time soldered directly to the protoboard. There was no change, but I did observe that rather than it being a case of the code either running or not-running, there was a tendency for the first upload of a day to work. Also, if I sat there pressing F10, out of twenty uploads two or three might be successful. I've grafted things onto a new protobard anf will take things from there - so far, so good....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

rokicki

Lonesock has created a special fast-but-safe SPI layer that does not do one-bit-per-clock reads to relax the timing somewhat.
I will build this tonight and upload it for you; can you test it after that? I think it is not impossible that we are pushing the
edge somewhat in the one-bit-per-clock code. Note that write rates are unaffected.

In any case, the "slower" SPI layers should work fine, as long as you don't need the blazing speed of the default one.

Hugh

rokicki said...
Lonesock has created a special fast-but-safe SPI layer that does not do one-bit-per-clock reads to relax the timing somewhat.
I will build this tonight and upload it for you; can you test it after that? I think it is not impossible that we are pushing the
edge somewhat in the one-bit-per-clock code. Note that write rates are unaffected.

In any case, the "slower" SPI layers should work fine, as long as you don't need the blazing speed of the default one.

Thanks Tom,

I can't test it on the old board, but will willingly test it on the new version. FSRW is off my list of suspects! Between micro SD cards, SD cards, micro-SD cards in adapters and all flavours inbetween it has done 'exactly what it says on the tin'.

Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Hugh

OK, this is what is happening:

I have a piece of code and a lot of objects in a single directory. As I tweak the code and upload new versions "something" happens, after which the SD card just won't mount - nothing is returned from the 'mount' call - it just sits there. Re-formatting the card or using new cards has no effect. I then remove all references to the MCP3208 object in the code and the SD card will again mount. (This is where we came in at the original post in this thread).

However, if download a new version of FSRW (I am toggling between v1.6 and v2.6) everything works again, even with the MCP3208 object re-instated. After a while the SD card fails to mount again. I then change the version of FSRW and everything works...

I am trying to determine whether changing other objects has a similar remedial effect when the SD card stops mounting. Regressing to previous versions of the code (that I know work) will not enable the SD card to mount - only updating the FSRW files in the directory has the 'silver bullet' effect.

Any ideas? Is this down to a fundamental mis-understanding of the Propeller Tool on my part?

The code isn't elegant but is attached for anyone who wants to try and reproduce this. (The location of the FSRW object in the OBJ list has no effect).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Post Edited (Hugh) : 12/15/2009 8:55:48 PM GMT