CLKFREQ mysteriously jumps from 80mhz to 824,195,128
R Pankau
Posts: 127
I could not figure out what was going on with my interrupts, all of a sudden the interrupts were taking roughly 10x longer between executions.
this is my clock setup
_clkmode = XTAL1 + PLL16x
_xinfreq = 5_000_000
at boot up CLKFREQ returns 80,000,000 as expected, then after writing to the SD card once it returns 824,195,128 instead. (using fsrw.spin) then it appears to stay put. essentially making all of the waitcnt instructions take a little over 10 times longer.
I've had other strange things with this board as well, for instance if I use SD-MMC_FATEngine instead, then the SD driver will not operate if GPS_IO_mini.spin is used in the same project. I suspect that some resource is being shared not so well but I cannot figure out which one.
this is my clock setup
_clkmode = XTAL1 + PLL16x
_xinfreq = 5_000_000
at boot up CLKFREQ returns 80,000,000 as expected, then after writing to the SD card once it returns 824,195,128 instead. (using fsrw.spin) then it appears to stay put. essentially making all of the waitcnt instructions take a little over 10 times longer.
I've had other strange things with this board as well, for instance if I use SD-MMC_FATEngine instead, then the SD driver will not operate if GPS_IO_mini.spin is used in the same project. I suspect that some resource is being shared not so well but I cannot figure out which one.
Comments
By the way ... what do you mean with interrupts? There is no such concept for propellers.
Waitcnt needing longer than expected you have when you just missed the cnt!
You should post your code!
the "Null[0] right off the bat has me thinking that it's writing to location zero.
the "interrupt" I refer to is just this, running it a separate cog. and I use cntr a global var to trigger subs then clear cntr,then wait again. I had CLKFREQ in the waitcnt instruction at first then switched it to 80Mhz and noticed that things began working better.
I also use byte addressing in this, which is where all the writing to the sd card happens. but I believe it should never affect location zero....requires a closer look though.
maybe I should have used byte[@lat_and_long][0], I assumed that referencing a var array would return the address of the first byte, but.... now I see that by clearing the array to zero, or if it starts out that way, the byte[effectively zero][0] then writes to location zero.
Now if I could find the switch to turn off "unsolved" on the forum heading.
So, if you still have the problem after changing back you did not fix the original bug yet and this means it can also overwrite other parts which cause more harm!
It's better to post the whole truth, because the bug might be at a place you'd never expect it to be! The propeller tool has a niche archive function which zips all needed files from actual file point of view. So, select your top-file and do an archive and post it here.
I think your code is fine, but the GPS code seems to be buggy, starting wit this:
byte gps_buff[80],Rx',cksum
....
longfill(gps_buff,20,0)
This overwrites the whole begin of HUB-RAM propably destroying something in your code which makes it write to wrong memory locations as well.
My expectation was that longfill works the same way as bytemove, which needs a pointer to the memory. If my expectation is wrong I'd say that SPIN has an inconsistency in the syntax.
If my expectation is correct, gps_buff is an array to store the incoming string. Using it without @ means that
gps_buff[0] is read and used as address which is 0.
@R Pankau: would it be possible to get a data dump of the stuff coming from the GPS unit for one of the failure cases? I don't have any GPS h/w so that would kind of help figuring out where it goes wrong.
the incompatibility that I spoke of in my first post I believe is happening before any reading of gps data takes place.
for instance the SD_MMC fat engine has written for it a SD card profiler demo program, if I run that demo everything is great, if I load the gps object in the same project even without calling it the demo crashes with no apparent cause, nothing is written to the sd card, i believe usually the error string is written to the card if it was successfully mounted with a file open.
I used coginit once as a troubleshooting method, thinking I had a faulty cog possibly, also rearranged the order of starting the objects. it just needs to be switched back to cognew.
$GPRMC,032531,A,3016.3376,N,08811.8669,W,000.0,000.0,250312,,,A*61
$GPGGA,032532,3016.3377,N,08811.8667,W,1,03,02.4,00237.5,M,-033.9,M,,*7A
$GPGSA,A,2,08,11,19,,,,,,,,,,02.6,02.4,01.0*00
$GPGSV,3,1,11,01,28,140,26,03,13,050,00,06,02,047,00,07,76,142,33*73
$GPGSV,3,2,11,08,62,317,34,11,46,124,41,13,18,192,26,17,13,220,00*77
$GPGSV,3,3,11,19,48,051,41,26,19,315,30,28,34,283,00,,,,*40
$GPRMC,032532,A,3016.3377,N,08811.8667,W,000.0,000.0,250312,,,A*6D
$GPGGA,032533,3016.3376,N,08811.8669,W,1,03,02.4,00237.5,M,-033.9,M,,*74
$GPGSA,A,2,08,11,19,,,,,,,,,,02.6,02.4,00.9*08
$GPGSV,3,1,11,01,28,140,00,03,13,050,27,06,02,047,00,07,76,142,33*72
$GPGSV,3,2,11,08,62,317,34,11,46,124,41,13,18,192,00,17,13,220,26*77
$GPGSV,3,3,11,19,48,051,41,26,19,315,29,28,34,283,00,,,,*48
$GPRMC,032533,A,3016.3376,N,08811.8669,W,000.0,000.0,250312,,,A*63
$GPGGA,032534,3016.3375,N,08811.8671,W,1,03,02.4,00237.5,M,-033.9,M,,*79
$GPGSA,A,2,08,11,19,,,,,,,,,,02.6,02.4,00.9*08
$GPGSV,3,1,11,01,28,140,00,03,13,050,00,06,02,047,00,07,76,142,34*70
$GPGSV,3,2,11,08,62,317,33,11,46,124,41,13,18,192,00,17,13,2
I assume you at least started it?
here is the sd card test. it fails with either gps parser.
Also, the object uses a cut down version of FDS but sets the transmit pin to 0 which I believe is used by the SD card interface. So if you could move that out of the way and see if it resolves the issue (serXmit). That said, the other parser object (Lite) doesn't have the pin conflict so something else is going on here.
Note that the attached object also uses 0 for tx. Just set it to something unused.
Edit: Just in case, there should be a buffer length check (while Rx <> CR and cptr < 80).
The SD-MMC_FATEngine.spin object is a pretty nice SD object, so I may try to redo this now that it works.