On 2011-06-01, at 8:27 AM, RussellMc wrote:

>> This time it is a difficult program to simulate because of the IO.  It w=
ould
>> be a lot of work to write the stimulation files and I'm not sure that is
>> even possible.
>=20
> Without digging into what stack access and manipulation is possible on
> that device:
>=20
> Is it not possible to prewrite the stack with known data and then
> examine it explicitly or implicitly after running the program or on
> diagnostic occasions during operation to see how close it has come to
> its bounds, or whether it has exceeded them.

On a couple of systems I have worked on, the diagnostic code did exactly th=
at.=20

Preset the stack memory with a known data pattern. As part of the timer tic=
k routine, the stack is looked at to check just for overflow - takes a coup=
le of reads to do. As part of low priority diagnostics task, the stack usag=
e is calculated - can be done with a successive approximation scheme to min=
imise the number of reads needed. This code would check all the task stacks=
..

However, the stack in the PIC16f886 is accessible neither is the stack poin=
ter and the stack wraps silently.=20

>From the data sheet, "The PC is PUSHed onto the stack when a CALL instruct=
ion is executed or an interrupt causes a branch. The stack is POPed in the =
event of a RETURN, RETLW or a RETFIE instruction execution." If you could i=
nstrument call, interrupt and return events to increment and decrement a co=
unter, you should be able to keep track of the stack.

Veronica


--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.