Method calls failing.....
Sniper King
Posts: 221
I am having a huge problem with method calls working sometimes and crashing the code other times.· Below are the Objects I am using and the Variables I am using.· I have put in precations to prevent going outside my array values so i know that is not the case.· Sometimes if i change a method from public to private it will work.· But some other method will fail.· I can get the loop to work perfectly one time and then the second time around a method will fail and the software will crash.
I am using...
·········LED···· : "uOLED_Small"
········ GPS····: "GPS_IO_mini_PNAV"
········ Debug : "FullduplexSerial"·
········ Comm· : "FullduplexSerial"
········ FS····· : "Floatstring"
········ FP···· ·:· "Float32Full"
········ num··· :· "Numbers"
Variables
·long TMN
long TMCNTd
long TMCNTs
long TMS
Long TMCNTn
long TMD
long Count·
long Heading
byte buttons[noparse][[/noparse]1]
long stat911
byte BFTMode[noparse][[/noparse]1]··· 'N for Navigation , S for standard(Sleep)· E for emergency
byte Separation[noparse][[/noparse]1]
byte latitude[noparse][[/noparse]35]
byte longitude[noparse][[/noparse]35]·
byte lat[noparse][[/noparse]35]
byte lng[noparse][[/noparse]35]
byte answer[noparse][[/noparse]4]
byte Serial[noparse][[/noparse]10]
long lats
long lngs
long wlngs
long wlats
long TmCnt911
Long Tm911
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
I am using...
·········LED···· : "uOLED_Small"
········ GPS····: "GPS_IO_mini_PNAV"
········ Debug : "FullduplexSerial"·
········ Comm· : "FullduplexSerial"
········ FS····· : "Floatstring"
········ FP···· ·:· "Float32Full"
········ num··· :· "Numbers"
Variables
·long TMN
long TMCNTd
long TMCNTs
long TMS
Long TMCNTn
long TMD
long Count·
long Heading
byte buttons[noparse][[/noparse]1]
long stat911
byte BFTMode[noparse][[/noparse]1]··· 'N for Navigation , S for standard(Sleep)· E for emergency
byte Separation[noparse][[/noparse]1]
byte latitude[noparse][[/noparse]35]
byte longitude[noparse][[/noparse]35]·
byte lat[noparse][[/noparse]35]
byte lng[noparse][[/noparse]35]
byte answer[noparse][[/noparse]4]
byte Serial[noparse][[/noparse]10]
long lats
long lngs
long wlngs
long wlats
long TmCnt911
Long Tm911
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
Comments
This is the second thread you've begun on the selfsame topic in as many days. It would be helpful if you could respond to comments/suggestions in yesterday's thread rather than starting over. For example, did you check out any stack allocation issues that might exist? Did it help?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
Nothing that you've said is very helpful in sorting this kind of thing out. This is the sort of thing that only painstaking tracing and debugging output will help narrow it down to the area of the program involved and the state of the program when the problem occurs.
Although things are never "impossible", it is very unlikely that the problem has anything to do with the compiler or the interpreter or the library objects. You may have checks for subscripts out of range or invalid pointers, but it's very difficult to separate out what you intended for the program to do vs. what you actually coded.
Post Edited (Mike Green) : 9/19/2008 9:14:25 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
it's true what Mike says:
if you want to narrow down the problem you have to check EVERY single line which uses OR changes an array-value and other lines of code
looking through the code guessing "- no there it isn't " - makes you run over the interessting point a thousand times until you decide to check it too
to make it faster to find the place make lines of code that check array-boundaries and if the boundaries are broken send a debugstring with information of
which method which line of code inside the method
As you refuse to send your complete code you have to do most of the work yourself
Did you increase stackspace always for one object and then test again ?
then increase stackspace for the next object and test again ?
did you check every parameter is treated as long
every result given back from methods is a long
all local variables are longs
another way of narrow it down is to comment out one object
if results processed by this object is needed many times in other objects
make a constant dummyresult instead
this all is NOT "just add three lines of code and we will find it"
but as complex as yor project is the effort to find the fault has its size
In general for developing software in the long run a strictly modular style of programming pays off
by much lesser time spend on debugging.
This means: every method does ONE senseful thing
use parameters instead of global variables whereever possible
Be careful about changing global variables
especially if more than one cog changes tis variable
then the order of the setting of a variable can vary a lot
if YOU think this method in cog 1 will be always finished before cog 2
is doing something with it I bet this is NOT true in the long run.
there will be crossover changing the value
You can avoid this be using semaphores and locks
In my former company i was coding in delphi for maschinecontrols
We used a strictly sequential way of code-execution for critical sections to make 100% sure
that things will be executed in the order we wanted it to
this makes it much easier to track on errors
We coded so called statemachines to realize that
test every method of this style on it's own
test the behaviour if it with VERY strange parameters
test it with zero, test it with 254, 255, 65535, 65536 with 2^32 2^32-1 test it with -100
etc. etc. if an error occurs and you have done all this testing you can be 99.9% sure
the error is caused in your actual new tested method (and not in previuos tested methods
best regards
Stefan
··· This is creating an array of strings that can be read by calling each method.· The stack portion I am not sure about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
Can we also have a look at that? Since the name has been changed from fullduplexserial to fullduplexserial_mini I'm ***UMING you have made modifications to that object. This is necessary so we can see what your code is ACTUALLY doing. Since this object was renamed we would like to know if, if anything was changed, so we don't have to waste time running a 'diff' on the code.
·
Also since it was not included can we see what:
Are set for?
It would be a whole lot easier if you would post an 'archive' of code that exhibits the problem so those that are willing to look, and help, would have all of the resources available to debug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Post Edited (Mike Cook) : 9/19/2008 11:14:28 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Ouch, thats not suppose to be hot!··
Michael King
Application Engineer
R&D
Check out Project: PSAV Persistent Sailing Autonomous Vehicle