Pulling out what hair I have left!
pgbpsu
Posts: 460
I've been working on some string routines to parse GPS strings and I've hit a snag that has me confused, befuddled, and amazed. The first snippet below works. The second causes the whole program to hang.
The first chunk is about 6 lines above the second. If I comment out the final bytemove in the second snippet or change the offending line to
I've declared things like this:
For the life of me I can't figure out why the second snippet causes a crash. I assume it's a memory leak, but how can that be? There are no other cogs accessing this memory. I've must be missing something obvious, but I've been working on it so long I think I've lost the forrest and the trees!
Any fresh eyes see the trouble?
Thanks,
Peter
' This works ' latitude N/S bytefill(@tempString,0,12) ' set whole thing to "0" bytemove(@tempString[0],@latString[1],4) ' copy ddmm from longitude string into temp_str bytemove(@tempString[4],@latString[6],4) ' copy mmmm from longitude string into temp_str
' This does not work ' longitude E/W bytefill(@tempString,0,12) ' set whole thing to "0" bytemove(@tempString[0],@lonString[1],5) ' copy dddmm from longitude string into tempString bytemove(@tempString[5],@lonString[7],4) ' copy mmmm from longitude string into tempString
The first chunk is about 6 lines above the second. If I comment out the final bytemove in the second snippet or change the offending line to
bytemove(@tempString[0],@lonString[7],4) ' copy mmmm from longitude string into tempString, the program runs as it should, of course the value in tempString isn't correct.
I've declared things like this:
DAT tempString byte "000000000000", 0 latString byte "SDDMM.MMMMMM", 0 lonString byte "SDDDMM.MMMMMM", 0
For the life of me I can't figure out why the second snippet causes a crash. I assume it's a memory leak, but how can that be? There are no other cogs accessing this memory. I've must be missing something obvious, but I've been working on it so long I think I've lost the forrest and the trees!
Any fresh eyes see the trouble?
Thanks,
Peter
Comments
-Phil
It is customary to to use the "Archive" function of the Propeller Tool to post your code. That way all the objects in question are included. You might have changed them and no one would know.
-Phil
Here's the output as the program stands (lonString is W07751.9199928)
193206 19:32:06 010411 2011 04 01 N4047.647759 40476477 W07751.919928 268527447 001 10 1271177904
Phil-
Your's was an excellent question. I added a few lines to the PROCESS_GGA method and either their addition has jiggled something loose (unlikely) or it has revealed that my program wasn't hanging like I thought.
' longitude E/W bytefill(@tempString,0,12) ' set whole thing to "0" uarts.str(DEBUG,string(13,"lonString: ")) uarts.str(DEBUG,@lonString) uarts.str(DEBUG,string(" tempString: ")) uarts.str(DEBUG,@tempString) bytemove(@tempString[0],@lonString[1],5) ' copy dddmm from longitude string into tempString bytemove(@tempString[0],@lonString[7],4) ' copy mmmm from longitude string into tempStringBefore, my output terminal window would have been blank. However, with these lines I get:
I'm as confused as ever, but my program is not hanging. Something I've done is interfering with the return value from PROCESS_NMEA_LINE (which is called in the big IF statement in the top level object). I know this because I have a debug pin
which is set high before entering the PROCESS_NMEA_LINE. Immediately after processing my two NMEA sentences, that pin should go low and it does not.
Why that is I'm still working on....
p
You're right. Here's the zip. SleepAndWakeGpsTest - Archive [Date 2011.04.01 Time 16.00].zip
I don't know if it is your case, but this is the first test I would do.
Massimo
That's a possibility I hadn't considered. The stack size for this cog is 90 longs which should be more than enough, but I'll tinker with it to see if upping that helps.
p
Ditto the stack size suggestion.
-Phil
I've increased the stack size for this cog from 90 to 100 to 200 and that doesn't solve it. I've been (maybe incorrectly) focused on this line:
Changing the last parameter of the bytemove command (number of bytes to move) has a very strange effect on things. Setting it to 0 and my debug messages start coming out right away at a rate of 1Hz. They are wrong but they arrive right away. Setting this parameter to 1 and it also starts up quickly and I get a new message every 1 second. Setting it to 2 and things don't come right away, but eventually they start arriving. Set it to three and I have to wait even longer for the first message. Setting it to 4 and I stop getting them even after waiting for several minutes. The only changes between these 4 runs is the final parameter of this one line. In each case below stack size is 200 longs.
Clearly this is a coding error. I thought it was a simple one. Maybe it's more fundamental.
Try putting in a bunch of zero's in between your strings like this:
...
ggaString byte "$GPGGA", 0
byte 0[20]
polytString byte "$POLYT", 0
...
Another possibility is that there are zeros in the strings your moving around that shouldn't be there...
I guess you've looked into stack space already... How many longs are free in your program?
Does the main SPIN cog have enough stack space?
Sorry I wasn't clear, the stack looking critical is
gps_stack[10] in NavsyncCW25.spin
Massimo
Again, thanks for looking at the code. I had forgotten about the stack space set aside in the NavsyncCW25 file you indicated. However, this code is not running in a cog launched from within the object so this stack space is not used. All the code called in this object resides cog that was launched by the top-level object. I was able to comment out the stack space variable you refer to and on INIT method and still able to get the object to compile and run as before.
Thanks for the suggestion.
I've rearranged things and now it seems to work as expected....
Thanks all for your input. I don't think anyone (including me when I first posted this) had enough info to debug this. But it was because of all the suggestions here that I kept searching for the needle.
Thanks,
p
-Phil
Knowing the structure of the program and the NMEA port baud rate, I should have looked at this earlier. It was one of your questions that made helped me discover that my program wasn't hanging. It was simply not returning a value I was expecting before printing out all the info collected from the NMEA messages. The slightly altered version is working fine. I think this explains the problems I was seeing. There are no other cogs acting on this memory so race condition or corrupt memory seemed unlikely, the cog stack had been increased to 200 longs which seems unreasonable (and still didn't help). I'm running this for a couple of days to see what the logged data look like but I'm optimistic.
Thanks again for looking over the code and making suggestions.
Kind regards,
Peter