• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 10774 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/TMS320C6748: Thread schedule in sys/bios

user4337327
Prodigy 160 points
Part Number: TMS320C6748

Tool/software: TI-RTOS

   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.

   

  • 0
    TI__Guru* 96960 points
    Just use two different semaphores. Here's the pseudo-code

    Hwi
    do work
    Semaphore_post(driverSem);


    Task1
    while (1) {
    Semaphore_pend(driverSem, BIOS_WAIT_FOREVER);
    do work
    Semaphore_post(fooSem);
    }

    Task1
    while (1) {
    Semaphore_pend(fooSem, BIOS_WAIT_FOREVER);
    do work
    }
  • 0 in reply to ToddMullanix
    Prodigy 160 points

     

       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.

     

     

  • 0 in reply to ToddMullanix
    Prodigy 160 points

    Hi, ToddMullanix

    I got the error moment this time, 

    It seems that BIOS Schduler is wrong.

    Appendix is the data exported from the Live Session.

    5861.aa.xlsx

  • 0 in reply to user4337327
    TI__Guru* 96960 points
    Look in ROV to see the callstack for task2. It's in ROV->Tasks->Callstack (or something close to that...I don't have access to CCS right now). What is it doing?
  • 0 in reply to ToddMullanix
    Prodigy 160 points

    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.2625.app.cfg

  • 0 in reply to user4337327
    TI__Guru* 96960 points
    It looks like Task2 is pending on a second semaphore or there is some corruption going on. Can you verify the stacks are not blown (ROV->Tasks->Detailed)? I'm basing this on seeing the following (thanks for the xls!!!).

    Normal flow (in time order)
    Idle
    Hwi (I'm assuming)
    Semaphore_post(0xc006f438) which makes Task1 ready
    Hwi ends
    Task1 runs
    ...
    Semaphore_post(0xc006f450) which makes Task2 ready
    ...
    Semaphore_pend(0xc006f438, BIOS_WAIT_FOREVER) which blocks

    Task2 runs
    ...
    Semaphore_pend(0xc006f450, BIOS_WAIT_FOREVER) which blocks

    But then I see this at line 1175 in the xls file.
    LM_pend: sem: 0xbe665947, count: 0, timeout: -1

    Looking above that I see that Task2 is the one using a Semaphore_Handle of 0xbe665947 instead of 0xc006f450. That's why the count is 1 on the semaphore (which Task1 did post). 0xbe665947 looks like a bogus address. So I'm thinking stack overflow or buffer over-write or something that corrupted the Semaphore_Handle being used in Task2.

    Todd
  • 0 in reply to ToddMullanix
    Prodigy 160 points

    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)?

  • 0 in reply to user4337327
    TI__Guru* 96960 points
    Regardinf buffer overflow, take this example of local variables

    char foo[10];
    Semaphore_Handle semHandle;

    If you do something like a memcpy to foo, but use 11 bytes, you are corrupting the semHandle. What is directly before the sem2 handle variable?

    I'm 99% sure that you are corrupting the Semaphore_Handle. I cannot remember if C67 supports HW Watchpoints in CCS. If it does, create a watchpoint on the sem2 handle after it is created. Then break if there is another write to that address. If corruption is occurring, you'll see where it is happening. If watchpoints are not supported, make a backup copy of the handle some where. Then before you use sem2, compare it to backup. It will proof that corruption is happening and get you closer.

    Todd
  • 0 in reply to ToddMullanix
    Prodigy 160 points

    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.

    Thanks again!

  • 0 in reply to ToddMullanix
    Prodigy 160 points
    Todd,
    This function caused the error: DSPF_sp_mat_mul.
    I use DSPF_sp_mat_mul to Multiply two real matrices, and A is 6*3, B is 3*20. The extra row and cow is loaded when use this function.