Compile oddities and frustration

Erik Friesen · 2012-02-02 13:41

I have here my complete code, its more than one can really grasp in a few minutes, but here is the gist of my problem.

Adding or removing items to my code renders it unusable or usable, independent of the added code functionality.

In the zip here, notice in the top file, that changing the - text : "s6b0724unv1.0small" - from the top to the bottom of the object series does this. At the bottom the screen outputs gibberish, and modules fail to start. With text at the top everything appears ok, but I have a function (clkmenu) that hangs, and will not return.

I am used to the pic stuff, and the inability to debug this problem is driving me nuts.

Erik Friesen · 2012-02-02 13:44

Graphic proof.

StefanL38 · 2012-02-02 14:11

as this problem depends on size of the code
the problem might be
- a too small stack
- an array that writes to RAM out of its borders
- a pointer that points to the wrong place in RAM

if some more code is added the RAM-overwriting has this effect.

This is only a quick guessing. I haven't looked inside your code

best regards
Stefan

Dave Hein · 2012-02-02 14:19

oscbuffer is defined to be an array of 128 bytes, but you have the follow code that writes into a 129-th location.

   repeat lt from 1 to 128
      oscbuffer[lt]:=adc.average(5,scti)*505/10000/3

lt should go from 0 to 127, or you should declare oscbuffer as an array of 129 bytes.

Erik Friesen · 2012-02-02 14:24

This doesn't have to do with amount of code, but rather alignment, perhaps byte/word misalignment I have been over every stack, don't really think that is the problem, unless you are referring to the main spin stack.

Good catch hein, unfortunately that method isn't being called here, I'll fix, but can't be the issue here.

Dave Hein · 2012-02-02 14:45

What is the page size of the EEPROM you're using? Your program won't work correctly if it's less than 128 bytes. I don't think this is causing the program to hang, but it might be a problem.

You are probably scribbling into memory somewhere. If the last object is failing, then it might mean that you're scribling into the area just before the VAR section. Try putting a long dummy array at the beginning of the VAR section of the top object to see if this makes the problem go away. If so, then try reducing the size of the dummy array until the problem happens. The dummy array would be placed as follows:

VAR
  long dummy[100]
  byte trip1234[30], notes[64]

The contents of dummy should always be zero, if it's not zero then you are scribbling into it.

Erik Friesen · 2012-02-02 18:47

Thanks Hein, that got me thinking. Its been a while since I did this, and I went through and checked my repeats. My i2c object was writing one too far when reading from the eeprom. I think that was the problem, well see for sure yet.

Erik Friesen · 2012-02-02 19:19

One thing I'd like to see, is a microchip style map file output from the compiler. It would be rather handy in understanding the why's of this. I suppose that code and data are completely intertwined.

jazzed · 2012-02-02 19:35

Erik Friesen wrote: »

One thing I'd like to see, is a microchip style map file output from the compiler. It would be rather handy in understanding the why's of this. I suppose that code and data are completely intertwined.

BST/BSTC can create a list file that has all the compiled addresses in it. It seems to give much more info than a map file.

Erik Friesen · 2012-02-03 05:00

I use bst, but its difficult to find what you want as there is no search function.

Publison · 2012-02-03 14:37

I haven't tried your code yet, but did you try the original BS2.spin code?

http://obex.parallax.com/objects/30/

Compile oddities and frustration

Comments