This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TMS320C6748
CCS Version: 7.1.0.00016
sys/bios Version: bios_6_50_01_12
I have one Hwi and two tasks, task1 and task2.
The priority of task1 is higher than task2. now, I want to achieve the function as follows:
Run Task1 after Hwi, then run Task2 after Task1 finished, and then go to Idle loop and wait for Hwi again after task2 finished.
The time between two Hwi is 64ms, and task1 if about 35ms, and task2 is about 10ms.
What can I do to achieve the function?
I have tried to post an event in Hwi to run task1, and post a semaphore to run task2 at the end of task1. but it didn't worked as what I expected.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to ToddMullanix:
Thanks for your answer.
I use two different semaphores to do this, meantime, I use Execution Graph to have a monitor.
At the beginning, everything seemes to be ok,like this
The green thread is task1, blue thread is task2, and the red is idle.
However, about 30 minutes later, the Execution Graph become this:
It shows that there is only task1 and Idle thread. I feel strange so much and don't know where is the task2 thread.
I use two leds to show the run of task2 and Idle respectively, and led1 is Idle and led2 is task2, however, only led1 still running and led2 stoped.
I got the error moment this time,
It seems that BIOS Schduler is wrong.
Appendix is the data exported from the Live Session.
In reply to user4337327:
The ROV shows as follows when error comes:
However, the semaphore shows that the number of sem2 is 1. How could it be that task2 was blocked and sem2 is 1?
I'd like to attach my .cfg file since I really don't know how to solve the problem now.8585.app.cfg
Todd, thanks for your continued help.
Now, I think I understand why the task2 disappeared. It was pended by a wrong semaphore instead of sem2,
so it will be blocked forever by the wrong semaphore. Am I correct?
So, the question is what caused the wrong semaphore...
I don't think the reason is stack overflow, please look at this picture:
And what do you mean the buffer over-writer?
Also, I'm considering another way to solve the problem.
What if I use Semaphore_pend(sem,64) rather than Semaphore_pend(sem,BIOS_WAIT_FOREVER)?
This is a Screenshot from my map file:
I use watchpoint and HW breakpoint to monitor whether the value of sem2 was changed, but nothing happened when error comes, so I think HW Watchpoints is not supported in c6748.
I agree with your opinion that the sem2 was corrupted.
I will check my task2 more carefully next to see whether some array was used incorrected. I will give a feedback when I find the error.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.