Possible causes for halting SPIN code execution

idbruce · 2011-05-23 04:12

Hello Everyone

I have a program that is halting execution for some inexplicable reason. What are some of the causes that will halt SPIN code execution?

Will inadequate stack space for one cog stop all SPIN code execution, or would it just affect that single cog?

Just to start any possible list that may result from this post, I will post the most obvious as #1

Loss of power

doggiedoc · 2011-05-23 04:16

2. Coding error
3. Flawed algorithm

(not to imply that these are your problems, but it's usually what it turns out for with me)

Paul

idbruce · 2011-05-23 04:20

@doggiedoc - Thanks for the response. If you have the time, could you please provide some simple examples and perhaps explain how #3 would halt execution.

Clive Wakeham · 2011-05-23 05:44

I had an issue with the object I am writing for the PCF8593 RTC.
Until I realised that a variable I was using was only byte sized and it needed to be long sized to be used for TRUE or FALSE comparisons.

schill · 2011-05-23 05:47

A problem I had the other day that took way too long to debug:

I had a bad cogstop in the Stop method of an object. The first thing the Start method did was call Stop in case a cog was already being used (pretty standard process). But, unfortunately the cogstop command in Stop was always stopping cog 0 (essentially because of a typo).

So every time I tried to initialize this new cog, I was stopping the one interpreting my main routine.

ElectricAye · 2011-05-23 05:50

doggiedoc wrote: »

2. Coding error
3. Flawed algorithm...

Things are or are not inside IF statements or REPEAT loops when they should not be or should be.
AND or OR statements are wrong.
Greater than or less than statements are in a range different than intended.
Integers are used when you really meant to use decimal numbers, especially when comparisons are made between numbers.

Just tossing those out there.

idbruce · 2011-05-23 06:05

Thanks To Everyone

This is all good information. Keep the ideas coming.

Mike G · 2011-05-23 06:37

How do you know execution halted?

Infinite loop
Overwriting a main RAM value used elsewhere
Using a pointer as a value or a value as a pointer
Bad or unexpected input values

ElectricAye · 2011-05-23 06:41

Code is waiting for a response from a sensor but the sensor is out to lunch.
Code is waiting for an input from its author, but its author needs more coffee and forgot to hit the ENTER key.

Mike Green · 2011-05-23 06:48

Inadequate stack space can cause all sorts of things to happen as can array access out of bounds. It depends on what code or other variables were overwritten. Unfortunately, the eventual program failure often occurs in places (in the program's operation) and times remote from the original error.

Dave Hein · 2011-05-23 07:18

idbruce wrote: »

@doggiedoc - Thanks for the response. If you have the time, could you please provide some simple examples and perhaps explain how #3 would halt execution.

Bruce, it would be more efficient if you posted your code. There are lots of ways that a program can fail. If you don't want to post your code, then I would suggest you start adding a few debug prints, or at least flash an LED to see where the program becomes unresponsive. If you have a free cog you could add some debug code in the spare cog that watches hub locations, and prints out debug information if it detects something wrong. You could also write to a trace file if you are using an SD card, or you could write trace information to the EEPROM. Of course, if you think the problem is stack overflow, just increase the size of your stacks until the problem goes away.

doggiedoc · 2011-05-23 07:24

idbruce wrote: »

@doggiedoc - Thanks for the response. If you have the time, could you please provide some simple examples and perhaps explain how #3 would halt execution.

The general example I had in mind is when the cog runs out of code and stops. The code may be syntactically correct but logically has no further execution to perform. I guess now that I've tried to elaborate on my thoughts, that could be a high level coding error as apposed to the algorithm per se.

Hope my explanation gives you insight to my thoughts.

Paul

On EDIT:
I know you have had issues in the past with posting your code for proprietary reasons but it may help to have someone else look at your code. Perhaps there is someone you trust that you could share your code with privately.

idbruce · 2011-05-23 08:16

Thanks All Those That Are Participating In This Thread

Code is waiting for a response from a sensor but the sensor is out to lunch.

This is not quite my problem, but close. I have not figured it out completely, but I have narrowed the problem down to two functions which perform sensor readings. And the two functions have worked perfectly in the past. So I am assuming that the problem is due to a recent alteration.

Here is the situation. On my wire bending CNC, I have a bending head which is constructed from 1/2" steel rod and two hardened 1/6" dowel pins pressed into to the top of the steel rod. One dowel pin is the center pin, and the other is the bending pin. To quickly and accurately position the bending head for CW and CCW bends, I have painted the entire bending head flat black except for a small stripe adjacent to and parellel to the bending pin, and I am using two QRB1114 reflective object sensors to achieve the proper CW or CCW positioning with the following code.

PUB RepositionBenderForCWBend | Counter, CycleOffset
  CycleOffset := MIN_SPEED
 
  CTRA[30..26] := %00100 ' Configure Counter A to NCO
  CTRA[5..0] := Bender_Step
  FRQA := 1
  DIRA[Bender_Step]~~  
 
  Counter := CNT
  REPEAT UNTIL NOT INA[6]
 
    PHSA := -HIGH_PULSE_WIDTH
    WAITCNT(Counter += CycleOffset--)
 
PUB RepositionBenderForCCWBend | Counter, CycleOffset
  CycleOffset := MIN_SPEED
 
  CTRA[30..26] := %00100 ' Configure Counter A to NCO
  CTRA[5..0] := Bender_Step
  FRQA := 1
  DIRA[Bender_Step]~~  
 
  Counter := CNT
  REPEAT UNTIL NOT INA[1]
 
    PHSA := -HIGH_PULSE_WIDTH
    WAITCNT(Counter += CycleOffset--)

However, during a recent alteration, the diameter of the bending head was reduced by approximately 1/16", and I have not altered sensor placement to compensate for the change. I am assuming this is the problem. However, in the past, improper sensor placement either caused the bending head to spin continuously or just stop at improper locations. I never had these functions just stop program execution before.

Anyhow, I appreciate all the comments. It is a good subject with good input for troubleshooting. I hope the input keeps coming.

Bruce

EDIT: Additionally, I have also recently altered the MIN_SPEED constant value. This could also be part of the problem.

ElectricAye · 2011-05-23 08:27

idbruce wrote: »

.... I have painted the entire bending head flat black except for a small stripe adjacent to and parellel to the bending pin, and I am using two QRB1114 reflective object sensors to achieve the proper CW or CCW positioning with the following code.....

Any chance that the small change in geometry has effected a reflection you did not intend? Could the light source be hitting the flat black at such a raking angle that it is glancing off, bouncing around, hitting reflective metal parts and messing up the measurement? The QRB is in IR, and flat black paint might look black in the visible spectrum but be more reflective than you think in IR.

Just a thought.

idbruce · 2011-05-23 08:35

ElectricAye

I would say the geometry change may have affected it. If I move each sensor 1/32" closer to the bending head to compensate for the 1/16" diameter change, it may work perfectly again. But I also suspect the MIN_SPEED constant alteration.

It works perfectly or it halts program execution. Whatever it is, it is right at the borderline.

Dave Hein · 2011-05-23 08:45

Bruce, what is the value of MIN_SPEED? You initialize CounterOffset to MIN_SPEED, but you decrement CounterOffset every time it loops. If it gets too small the target cycle count for waitcnt will be less than the value of CNT, which means that waitcnt will wait for 4 billion cycles instead of just a few hundred or thousand cycles. You should limit CounterOffset to a minimum value that will prevent this.

EDIT: I ran your loop under SpinSim, and it takes about 2500 cycles per loop. So CounterOffset should not be allowed to get below this. A minimum value of 3000 should be safe to use.

Chris Savage · 2011-05-23 08:48

idbruce,

A very useful debugging tool is the ability to track the progression of your code as it runs. You can debug messages to the console for this purpose, or, if your application uses the PC connection for other use, you can use a simple LCD display. But you can use these tools to track the entry (and exit) points into the various routines. When the program stops, you will know where it stopped and narrow your search down to that area. At that point you can focus on displaying the status of variables in that method to see if something if ending up outside of nromal range.

idbruce · 2011-05-23 08:53

@Dave Hein

but you decrement CounterOffset every time it loops

Both of those functions should read

WAITCNT(Counter += CycleOffset)

I believe you hit the nail on the head. I have not tried that fix yet, but that is definitely a typo and programming error. Good catch!

Bruce

Dave Hein · 2011-05-23 08:56

Yes, the auto-decrement of CycleOffset did seem a bit strange. I thought you might be doing some kind of accelerated ramp up. I hope that resolves the issue.

idbruce · 2011-05-23 09:04

@Dave Hein - Now that you mention it, the accelerated ramp up was my intention. And the value of MIN_SPEED is declared at 8000. But now there is another scenario. The MIN_SPEED declaration is a constant and I am trying to decrease it with every loop iteration. That sounds like an OOOOPPPS. Would that cause my problem?

idbruce · 2011-05-23 09:12

@Chris Savage - Thanks for your input and I agree with you 100%. My machine is very difficult to connect to a PC, so I do not have the luxury of nice debugging. However, I do have a 2X20 LCD on the machine, but it is a muti-prop machine, and I just have not had the time to write some good debugging routines to communicate between the props. But it is a necessity, I agree.

Dave Hein · 2011-05-23 09:40

Bruce, you are initializing CycleOffset to MIN_SPEED, and then decrementing CycleOffset, which is fine. If you start at 8000 you will reach 2,500 after 5,500 loops. That should take about one-third second at 80MHz. If the input bit changes in less than one-third second it will work fine. If it takes longer than one-third second there will be a problem. As I said, you can resolve that issue if you limit the minimum value of CycleOffset to 3000, or maybe 3,500 to account for the additional instructions in the loop.

StefanL38 · 2011-05-23 10:03

May I add that EZLog from hannoware can be easily used to show values of variables through another cog not affecting the rest
except that for showing the execution-progress you add
a variable and change the value depending on the executed part of the code

if .....
DebugVar := 1

case ....
DebugVar := 2
do xyz..
DebugVar := 3

repeat .....
DebugVar := DebugVar +1
etc.
best regards

Stefan

idbruce · 2011-05-30 04:40

@Dave Hein - Hey Dave, just wanted to let you know that I finally got around to working on those functions again and you were correct. It was those decrementors that were giving me problems. I forget when I tacked those on there, but it certainly was not my brightest moment. Even if I was to gain some speed, I would not gain much, because when those functions are called, the bending head is only turning one half of a revolution or 1000 steps. It would have probably drove me nuts for days, because I certainly would have overlooked that. Thanks for your guidance Dave.

Bruce

Possible causes for halting SPIN code execution

Comments