Propeller Tool V1.3

Paul M

Yesterday I downloaded and installed Propeller Tool V1.3. I tried compiling a fairly large and complex application which was successful. However, after downloading to the prop the application did not run. I reverted to V1.2.7 and everything was OK.
After some investgation I traced the problem to the "Stack_Length" object which has been updated for Proptool V1.3. The updates include:
1. The return value from the GetLength method has been changed to a Long from a string pointer.
2. Serial transmission of the stack length now uses "Parallax Serial Terminal.spin" rather than just inline code to transmit on the chosen pin.

I am surprised that this has slipped through the net as these changes will clearly break existing code; 1. because the return type has changed, and 2. because "Parallax Serial Terminal.spin" starts a new cog (which may not be available) and, by the way, never stops it, nor indeed is the any way of doing so.

As it turns out, although several objects referenced the Stack_Length object, my application did not make use of the GetLength call nor was I using the serial output feature and yet my code would not run.

In short, the problem appears to be with "Parallax Serial Terminal.spin"; removing all references to it in 2Stack_Length.spin" fixes the problem. I don't understand why, but simply having the reference to the object in the OBJ block without any calls to its methods, also causes the problem.

Surely a library object should not modified such that it breaks existing applications?? - even if it did actually work!

Paul

kuroneko

AFAIAC an included object which isn't called in any way just shuffles memory around. Which means the problem is in fact somewhere else.

Paul M

kuroneko wrote: »

AFAIAC an included object which isn't called in any way just shuffles memory around.

That makes sense.
But If I compile with 'F8 View Info' the object takes up 272 Longs of Program RAM and 55 Longs of Variable space.

kuroneko wrote: »

...... Which means the problem is in fact somewhere else.

There is no compiler error - so where do I start looking?

I have added just the reference in my main code and this also causes it to fail.
It doesn't matter where the reference is added in the list of objects
I have changed the reference name and renamed the object .spin file but this does not help.
I can add additional references to other objects without any problems.
I have added the reference to a smaller application without any problems.

Anyone?

kuroneko

Paul M wrote: »

There is no compiler error - so where do I start looking?

Your guess is as good as mine. Is us seeing the code an option?

• How does it fail (what doesn't happen)? Is it always the same location or is it random? Could give a hint re: memory corruption.
• Are all stacks big enough? Even if you think they are, make them bigger for now.
• Are all access ops within range? I know it's a pain to verify ...

Let's start with that list.

prof_braino

Need to see the code.

But I would advise breaking your complex application into its constitutent parts, and see if these work individually, then start putting them back together.
Since this erro has not been reported before, there is a good chance its something in the way you app is put together, reather than the tool.

Paul M

Thanks for the replies. The code is commercial - and long, uses bespoke pcb and hardware etc. so it would not be very helpful anyway.

I agree, not due to V1.3 of the tool; as I said, referencing the PST object anywhere in the application causes the problem and it also occurs with V1.2.7.

I have started trying to eliminate parts of the code but as you will probably agree this is a painful process - not least because of the long(relatively) compile and download times.

kuroneko wrote: »

Are all access ops within range? I know it's a pain to verify ...

Sorry, don't understand "access ops" ??

kuroneko

Paul M wrote: »

Sorry, don't understand "access ops" ??

Just tried to express any form of memory access, especially writing. Can you at least pinpoint the object where it stops working? I call it a day now (2308h).

Paul M

OK. Then the simple answer is yes. The application uses several cogs interfaced to various hardware(A/D, D/A, I2C etc.) writing values into hub ram. The main program loop reads these values, performs maths, and updates a VGA monitor using VGA_Text.Spin, sends data over a serial link, sends data via an Xbee. I cannot as yet pinpoint the object causing the problem.
Depending on which parts of the main loop I eliminate, the code stops running at different times - sometimes the display never comes up at all, sometimes it is updated a few dozen times before the crash.
I have tried eliminating the VGA object altogether but it still stops; I can tell because the serial data also stops.
Sometimes the propeller reboots - again I can tell this because I have a different code loaded in eeprom.

All I really know is that adding a reference to the PST object causes the problem.

I'll have to get back to this next week - thanks again for the suggestions.

Paul M

After further tedious testing, I am almost certain that it is not a specific object that causes the problem.
I have got to the point where adding a single line of code, e.g. X:=1 will cause the crash. I can add the code anywhere with the same results.I assume this means that valid program RAM is very close to its maximum limit and is somehow being corrupted at run time; however, the compiler reports plenty of spare RAM.
Any ideas?

Mike G

Stack space... Just a guess without seeing the source.

pgbpsu

Are you sure the system is crashing or is it hanging because of a waitcnt roll over issue. Does it come back after ~50 seconds? I've mistaken crash for "pause" more than once.

Rayman

Sounds like maybe the new objects are just a hair bigger than they were and now your program is intruding into stack space...

Is this a very big programs? How many free longs do you have?

Paul M

In response to the most recent questions:

It definately crashes; quite often the prop reboots - I have loaded a different program into eeprom so I can tell when this happens

I have only 2 objects running spin in new cogs and I have checked the stack space for these objects - they have 2-3 times more than reported by the stack length object.

It is a large program; when compiled with F8 the compiler reports 474 free longs and the code will crash.
removing just one line will result in 475 free longs and will run.

I have used both Version 1.2.7 and 1.3 of the proptool; 1.3 uses less program space so code that won't run under 1.2.7 will under 1.3. However, as soon as the free space drops below 475 the problem occurs with V1.3 also. This presumably is further evidence that it is memory corruption.

As you can tell I don't understand this very well - I looked at the manual p.80 "The Need for Stack Space" - does this imply that the main code uses some of the free ram for its stack?

kuroneko

Manually started SPIN cogs (for want of a better word) require a user-defined stack (usually a long array in VAR space). The top level object uses the memory after VAR as stack. Note that the PropTool shows this (blue) area as Stack/Free. That said, I never encountered a top level object which requires/uses this amount of stack space.

Is one of your objects relying on a certain amount of free space (hardwired addresses in high memory maybe)? IIRC one of the settings objects from the OBEX uses memory from top of RAM downwards as cache.

Mike G

I've had this exact issue. It was a bug in my code. I'm running a project that has 464 free longs. It runs fine and has been up for months

Paul M

I can well believe it is a bug and 99.99% certain it is one of mine!

As far as I am aware I'm not accessing any high memory using hardcoded addresses.

Does the fact that the 'bug' causes the propeller to reboot narrow down the possible cause?

Also, does the order of declaration/order of "first use" of objects affect their position in memory?

Rayman

400 longs is probably enough. The main Spin program does need some free stack space, but usually 100 longs is enough in most cases (unless there are recursive calls).

If you are using CogNew to start up other Spin cogs, that's another area I'd double-check for enough stack space...

Rayman

Rebooting is a little wierd...

You do know about the issue where an FTDI serial chip that is connected to the Prop, but not connected to the PC can cause a reboot, right? Are you connected to a PC when this happens?

Mike G

Does the fact that the 'bug' causes the propeller to reboot narrow down the possible cause?

Not really... The code could be running out of control and over writing another process's allocated memory or simply writing to an unexpected location. I've done that too.

Also, does the order of declaration/order of "first use" of objects affect their position in memory?

From experience the order of objects in the OBJ block defines where the object start and stop in memory. However, the VAR blocks are ordered from smallest to biggest and the DAT block is left as is. I'm not sure how the VARs behave across multiple OBJs. I'm fairly sure that the DAT blocks are static. I assume (and it appears to me ) that the VARs are lumped together regardless of the object. I'm not sure though, never tested the assumption.

Paul M

Thanks for all the continued replies without which I would have given up by now!
I've found the problem.
My main routine declared a number of local variables, including an array. The array was never used but was declared as 400 longs. When I moved the array to the VAR section it became clear that I was running out of stack for the main method - it actually required 87 longs.

At the risk of boring you all, I am now a bit confused.
Judging by the output of F8 for the following short code:

VAR
long x,y,z
long i[100]
PUB main | a,b,c,q[100]
'some random code
repeat
  a:=1
  c:=2
  b:=a*c
  i[10]:=b*c
  q[10]:=i[10]
PUB another | a,b,c
a:=1

- local variables are created on the stack and do not form part of the object's variable space?
- local variables are created when the method is called, whether they are used or not?
- number of free longs is independent of number of local variables?

What is confusing is that in my original (large) code adding local variables or changing the local array size in the main method does change the reported number of free longs, but not in a consistent way:
with 5 local variables free longs: 329
with 6 local variables free longs: 328
adding local array ARR[2] free longs:326
adding local array ARR[4] free longs:318
adding local array ARR[6] free longs:314
adding local array ARR[25] free longs:297
adding local array ARR[250] free longs:282
and finally, if the array is the last local variable declared the compiler just seems to ignore it.

Is this expected behaviour?
Should not the compiler take account of local variables for the main method since it has to run and the variables will always be created?

Rayman

Ok, I see. So your original "main" routine was like that above but with q[400]? And you only had ~400 longs of free stack space.
That definitely sounds like trouble....

It's probably not a good idea to declare huge local variables like that. It makes determining how much free stack space you need difficult...
I think it's much better to have big arrays in var or dat.

rogersyd

Rayman wrote: »

Sounds like maybe the new objects are just a hair bigger than they were and now your program is intruding into stack space...

Is this a very big programs? How many free longs do you have?

If I had a dollar for every time that happened...

kuroneko

Paul M wrote: »

What is confusing is that in my original (large) code adding local variables or changing the local array size in the main method does change the reported number of free longs, but not in a consistent way:

Not having seen your original code, I'd attribute that inconsistent behaviour to the fact that the first 8 parameters (result, method args, locals in that order) use an optimised addressing scheme whereas everything else uses a different (slower) approach (see PropManual rev 1.2, page 185, Optimized Addressing).

Paul M

Rayman wrote: »

It's probably not a good idea to declare huge local variables like that. It makes determining how much free stack space you need difficult...

Lesson learned - the irony is that the array wasn't used and a throwback to when the code was originally written - I will now have a good tidy up.

kuroneko wrote: »

(see PropManual rev 1.2, page 185, Optimized Addressing).

Thanks for that, I'm sure it must be something to do with this. My short example does not behave in the same way but is probably not a fair test.

Although I'm glad it happened, this all came about due to an updated library object in proptool V1.3 that is not backward compatible.

To wrap this up, am I alone in thinking this shouldn't happen?

Mike G

Although I'm glad it happened, this all came about due to an updated library object in proptool V1.3 that is not backward compatible.

What object caused the problem?

To wrap this up, am I alone in thinking this shouldn't happen?

I think it's a good thing you found that local 400 item array.

Paul M

Mike G wrote: »

What object caused the problem?.

The Stack Length object: it has a changed return value and now uses the Parallax Serial Terminal object (see my very first post)

Mike G wrote: »

I think it's a good thing you found that local 400 item array.

Absolutely! Lesson learned as I said. Perhaps the modified object should just have been renamed to ...V2 or something.

Heater.

"...Updated library object...does not work...that should not happen..."
It's been that way for decades. In the Windows world they call it "dll hell". Linux has similar dependency problems that the distributions package managers try to solve for you but can still bite you when developing your own code or building things from sources.
One just has to learn to be vigalent and ask "what changed" when updates cause things to break.

Phil Pilgrim (PhiPi)

This is yet another argument for some sort of version control embedded in the dev tools. Regardless of what happens in the Windows and Linux worlds, changing library routines in this manner without renaming them is rather cavalier on Parallax's part. It could have been handled better than it was.

-Phil