Page 1 of 1

Function calls on the 17C756

PostPosted: Sat Nov 18, 2000 3:15 am
by brian
I am using the Hi-tech compiler with MPLAB to write an i2c send module for the PIC17C756. I am developing with an ICE I want to know if it is possible to call a function from another task? I have a task that calls a function every four seconds by using the OS_Delay context switch. After five calls to the function, the program hangs up within the source util.c. The strange behavior is the program stops running on the line ** in the included code below. Am I overloading the stack or not clearing some parameter?

*** snippet of code from util ***

void OSSaveRtnAddr( void (* task) (void) )

** OScTcbP->tP = task;


Re: Function calls on the 17C756

PostPosted: Sat Nov 18, 2000 4:14 am
by Pumpkin Incorporated
You can call any function, including a Salvo user service function, from a task (or elsewhere).

You cannot call a Salvo context switch (e.g. the user service OS_WaitSem()) from anywhere but inside a task.

So something like this is fine:

void MyTask (void)
for (;;)
OS_Delay(4_SECONDS, MyTasksLabel);

But something like this is not:

void MyOtherFn(void)
OS_Delay(4_SECONDS, MyOtherFnsLabel);

So I think you're doing all the Salvo stuff correctly.

The call tree of a function called from within a Salvo task can extend pretty deep. Since main() calls OSSched(), and then OSSched() dispatched your task, you're two call levels deep in your Salvo task, meaning that the call tree of your function can still be quite deep.

The place where you're ending up in the ICE is in the context-switching macro, which runs with interrupts enabled. So an interrupt may be occurring right after you enter OSSaveRtnAddr().

Since the PIC17C756 has a 16-deep call stack, and Salvo typically uses a maximum call stack depth of four, this sounds to me like perhaps you have unintentional nested interrupts. You can email or ftp me the code and I can take a look at it.

If all you're doing is pretty much sending
some I2C out every 4 seconds, I think it's interrupt-control related -- check your ISR.

The ICE Trace feature (with all of the code selected for tracing) is very powerful. Run the code, have it crash, and then work backwards through the Trace Results window to see what happened ...

[This message has been edited by aek (edited November 19, 2000).]