Untentional self-modifying code or tropming on memory?

John Abshier · 2008-06-14 01:48

Outline of code (complete project is attached)

John Abshier

CON
   _clkmode = xtal1 + pll16x
   _xinfreq = 6_000_000
VAR
   long escapeStack[noparse][[/noparse]400], attackStack[noparse][[/noparse]40], pursueStack[noparse][[/noparse]40], driveStack[noparse][[/noparse]40], telemetryStack[noparse][[/noparse]40]
   long wantControl[noparse][[/noparse]NUM_BEHAVIORS], speed[noparse][[/noparse]NUM_BEHAVIORS], turnRate[noparse][[/noparse]NUM_BEHAVIORS]
   long CYCLE_TIME, wait, startWait
   long leftmotor, rightmotor
Pub Main | i
   CYCLE_TIME := clkfreq * 5 
   Init
   wait := cnt
   repeat
      wait +=  CYCLE_TIME
      sio.dec(CYCLE_TIME)
      waitcnt (wait)
PRI Init | cog
   sumo.Init
   SumoBot.Init
   sio.Start(31,30, 0, 115200)
   cognew(Esc(@wantControl), @escapeStack) ' need to check if free

edit:· in summarizing the code I left out the incrase in wait.

The printed value of CYCLE_TIME in the repeat loop is 0 then 45 then 45. The waitcnt waits about a minute. If I comment out the cognew statement in Init, the value of CYCLE_TIME is 480000000, the correct value, and the repeat loop takes 5 seconds a requested. escapeStack is set to 400. If I hardcode the value of CYCLE_TIME with an assignment statement, I get the same results. I don't know how to proceed. The text file attachment are the results of several runs.

Post Edited (John Abshier) : 6/14/2008 2:01:29 PM GMT

hippy · 2008-06-14 12:20

If it's not a stack overflow, you could have an array indexing error somewhere. Making
"long CYCLE_TIME" the first declaration or putting a "long dummy[noparse][[/noparse]1000]" before it should
hopefully prove that.

You're going to have to start putting debug checks in your Esc() routines and everything
that calls. You can pass the address of CYCLE_TIME into Esc() and then check it is what
you expect and give some indication or halt the code when wrong. Move the check around
and you'll find two points between which CYCLE_TIME gets corrupted, then it's a case of
narrowing it down to find exactly where, then working out what's causing it.

John Abshier · 2008-06-16 22:30

I "solved" the problem of CYCLE_TIME being stomped on/modified by removing it from the VAR section and making it a local variable in PUB Main. I wonder if I am now stomping on leftmotor which I think is now at the address that CYCLE_TIME used to have.· I have a bad feeling of alligators waiting to bite since I don't know what/why CYCLE_TIME was getting changed.

New debug.spin file is attached.· There are no changes to other files in the previously attached archive.

John Abshier

hippy · 2008-06-17 01:01

Just moving CYCLE_TIME to somewhere else probably does leave another variable to be stomped
on. Probably best to get on with that debugging and find out where it's happening or you most likely
will get bitten later. Besides, if something is writing out of bounds, it's not writing in bounds which is
another way in which your code isn't doing what you want it to.

John Abshier · 2008-06-17 14:50

Problem solved: It was subconscious FORTRAN array handling. Arrays start at 0 not 1 in Spin.
Thanks hippy. By the way, are you the same hippy that is on the PICAXE forums?
John Abshier

hippy · 2008-06-17 17:05

Glad you got there; knew you would. And yes, the one and same.

Untentional self-modifying code or tropming on memory?

Comments