• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 806 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Task is Blocked - Will Not Unblock

Rick Faszold
Expert 1090 points
Other Parts Discussed in Thread: CODECOMPOSER

Hi TI:

This may be a combination of a SYS/BIOS and a TI-RTOS question.  I have Tiva Launchpad, CodeComposer 5.5, SYS/BIOS 6.35, TI-RTOS 1.10.

My program seems to have an issue with going into BLOCKED_MODE and staying there for the two Tasks that I have running. 

Task #1 - Runs I2C communications with a couple of chips that interface to a number of sensors.  The code "appears" to run just fine.  I am using the TI-RTOS I2C drivers for this.

Task #2 - This is basically a serial processor.  The only command that I am using for this is UART_Read() and I am waiting for a NEWLINE before returning from the call.  I am using the TI-RTOS drivers for this.

When the Board first starts, Task #1 starts running and all is well.  Task #2 hits the UART_Read() and immediately goes into BLOCKED_MODE.  This seems to be expected since Task #2 is waiting for a NEWLINE.  Task #1 continues to run.

The problem occurs when Task #2 receives an <ENTER> triggering the UART_Read().   The UART_Read() processes as expected.  It executes a command, the goes right back into the UART_Read() command and into Blocked Mode.

Unfortunately, Task #1 essentially shuts down and stays that way.  According to the ROV, Task #1 goes into Blocked Mode based on a Semaphore.  When I look at the Semaphore, the status for Task #1 is pendState: Waiting Forever.  (Sounds like a long time.) 

I can't figure out how to nudge Task #1 to continue processing.  When Task #1 is running with a full code set (a few thousand lines of code), I can get Task #1 to go into Blocked Mode with one hit of <ENTER> in Task #2.  If I remove sections of code from Task #1, it takes a few more <ENTER>'s in Task #2 to make Task #1 go into Blocked Mode. 

Your thoughts would be greatly appreciated. 

Thanks

Rick

  • 0
    TI__Genius 10260 points

    Hi Rick,

    Sorry for the delayed response.  

    Sounds like a lot is happening in Task1 ("... a few thousand lines of code..."); are you using semaphores to block Task 1 within this code?  Can you post the instrumented I2C driver logs?  These might help determine what is going on with communication.  Additionally, what are the priorities for Task 1 and Task 2?

    Thanks,

    Emmanuel 

  • 0 in reply to Emmanuel Trinidad - Alicea
    Expert 1090 points

    Hi Emmanuel:

    I've thought a lot about this issue since I posted it.  Thank you for your reply. 

    As you note, Task1 is overloaded and as I looked at everything that was going on, I decided to go ahead and start offloading I/O onto a different subsystem.  I am going to redesign this.

    Let's go ahead and close this out.

    Thank you.

    Rick