• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 493 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.

TMS320F28335: SYS/BIOS: Timer_Sleep() blocks after being called once

stevenh
Guru 20075 points

Other Parts Discussed in Thread: TMS320F28335, SYSBIOS

art Number: TMS320F28335

Hello,

I have two task that are using Timer_Sleep().  Both of them block indefinitely after being called once.  How can I determine what is causing Timer_Sleep() to block?

The application is using Timer0 (INT38) and Timer1 (INT13) for HWIs.  I had thought that the kernel is using TImer2 for the RTOS Timer Tick.  Is that correct?

The configuration for the two tasks are shown below (CAN_COM and RS232_COM). The clock configuration setting is also shown below.

I checked all timer registers and they are constantly running while Timer_Sleep() is blocking.

Stephen

  • 0
    TI__Guru 54615 points

    I assume you mean Task_sleep()? I'm not familiar with a Timer_sleep().

    Can you use ROV to investigate? Let the application run for a few seconds and then halt and open ROV. Look at the Clock module to confirm that the tick is incrementing as expected. Look at the Tasks to see what state they're in (blocked, ready, etc...). You can also look at BIOS->Scan for errors... to see if there are any other issues in the kernel that could be causing the problem.

    Whitney

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    Yes, I meant Timer_sleep().

    I did open the ROV and it shows the two tasks are blocked.  It also shows the timer has counted to a value lower than the Timer Period (i.e. Timer Period = 150000 and Count = 14 thousand something)  I think the counter counts down, so that is why it is less than the period value.

    I will try BIOS->scan for errors.

    The reason might be that I am using Timer 1 and Timer 0 for an HWI.  Could that be causing the issue?

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    Scan for Errors "no errors" (see below).  Also, The HWIs from ROV are shown below.  ti_sysbios_knl_Clock_doTick__I shows up at the top (intNum = 14).

    Timer from the ROV is also shown below.

    I didn't add intNum 14 HWI.  It was added automatically.  Is that causing the issue?

    HWI from ROV

    Timer from ROV:

    Bios scan for error.

  • 0 in reply to stevenh
    Guru 20075 points

    Here's a snapshot of the TImer in ROV showing the count.  Is there any other information you need?

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    I noticed ticks in the ROV Clock Module stays at 0.  I think that could the causing the issue.  What could keep it from ticking?  I can see Timer2 incrementing in the register window.

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    I forgot to mention that I am using SYS/BIOS version 6.46.6.00 and xdc tools 3.31.3.43.

    I do have another project where tasks are working.   That project contains more code.  I compared the two projects and I can't figure out why one is working and the other is not.  In the working project, tick is incrementing.  Also, that project uses SYS/BIOS 6.76.1.12 and xdc tools 3.60.2.34.  I tried to change the non-working project to 6.76.1.12, but I received some type of compiler error about Sys/Bios heap setting misconfiguration. 

  • 0 in reply to Whitney Dewey
    Guru 20075 points

    Hello Whitney,

    INT14 was jumping to the default empty body ISR. 

    I did the following to fix the issues:

    1. Excluded DSP2833x_PieVect.c from the build

    2. Put extern "C" around InitPieCtrl's function prototype

    3. Added the following to the end of InitPieCtrl() 

         PieCtrlRegs.PIEACK.all = 0xFFFF;  

         PieCtrlRegs.PIECTRL.bit.ENPIE = 1; // Enable the PIE

    It now works properly.

    Thanks,

    Stephen