HC08 stack usage question

[erokc]

I am moving from HC05 which has a fixed stack location in RAM.  I have avoided stack and variable conflict by not assigning variables within the defined stack addresses on the HC05 device.

The HC08 has a more flexible stack.  I need to determine what the worst case is for stack usage in my program.  Will Code Warrior and the FSICEBASE monitor that for me?

How does a programmer handle the stack RAM vs. variable RAM boundary?

Thanks, Dave

[YeOldeBDM]

You are able to specify the size of the stack in the .PRM file for your project & target.

The linker will not place any data or constants in this resulting stack region unless you have defined a variable or constant with an absolute address that lands in this region. There are not many reasons to do this.

It is possible for you specify to make a stack whose size is too small. Then you will run into big problems as the stack can overwrite ram which holds global or static variables. Or you may escape problems if th overwritten ram is not used by your application. But it is good design practice to ensure by analysis or testing that the size of stack you have specified is sufficient to prevent stack overflows.

[bigmac]

Hello Dave,

Of course, this assumes that you will be programming in C (that you probably were not when using the HC05).

For the smaller HCO8 devices with limited RAM size, it is probably a good idea to position the stack to the top of RAM, and commence the allocation of global and static variables at the start of zero page.  This will allow the widest separation of the stack from the data, irrespective of the allocated stack size.  When a project is created, the default .PRM file will not necessarily provide this arrangement - you will need to check, and modify as required.

The debugger does not provide any warning when the allocated stack size is exceeded - you need to test for actual stack usage, as previously mentioned.

Regards,

Mac

[erokc]

I'm always hoping for a simple solution but it rarely comes.  The P&E PROG08SZ is definitely a good solution for FLASH programming on board. Thanks to Bigmac. Back to the subject.

 My project relies heavily on external input to timer and IRQ interrupts.  The two signals are not synchronized and must not be missed.  One signal is pulse width measurement and the other is simply a counter. I test by supplying the fastest expected rate to the inputs and compare the stored result in the target to what was sent.

I am still programming in assembly.  I need the interrupt routines to be quick so I think the stack location in page zero should be faster.  Is that correct?  In any case it looks like I need to determine how much stack space is needed. 

Is there a way to trace the stack pointer when I run my tests?

Is there a method of adding up the usage based on interrupt, subroutine calls nested worst case, etc.?

I disable interrupts during an interrupt service so they don't nest.  If they are occurring faster than they can be serviced it's a loss of signal situation anyway. I put the variables used in the interrupt service on page zero.  The others can be on page 1.

All of my variables are static at this point.  I now have the option to pass variables through the stack for the math routines if I chose to (HC908AP16).  I would have to add those to the stack usage also.

Your help is appreciated.

Dave

Message Edited by erokc on 2007-04-1204:13 PM

[bigmac]

Hello Dave,

Firstly, the stack operations take the same number of cycles, irrespective of where the stack is located.  So it is better to move the stack away from zero page, and use this area for other variables.

Secondly, if you are using assembly programming, the stack usage will be under your direct control, and I wouldn't expect stack overflow to be a problem unless RAM resources are very tight.  When writing assembly code, it is more obvious how much stack is being used by each routine, certainly compared with C code.

One method of checking for stack usage is to use CW simulation mode.  Zero the stack RAM during initialisation, and then run the program.  During tests you can then stop operation, and examine for the lowest address with a non-zero value, in the stack area.  Then perhaps allow some additional room for any interrupts and sub-routines that may not have executed during simulation.

Regards,

Mac

[erokc]

Thanks Mac,

Sometimes the answer IS simple, why didn't I think of that.  I try solving problems the hard way sometimes.

I have considered coding in C but I don't know if I can trust the compiled code to do what I want.  I'm used to knowing exactly what instruction is fetched by the CPU and what to expect.  I'm afraid of the occasional bug that is impossible to find.  I will never forget my first program bug.  The difference in LDA #3 and LDA 3 took me two days to find.  I've never made that mistake since.

Now I can, with confidence, determine my stack space needs.

Thanks,  Dave