objects conflicting

jstjohnz

It's late, I'm punchy, so this may not be terribly coherent.

I'll try to be brief. I am seeing some sort of weird conflict between 2 objects. I have 2 objects that start a cog and run some PASM code. It started out as a single object, but I just didn't have room to cram all of the PASM into one cog, so I split the code into 2 separate objects.

At least half of the PASM is identical between the 2 objects. The idea is to load one object or the other depending on what hardware needs to be controlled.

Here's the rub. If I just define one object in the OBJ section of my SPIN code, and start that object, all is well. But, as soon as I even define the 2nd object in the OBJ block, without ever even referring to it anywhere else, the first object starts acting flaky.

I know from past experience that the Propeller Tool loads all defined objects even if they are never used, so I get that it's loading the 2nd PASM object even though I don't actually use it. But for some reason, just loading that 2nd object is corrupting the first object.

I assume that I am doing something stupid and somehow I'm inadvertently creating a situation where the compiler is sharing some code or data between the 2 objects but like I say it's late and my brain isn't functioning well.

ErNa

Always a good idea to have a project archive attached to see the source. Because a processor alway does, what you say, not what you mean ;-)

Mike Green

It's probably a stack problem or pointer error. When you include the 2nd object, things move around in memory and the stack starts higher up in hub memory. If you're accessing an array or using a pointer incorrectly, you overwrite something different.

jstjohnz

OK, working on it again tonight after some decent sleep. Is there a utility that allows you to see where the various objects reside in memory?

Dave Hein

The upper left corner of the Prop Tool shows the objects that are used. One copy of each object's executable code is placed in memory in the order that they are referenced starting with the top object. There is a unique copy of each object's VAR section for every time that it is referenced by another object. Your problem may be due to referencing an object from different objects, which results in using different VAR memory spaces. However, it's virtually impossible for us to help without seeing your code. Please post all your code.

jstjohnz

I appreciate all of the suggestions. I'm constrained re posting all code due to it's being for a commercial product, and it's a *lot* of code.

The 2 objects in question are 100% PASM code, except for the standard START and STOP procedures at the head:

VAR
long cog
long _clkmskptr

PUB Start(clkmskptr) : okay
_clkmskptr:=clkmskptr
okay := cog := cognew(@entry, _clkmskptr) + 1

PUB Stop
' Stop Pixel Driver, frees cog
if cog
cogstop(cog~ - 1)

DAT

org 0
'everything above this line is identical in the 2 objects, 'as is a significant part of the PASM code.
<<pasm code>>

I'm thinking that this is an errant spin write, possibly an array index out of bounds.

I did try a couple of things. I created a dummy object with the exact same structure and length as the object that's causing the problem. Just a series of "LONG 1" commands in the DAT block to force it to the proper length. Referencing this dummy object in the OBJ block instead of the real object caused the problem to disappear. I found that a bit surprising since everything should have been in the same locations in memory.

I also discovered that simply swapping the order of the 2 statements in the OBJ block also causes the problem to disappear. At least it's not showing itself in an obvious way. I don't mean to imply that this is a fix.

I do have one web page form that's acting strangely, I think I will look into that spin code as it may be related.

Duane Degn

When you press F8, how much space is left in hub RAM? If your free space falls below a couple hundred longs, you can run into stack issues with the initial cog.

If you have plenty of space then the issue is somewhere else (obviously).

As others have suggested, attaching an archive of the program would let us take a look at it.

Duane Degn

jstjohnz wrote: »

PUB Start(clkmskptr) : okay

What sort of pointer is passed to the Start method? If "clkmskptr" points to anything other than a long address (or at least a long aligned address), then this is likely causing the problem.

Dave Hein

jstjohnz, can you reduce your code down to a small program that still shows the problem, and post that code? Otherwise, it will be very difficult to determine the source of the problem.

jstjohnz

About 800 longs available. The passed value is the address of a long.

I will try to pin this down a bit more. I know it's difficult to work with what I've given you.

To summarize, if I have:
OBJ
object1: "firstobject.spin"
object2: "secondobject.spin"

then object2 fails to run properly even if object1 is never referenced in the spin code.

If I have:
OBJ
object2: "secondobject.spin"
object1: "firstobject.spin"

then everything appears to work properly.

The only difference is where objects 1 and 2 reside in hub ram. I think I need to focus on the SPIN code that executes before those objects are loaded. I suspect that in the first scenario object2 is being corrupted before it is started in a cog.

Dave Hein

The executable code for the two objects is loaded in memory in the order that they are referenced. The DAT variables follow immediately after the executable code in each object. So it is possible that you are writing beyond the boundaries of an object's DAT space and scribbling into the code space of the next object. The VAR variable space is located after the last object's code and DAT space. The main stack space follows the VAR space. So the other possibility is that you are overwriting an object's VAR space and scribbling into another object's VAR space or even into the stack.

If you can't post your code then I would suggest adding debug prints in your code to determine where the program stops working. This should give you an idea of where the failure is occurring.

jstjohnz

Well, the issue was embarrassingly simple. I had an uninitialized variable in one of my PASM objects. The object load order was affecting this variables initial value.

Appreciate all of the help.