• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1229 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/TM4C129DNCPDT: TI-RTOS with Compiler Optimizations

Thomas Jacobson
Intellectual 310 points
Part Number: TM4C129DNCPDT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello!

I'm working on a TM4C129 with TI-RTOS. Our project involves communications, which are currently running slowly due to the amount of processing going on. I'd like to use the optimizations to speed things up, but the optimizations are causing a Semaphore_pend call to hang, even though the related Semaphore_post call is being made.

Under our project's properties, under Build->ARM Compiler->Optimization, I've set --opt_for_speed=5, and that hasn't had any trouble at all. When I set --Ooff, everything runs fine, but the communications are slow. When I set --opt_level=1, everything does run faster, but eventually the Semaphore_pend call never returns, despite the Semaphore_post call being made for the same semaphore.

I've set all of our semaphores, events, and mailboxes as volatile, although they're statically set up using the app.cfg file (so I'm calling extern volatile...) Are there any other tricks I need to do for the optimizations to run properly? I'm currently using CCS 7.4.0.00015 with compiler TI v16.9.7.LTS.

Thanks for your help!

- Tom

  • 0
    TI__Guru* 96960 points
    Hi Thomas,

    Can you look at Tools->RTOS Object View (name might vary depending on which version of CCS you have). Open up the Semaphore view to see the status of the semaphore. You might want to do a quick checks of stack usage also (e.g. Tasks->Detailed and Hwi->Module).

    Is the system still running otherwise?

    I expect the different compiler optimization settings are exposing a race condition in your code.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 310 points
    Hi Todd,

    Thanks for responding. The task that the semaphore is inside of has a pretty high priority. Interestingly, it doesn't say its blocked on a semaphore. It's listed as 'Ready,' and isn't blocked on anything. Its call stack looks like this:
    0 ti_sysbios_knl_Task_schedule__I() at Task.c:75
    1 ti_sysbios_knl_Task_restore__E(unsigned int) at Task.c:323
    2 ti_sysbios_knl_Semaphore_pend__E(struct ti_sysbios_knl_Semaphore_Object *, unsigned int) at Semaphore.c:191
    3 taskFxnTest(unsigned int, unsigned int) at Test.c:216 ***[That's my code!]
    4 ti_sysbios_knl_Task_exit__E() at Task.c:414,PC = 0x000268F0 FP = 0x2001A0B0

    Despite this, when I set a breakpoint right after the Semaphore_pend call in my code, it never gets there. What's also interesting is that lower-priority tasks are running, even though the task in question is still listed as 'Ready,' and nothing blocking it.

    The system does continue to run. There's at least one other semaphore that is posted and pended that still seems to run properly. This is the only location where the semaphore in question is pended, so I don't think there's a race condition occurring, at least not for the semaphore.

    - Tom
  • 0 in reply to Thomas Jacobson
    TI__Guru* 96960 points
    Do you ever disable tasking (e.g. Task_disable)? Can you attach a screen shot of Task->Detailed?
  • 0 in reply to ToddMullanix
    Intellectual 310 points

    Hi Todd,

    Here's the detailed task list. The task in question is taskSample (second from the top). You'll notice that there is a lower-priority task running, even though taskSample is ready to run. I don't call Task_disable anywhere. 

    - Tom

  • 0 in reply to Thomas Jacobson
    TI__Guru* 96960 points
    Hi Thomas,

    Thanks...strange.... Can you confirm the scheduler is not locked? In Task->Module, schedulerState should be unlocked (ditto for Swi). Can you also confirm the currentThreadType is task in ROV->BIOS->Module? Does ROV->BIOS->Scan for errors give any errors or warnings?

    Are you using an Event in taskFxnSample or just a semaphore?

    What version of TI-RTOS (or more specifically SYS/BIOS) are you using?

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 310 points

    Hi Todd,

    Sorry for dropping off the radar for a few days. The schedulerState is listed as unlocked when I force the program to stop in my code. The currentThreadType is set to task, and the 'Scan for errors' tab did not report any errors.

    I have been switching back and forth between using an event and a semaphore. Originally, when I posted, I was using a semaphore. I then tried an event, and things worked for a while. However, I discovered (unrelated to this problem) that I had made one of my task's stacks too small, and increased its size. Upon doing that, the event started producing the same problem as the semaphore, getting stuck in the same place. All of my stacks are 1024-byte aligned, and are a multiple of 1024 as well.

    In my project's properties, SYS/BIOS is version 6.50.1.12. TI-RTOS for TivaC is version 2.16.0.08.

    - Tom

  • 0 in reply to Thomas Jacobson
    TI__Guru* 96960 points
    No problem. I've handed this off to a co-worker and he'll follow-up.
  • 0 in reply to Thomas Jacobson
    TI__Expert 4440 points

    Hi Tom,

    Are you using any of TI's drivers in the taskComm1 (such as UART, I2C, SPI...etc)?

    Could you provide a vague description of what this task does?

    This is abnormal behavior and I wish to help you resolve this.

    Thanks,
    Derrick

  • 0 in reply to Derrick Williams
    Intellectual 310 points
    Hi Derrick,

    Yes, the taskComm1 task uses one of the UART channels. The task checks for incoming bytes in a buffer (bytes are placed there by an interrupt for the corresponding UART). If any bytes are present, it begins building a packet that is then analyzed to read a command coming from our backend software.

    The firmware doesn't actually use the RTOS implementation of the UART. I don't know if that's a problem or not relating to the optimizations. It's worked so far using only the peripheral driver library.

    Thanks for your help, Derrick. And thank you, Todd, for assisting me this far.

    - Tom
  • 0 in reply to Thomas Jacobson
    TI__Expert 4440 points

    Thomas,

    Could you describe your UART interrupt implementation?

    When using interrupts with an RTOS, the RTOS needs to be "aware" of the interrupts.

    To remedy this, you will need to use the Hwi module to implement your UART interrupt.

    Derrick

  • 0 in reply to Derrick Williams
    Intellectual 310 points
    Hi Derrick,

    I will implement this and get back to you. Do you think that by not integrating the RTOS with these interrupts, that this is causing the semaphores to hang?

    - Tom
  • 0 in reply to Thomas Jacobson
    TI__Guru* 96960 points
    HI Tom,

    There's a discussion on interrupt handling in TI-RTOS here: processors.wiki.ti.com/.../BIOS_for_Stellaris_Devices

    You can have interrupts that are not managed by the kernel (we call them zero-latency, since the RTOS does not add latency). Note: in an unmanaged (zero-latency) interrupt, you cannot make any calls that might impact the scheduler (e.g. Semaphore_post).

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 310 points
    Hi Todd,

    I managed to find a temporary workaround by moving some of the code into a separate project, optimizing that, then compiling it into a static library. Then I link that library back into the original project. The part of the code I want to optimize has been optimized, and the firmware is running at the speed I'd like it to.

    However, I still want to pursue this. I've been busy with other projects, and with a solution in hand, I may not get a chance to implement these changes to see if that corrects the behavior I was experiencing before. Thank you very much for the support you've offered thus far.

    - Tom