Swordfish

Posted: **Tue Aug 30, 2011 12:52 pm**

Hello All,

Bit of a long rambling one this one but I was wondering if anyone could shed some light on some odd behaviour.

Been using the latest 4.1.4 SD File System lib, and everything seems to be generally working fine except when I attempt to use SD.Rename.

I keep getting "errNotFound" as the response when I know for sure the file exists (and can be checked and opened using the lib).

Just to be sure I have attempted to use the example code structure to be sure (most of the example code is included in the project to allow easy sd card debugging)

Code: Select all

		
Case "E"   // Rename
  			Name = GetName("Rename - Enter Old File Name")
         	NewName = GetName("Rename - Enter New File Name")
         	CDC.Write("Got " + Name + " " + Newname)
         	DisplayResponse(SD.Rename(Name, NewName, sdFile))

If I change this to call with the pOldName as a TSDName structure everything is file (even with the pNewName just as string), so i'm guessing there is something going amiss with the StrToFileDirName conversion.

Now, heres where my setup gets a bit odd. I am using an 18F87J50 device, and using the USB functionality. In order to utilise a bigger chunk of RAM, I have relocated the SD Shared buffer and StoredFiles buffers manually at $0C00 and $0E00 respectively. Like I said, everything else seems fine.

Looking at StrToFileDirName I can see a lot of FSR and register manipulation but to my untrained eye I can't see anything obviously wrong, but I suspect my odd setup has broken something here subtly and I was hoping someone might spot what it might be!

I have a work around for the minute of loading up the structure by hand so not desperate, just annoying to me!

Regards,

Nathan

Posted: **Tue Aug 30, 2011 2:27 pm**

Does it work any different if you comment out the CDC.Write() call?

Posted: **Tue Aug 30, 2011 3:09 pm**

Ah, yeah sorry, left that debug line in by accident. If its not there, things still are not working right.

Nathan

Posted: **Wed Aug 31, 2011 2:13 pm**

What's your RAM usage like?

With the 87J50, you only get 1K of normal RAM because of the USB BDT location at $400.

Posted: **Wed Aug 31, 2011 2:32 pm**

Very high. 991 from 1024.

Plus I'm cheating by manually placing the SD buffers above RAM BANK 7, Shared at $0C00 and StoredFiles from $0E00, both above the Swordfish "conventional 1k" memory and the USB buffers (using "Absolute"). Another big buffer is at $0800, so they arn't included in the 1k calculation.

Obviously I have to be pretty careful to keep track of what has what, but everything else seems to be behaving itself fine, just this one niggly error seems to be showing itself.

I know I'm pushing what SF is capable of here, obviously it would be nice if swordfish could handle the USB memory hole itself. hint hint

.

Posted: **Wed Aug 31, 2011 3:25 pm**

I don't see anything out of whack with StrToFileDirName either. Just to be sure I'm following you... it works with pNewName as either a string or a TDSName as long as pOldName is a TSDName... just not pOldName as a string, right? I can't test this right now, but it looks like Rename would use more ram if both were strings, but other than that I don't see much difference. The USB module in usbmem.bas should set _maxram to 1K for you anyway.

...Shared at $0C00 and StoredFiles from $0E00

It looks like that would limit SD_MAX_FILES to 8 before StoredFiles ran into the upper SFR region @ $F40.

obviously it would be nice if swordfish could handle the USB memory hole itself. hint hint .

That would be nice...

Posted: **Wed Aug 31, 2011 3:42 pm**

Correct.

pNewName has no effect, string or TSDName is fine.

If pOldName is TSDName structure, again, no issue.

If pOldName is a string the rename function always fails saying errNotFound.

I've got SD_MAX_FILES set to 2 so I shouldn't be running into the SFR's and I would have thought everything would be falling over if I was stomping all over them. It's a pretty subtle error.

Don't expend too much time on this one Jerry, I'm pretty sure it's all to do with my oddball RAM setup that probably no-one else will ever encounter, and I have a perfectly acceptable work around. I was just hoping someone might be able to spot something obvious that I missed.

Posted: **Thu Sep 01, 2011 4:19 pm**

I was playing around with this and it looks like it might be an issue with the compiler and the Rename() function, and not your code. Keep you posted...

Posted: **Thu Sep 01, 2011 6:22 pm**

I'm away over the weekend but will look into this as soon as a get back...

Posted: **Thu Sep 01, 2011 10:42 pm**

Out of curiosity, has anyone used the SD.Rename(pOldName As String, pNewName As String) version of the function before?

Has it ever worked, or did it break at some point?

Posted: **Fri Sep 02, 2011 9:42 am**

Had a play around and have found that the String rename issue as described is broken, even if RAM allocation is in handled automatically, using a cut down (SD only, no USB, no display, no absolute declarations etc.) sample application on the 18F87J50 (885 Variables used from possible 3936).

I cannot test the earlier 3.1.1. version as the hardware I have has the SD card on MSSP2 and the earlier version does not support the second MSSP.

I have played around with the SD lib previously (can't recall running into a rename issue). This is the first time I have really used the SD library in anger and it is absolutely brilliant! Opens up so many possibilities.

Posted: **Fri Sep 09, 2011 1:53 pm**

Just to round out this topic. The issue appears to have been resolved by David in the latest Beta, so again, many thanks to David and Jerry for their prompt assistance!

Regards,

Nathan

Swordfish

SD.Rename irrational behaviour with high memory

SD.Rename irrational behaviour with high memory