RTOS/TMS320C6678: How to extract info from task stack?

Chen,

Hi, what you are doing is pretty aggressive.  We do not explicitly support what you are doing, but I'm not saying it cannot be done.
Its not exactly clear to me what you are trying to accomplish but have you looked at used IPC instead of the approach you are taking?

I can tell you that the Task_SupportProxy_swap() for your device should be found in:

<SYSBIOS INSTALL>/packages//ti/sysbios/family/c62/TaskSupport_asm.s62

Judah

Hi,

Sorry for late feedback.

I have read TaskSupport_asm.s62 you figured out for me. And according to these info I have a simple test, but unfortunately it failed.

According to my understanding , the task stack is a block of memory and it grows to low address when new variables are allocated. And task->stack points to the lowest address. 

The comments in the source code points out that the top 32-bits of the stack are reclaimed by TaskSupport_getCheckValueAddr(), and later is :

* Task enter()
* Task glue()
* arg0
* arg1
* User's task func()
* Task_exit()

And there is 10 values represent A10-A15/B10-B13 stored between task_enter() and task_glue().

So it sums up to 8 + 6*4 + 10*4 = 72 B.

I copy the content of the stack the task used exclude the first 72B  and  rewrite it. But the result shows that it doesn't work: the task just run from start but not from the point when it was extracted.The local variables are also not coppied.

What confused me is as followed:

1. what does task->context means? Does it means the sp , that is , it points to the bottom of the stack which separate the stack to used and unused?But I have compared it with the pointer which returned by 

do {
} while(*sp++ == (Char)0xbe);

and the context pointer is lower than sp, and the result of context - sp is -4.

2. Does it matter if I don't copy the 10 values(A10-A15/B10-B13 ), I don't understand thier  functionality.

3. If i just rewitre the stack , will the local variables be rewritten? I didn't make it in my former try.

Thanks for your patient help.

Hi,

Thanks for your reply.

After quite a bunch of trial and error , I have succeeded in making a migrated task to run from where it stop. I find that there is a value stored in the stack that points to a specific location of the stack , which seems to be a start point of a serial of register. So I rewrite it in the new stack and make it point to the relative location. After that , the simple task works like I want.

And then I step forward to make my more complicated task to be migrated. However, I found my task is blocked when calling MessageQ_create().

Because messageQ is relative whit core, so before I switch my task which uses messageQ to another core , I need to free the old messageQ and create a new one. But my task is blocked then.

Do you know that what may cause task blocked when calling messageQ_create()?

Thanks for your help.

Judah,

Do you mean MessageQ.nameTableGate when you say MessageQ_module gate? I don't set anything when I call Message_create(Name, NULL).I have test for some time, but it was still blocked.

Can you tell me how can I pass the gate? 

Thanks for your help.

Where is the MessgeQ module coming from?  Is it from ti.sdo.ipc.MessageQ?

Yes, I'm using ti.sdo.ipc.MessageQ, and I'm also using transportqmss,

My config is as below:

var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');

var TransportQmss = xdc.useModule('ti.transport.ipc.c66.qmss.TransportQmss');

I have created a messageQ for other task when core start. And when I call MessageQ_create() (with another name) again, and it's blocked.

Thanks.

I find that it's system_printf() that cause messageq_create() blocked. If when I switch my task , the task is executing system_printf(). Then messageq_create() will be blocked.
Now it works fine. ^_^

Hi Chen,

Thanks for the update. I'm closing this one out since you are starting a new thread.

Todd