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.

SysBios Task Preemption Issue

Other Parts Discussed in Thread: SYSBIOS

The issue is that a lower priority task is not being preempted by a higher priority task even though the higher priority task is ready to run. The screenshot of my debug session illustrates this.

According to SysBios documentation "As a rule, no ready task has a priority level greater than that of the currently running task".

Here's the code for the tasks:

uint16_t processCounter = 0;

Void HighPriorityTask(UArg a0, UArg a1)
{
    while(1)
    {
        Semaphore_pend(process_sema, BIOS_WAIT_FOREVER);
        processCounter++;                                  //Code never hits this breakpoint
    }
}

Void LowPriorityTask(UArg a0, UArg a1)
{
    while(1);
}

 

What am I missing? 
 
 


  • What's the code that posts the semaphore?
  • Hi Richard,

    Have you verified that Semaphore_post has been called?

    Which board and version of TI-RTOS are you using? Do you have a small project you can share that exhibits this issue?

    Thanks,
    Vincent
  • This is code is triggered using the timer module

    Void Timer_1ms(void)
    {
    static int time_ms = 0;

    //Toggle the LED once per second
    if((++time_ms % 1000) == 0)
    GpioDataRegs.GPBTOGGLE.bit.GPIO32 = 1;

    //Signal the Process task
    Semaphore_post(process_sema);
    }
  • I am using SysBIOS (6.34.4.22), Xdc (3.24.5.48).

    Regarding the semaphore, please refer to the screenshot that I included with the post. It shows the high priority task in the 'ready' state. Based on the code that I included and the definition of the 'ready' state, the only way this can happen is if the semaphore_post occurred. Please refer to section 3.5.2 of the SysBios data sheet for more information (http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spruex3o).

    Send me an email and I will send you a simple project.

     

  • Forgot to mention, the board is an EzDsp 28335
  • Thanks. I have just sent you an email.
  • Hi Richard,

    Thanks for sending me your project. Unfortunately I don't have access to a eZDsp F28335 starter kit. I did however take your main.c and app.cfg file and replace the contents in the hello world example for the F28M35H52C1 control card (closest thing I could find) with your code and built it. There were a few small modifications I had to do to get it to build, namely removing your usage of GPIO and the ti.catalog.c2800.init.Boot module. After that I was able to successfully run the code and see processCounter increment when the semaphore is posted. So your BIOS configuration and the setup of your tasks, timer and semaphore seems to be correct.

    I have attached the modified helloworld.cfg  and main.c that I am running on my board. Maybe you can try to modify the Hello World example for your setup and see if it works? If it does, then you can maybe compare it with your failing scenario and isolate what is causing the issue.  See the attached screenshot that shows where you can find the Hello World example in the TI Resource Explorer.

    Also as a sanity check, make sure you verify that you do not have any stack overflows using the ROV tool in CCS. Here's a YouTube video that shows you how to launch it to inspect the stack peak usage under the Tasks Detailed Tab: https://www.youtube.com/watch?v=NV0gNNavmUw. Similarly, verify the system stack usage under the Hwi tab.

    Best regards,

    Vincent

    8877.main.c

    7026.helloWorld.cfg

  • Also want to add that I was using TI-RTOS tirtos_c2000_2_12_01_33, XDCTOOLS xdctools_3_31_01_33_core and SYSBIOS bios_6_41_04_54. You may want to see if upgrading makes a difference.

  • Regarding ROV, please refer to the screenshot in my original post. I was already using it.

    Does someone that you work with have access to 28335 EzDsp? If the code is correct, then it should work properly. As you have seen, the source code is rather trivial.

    So my preference would be to find the root cause rather than keep trying different version of the RTOS until I find the one that works. My guess is that there is a subtle project configuration error, coding error,  a misunderstanding of how this feature should work, or a bug in the RTOS.

    Nevertheless, I made all of the changes that you suggested except the change to a different RTOS because I need to keep SysBios for continuity with other projects. None of those changes fixed the problem.

  • Hi Richard,

    I am working to find a board. In the meantime, I just wanted to make sure none of what I suggested work, which means this is platform-specific.

    There have been quite a few changes between BIOS 6.34.4.22 and 6.41.04.54, so I wanted to verify if what you need is indeed among the fixes that were introduced. If the newer BIOS works for you, it would help narrow down on the actual fix you need.

    Best regards,
    Vincent
  • Hi Richard,

    I have located an ezDsp 28335 board and ran the 'ProjectCrash' project you sent. I can reproduce the issue using BIOS 6.34.4.22 with a new compiler (TI 15.9.0 STS) that I had in CCS 6.1.1. The issue arises due to the new compiler optimizing code in the Hwi dispatcher differently from older compilers, in particular the version referred to in the release notes for BIOS 6.34.04.22. I'd suggest you ensure you are using that particular version of the compiler (6.0.2), or at least stick to the 6.0.x stream, and see if the issue goes away.

    The Hwi dispatcher has been re-written since then, hence BIOS 6.41.4.54 does not have an issue with the new compilers.

    Best regards,
    Vincent
  • I installed compiler version 6.06 (couldn't find 6.02 ). It is working now as expected.
    But I am curious, optimization was turned off in my project, so why was optimization an issue?
  • Hi Richard,

    Good to hear it is working for you.

    Based on your example code, you have the following line in your .cfg file:

    BIOS.libType = BIOS.LibType_Custom;

    This tells the BIOS build system to rebuild the relevant BIOS source files for your system, and it does so with optimization turned on. If you had it set to debug/instrumented/non-instrumented mode instead, BIOS 6.34.4.22 would have used a pre-compiled library and you wouldn't have seen the issue.

    Best regards,
    Vincent