parameter stack of state machine

[gtiani]

Hello,
I'm trying to track down a bug that is killing the state machines when both serial ports are under heavy use.
Is there a way to see how many numbers are on the parameter stack of the different state machines from the forground task? Something like the ".S" command that can be typed from the forground except that shows the number of parameters on the stack for the state machines.
I don't really need to see the actual values only the count so I can see if there is an accumulation on any of the state machine stacks.
Thanks,
Gary

[RMDumse]

There isn't really anything built in to let you see stack depth from the foreground of the background, because by the time the foreground runs the background has run and is all over.

So, you might build something into the background.

Consider making a variable and storing the stack depth difference in it. On entry into your background thread do a DEPTH and at the end do another DEPTH and subtracted the two, then stored the result in a variable. Now in the foreground you could look at that result and see if it remained 0 always, or changed.

I think that would get you the essence of what you are asking for.

[gtiani]

I found the bug. It was an underflow condition caused by droping one too many values in one of the state machines. I'm surprised it ran as long as it did. Each message dropped one extra parameter. There were hundreds of extra drops before the ServoPod crashed. I guess it's good that the ServoPod can keep running with such a serious bug. But, it means I will have to improve my code testing methods. I'll try your suggestion for checking the state machine stacks.
Thanks,
Gary

[RMDumse]

As I originally envisioned isoMax(TM) the interrupts worked on the existing stack, however, to protect against just this sort of problem our programmer Brad chose to make a separate stack for the interrupts. So the background data stack is moved when the background runs and is released after it finishes. So we tolerate some stack problems without immediately blowing up.

This did give us a problem with DEPTH and .S in the background, and we later had to change them to deal with this move, otherwise they showed hundreds of things on the stacks during background. I forget which code version we changed that in, bu it is handled now.

So overall, I think it was a good thing.