Stacks / frame debug on ATMEGA2561

Csaba · Joined: 05 May 2012 Posts: 25

Dear Colleagues,

I’m having a probable stack problem, and I’d like to discover the stack/frame situation in my program. The program is big, 90% of an ATMEGA2561.

First I’ve played with the stack/frame sizes. It was a good play, without results. The BASCOM report file always gives the same start addresses for the two stacks and the frame, regardless of stating the stacks/frame 100, 100, 100 or 1000, 800, 800 or any numbers between. It seems it decides the stack/frame sizes itself, not much based on the required/stated sizes. At least there is no correlation seen in the report file with the required sizes written in the source program.

The BASCOM stack description is always:

Stack start : 21FF hex
Stack size : 320 hex
S-Stacksize : 190 hex
S-Stackstart : 1EE0 hex
Framesize : 190 hex
Framestart : 1BC0 hex
Space left : 2087 dec
(which is OK only for 800, 400, 400)

Then I’ve tried STCHECK, which always gives ERROR 3, even if STCHECK is the first instruction in the program. I’ve discovered here in the forum, that this is an already known problem.

My next hope was using the $lib "stackcheck.lib" library. I’ve copied a program snippet from the forum, and it gave strange results. It printed 7 bytes of software stack and all the other numbers were unbelievable, too.

The last hope is using $dbg. I’ve planted DBG instructions in every subroutine I thought residing deepest in the program. Unfortunately $dbg has given up after writing out 3-4 printouts. I came to know, that it works only if the program is in a single source file. This project consists of 78 files now, so merging them by hand is next to impossible. I have to do this merging several times during the program development to check the stacks & frame.

My questions are the following:

Is there a tool to merge source files to one single .BAS file?
(Or I have to write some perl code for it?)

Is there a reasonable hope that $dbg will give real results? Did somebody try it with a bigger program?

What other tool or method can be used to solve (see) the stack/frame scenario?

Best regards,

Csaba Sztrancsik / AtySoft

six1 · Joined: 27 Feb 2009 Posts: 553

Hi Csaba,
one hint:
try Steckcheck inside your main loop, then you will get top values of stack usage (after Prgrom runs trough all subs/functions)

best michael

Csaba · Joined: 05 May 2012 Posts: 25

Hi Michael,

Thanks for your reply.

Of course I've tried to put STCHECK in every part of the program, also in the main loop.
I've never seen anything else but ERROR 3. It would be a delight to see an error 2 or 1. I do not hope for an error 0.
I mentioned that the first line gives ERROR 3, as I think there is no way for me to do any harm to the frame than, as I did not call any subroutines at that line. This is the first line, the beginning, so there is no "before". Afterwards I can do bad things, which I have to find. But there is no reason to check, if it begins with an error before I start my program.
I think STCHECK doesn't work at all. At least for me. (or for ATMEGA256 processors.) I've read it in some post in this forum, too.

My main problem is, that I have no any other means to check the stacks and the frame usage. My only hope is $dbg, which I haven't tried yet.

Regards,

Csaba

six1 · Joined: 27 Feb 2009 Posts: 553

albertsm · Joined: 09 Apr 2004 Posts: 6197 Location: Holland

Csaba · Joined: 05 May 2012 Posts: 25

Hello,

Yes, I used exactly these routines to check my stacks and frame. Probably I misunderstood something, so I'm trying to clarify the usage.

The printed out values (HW-SW-FS) are giving me the maximum used number of the corresponding stack/frame area from the beginning of the program run. (So it can only grow.)
I can make out a sub of your code, and use it as a probe when an identifiable call is taken to it from various parts of the program.
Should any of the three numbers be bigger than the corresponding HW-SW-FS required/stated with the $HWSTACK, $SWSTACK, $framesize directives, means an error.

Sometimes there are huge numbers in SW and FS. HW-stack seems to be stable and low. Probably I can catch an error. It would be great !

Thanks,

Csaba

Csaba · Joined: 05 May 2012 Posts: 25

Dear Mark,

Previously I've mentioned that the report file contains the same number for stack sizes, regardless of modification.

albertsm · Joined: 09 Apr 2004 Posts: 6197 Location: Holland

what happens if you compile : the source is saved (but only the active window). if you use other tools, you must save it first before you compile.
after the file is saved, the $hwstack,$swstack and $framesize are grabbed from the options.
Then the editor is checked if these values exist and then these are used. These are passed to the compiler dll. these values need to be known in advance.
if you use a different editor you can best call bascomp command line util.

constants are not accepted, only numbers. so yes this is treated a bit different. I will have a look at it.

Csaba · Joined: 05 May 2012 Posts: 25

Dear Mark,

Exactly this is what happens, and it is OK. I only didn't know that it works this way.

With my method the (false) illusion is, that the compiler compiles everything from the disc sources, except the $stack, $framesize, etc. lines, for which it turns back to the on-screen version of the main file.
In reality bascom stores these variables in itself at the moment when the on-screen version is saved. (When one pushes the floppy icon on the menu line.)

In my opinion it is completely right, but those folks using some other tools to modify sources beneath BASCOM, better know it.

Otherwise they get results like me: modifying $stack on the disc file, compiling the modified file from the disc, and not seeing the effect of the $stack modification. All other modifications are appearing in the resulted compilation.

Probably my usage style is not common, and as BASCOM is already having PROJECT, there is not much need to use it.
I used it because I had no information about the BASCOM PROJECT scheme, and I was re-writing a C source to bascom, so it was convenient to have the original and the transformed files in one project.

Thanks for the answer. I think that this issue is solved and is not a problem any more. And it was only a misunderstanding from my side.

Regards,

Csaba

Csaba · Joined: 05 May 2012 Posts: 25

Dear Mark,

As you wrote