View Full Version : Strange clkfreq problem...
12-17-2009, 11:53 AM
Ok, so I've been having a problem with timing in my program. I narrowed it down to the "clkfreq" issue in my wait() commands. Apparently, for some god forsaken reason, my clkfreq is set to 1414743380(???)
Here are my clock settings...
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
ANY idea what gives?
12-17-2009, 12:02 PM
The CLKFREQ value is stored as a long in locations 0-3 of hub memory. Unless your program changes it, it is set by the Spin compiler, calculated from _xinfreq and _clkmode, and loaded by the Prop's boot loader. For the settings you've shown, it'll be 80_000_000. If it's not, your program has somehow changed it. Maybe you're using a pointer somewhere that's set to zero.
12-17-2009, 12:07 PM
... my clkfreq is set to 1414743380(???)
That equates to $54534554 which is either 'TSET' or 'TEST' in ASCII. Does that ring a bell?
12-17-2009, 01:21 PM
LOL wow... Yes, "Test" is a name of a file I am messing with on my SD card. That's a great place to "point" me in the right direction! Thanks Mike and kuroneko!
12-17-2009, 01:35 PM
Hmmm, that's strange... The following lines of code were causing the problem, with the first in particular:
repeat while !(done := SD.nextfile(buffer))
Where the SD object is the fsrwFemto object from the obex. The idea, was to print out a list of all the files on the SD card. It's totally not needed, but I was going to use it for debugging... Little did I know my debugging would cause further debugging.....
12-17-2009, 01:47 PM
Ah, the old "buffer instead of @buffer" ploy, eh? Swine code!"
Piranha are people too.
12-17-2009, 02:53 PM
D'oh! *smacks palm into forehead*
I can't believe I could be so dumb... This is one of those times I wish I could delete my original post out of sheer embaressment.
Regardless - thanks guys!
EDIT: I take it back... The code works when I'm not referencing the pointer to buffer. When I pass the pointer, it spits out a bunch of jibberish instead of the file names. However, when I pass buffer by itself, the filenames are printed, BUT the clkfreq is screwed up again.
Post Edited (Philldapill) : 12/17/2009 8:05:34 AM GMT
Beau Schwabe (Parallax)
12-17-2009, 03:03 PM
"This is one of those times I wish I could delete my original post out of sheer embaressment." - think of it this way.... Now your just one-up on me. http://forums.parallax.com/images/smilies/smilewinkgrin.gif
Beau Schwabe (mailto:email@example.com)
IC Layout Engineer
12-17-2009, 03:07 PM
I think we should have some big red stickers on the tops of our monitors with the "#" and "@" symbols on them.
For me, the past is not over yet.
12-17-2009, 03:21 PM
Ok, so this seems to work just fine... It's late and my brain isn't up to par, so forgive my small blunder... This IS the way it should be done, right? Again, my intent is to just print out the files in the current SD card root directory.
repeat while !(done := SD.nextfile(@buffer))
12-17-2009, 03:30 PM
Here's my code for a directory listing:
' opening the dir is just like opening a file
repeat while 0 == sdfat.nextfile(@tbuf)
' show the filename
term.str( @tbuf )
repeat 15 - strsize( @tbuf )
term.tx( " " )
' so I need a second file to open and query filesize
sdfat[ 1 ].popen( @tbuf, "r" )
term.dec( sdfat.get_filesize )
sdfat[ 1 ].pclose
term.str( string( " bytes", $0D ) )
Note that I am using multiple copies of FSRW, that way one is opening the directory listing, and another checks the filesize.
Piranha are people too.