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

Posting a semaphore in a hardware interrupt causing interrupt time increase

Christopher Taylor
Intellectual 690 points


I have a hardware interrupt setup on PWM1 that is set at 20 KHz.  The ISR posts a semaphore every second time through.  A task is pending on this semaphore.  The task takes 23 us to execute.  When I check the timing of the ISR I see the first time through takes 2 us to execute.  The next time through takes 30 us.  The time from rising edge to rising edge is 50 us.  This is seen by setting an output high on entry to the ISR and setting it low on exit and vioewing on the scope.  It appears that one of two things is happening.  Either the command to post a semaphore takes 27 us or the act of posting the semaphore is causing the task to wake up and execute within the context of the hardware interrupt.  This is not what I expected.  I expected the hardware to post the semaphore within a us and then exit with the task waking up after the hardware intterupt finishes.   I am using the 28335 chip.  Any ideas?  Below is the ISR.

interrupt void MainISR(void)
{
LED_ON;
 // Verifying the ISR
 IsrTicker++;

 if (++fs_isrCounter >= 2)
 {
  fs_isrCounter = 0;
  SEM_post(&SEM_MCT);
 }

 // Enable more interrupts from this timer
 EPwm1Regs.ETCLR.bit.INT = 1;

LED_OFF;
 // Acknowledge interrupt to recieve more interrupts from PIE group 3
 PieCtrlRegs.PIEACK.all = PIEACK_GROUP3;
}

  • 0
    Intellectual 690 points

    I tried something that I consider unwise except for testing purposes.  I changed from using a semaphore to using a flag and having the task TSK_sleep(1) while the flag is false.  Under this test, the hardware interrupt became stable at 3 us execution time every time with a stable period of 50 us (20 KHz).  The task also showed a stable execution time of 21 us and period of 100 us (25 KHz).  This is what I had expected from the use if the semaphore.

  • 0 in reply to Christopher Taylor
    Intellectual 690 points

    Also, looking at the scope output, the ISR is very stable for a long period of time, running every 50 us as expected, and then there is a 870 us gap and then starts running normally again.  What could cause a PWM hardware interrupt to not fire for over 800 us?  There are no other hardware interrupts setup and even if there were there is no way that an ISR would take that long to execute.  This is very upsetting.  Any ideas?  This continues to occur but is spread out enough that I cannot measure the interval or determine if it is periodic.

  • 0 in reply to Christopher Taylor
    TI__Expert 3240 points

    Chris:

    Are you saying that the BIOS dispatcher is being used for a function declared with the "interrupt" keyword?  This will definitely cause problems such as the ones you reported.  You need to either 1) use the dispatcher with a non-interrupt-keyword function along with BIOS scheduling calls (such as SEM_post()), or 2) just "plug" your interrupt-keyword function in the vector table but the function can't make any BIOS scheduling calls. Let me know if this works. Thanks.

  • 0 in reply to dwane bell
    Intellectual 690 points

    There were 3 problems that have now been resolved:

     

    1.  The intterupt keyword was removed.  The code was ported from a non bios example and this was missed.

    2.  The ISR being assigned to the PIE Vect table in the chip initiailization was removed.

    3.  The code in the task using the semaphore was running at 20 KHz.  During this time it was setting the PWM trip zones to ensure that that PWMs were disabled.  This frequent setting of the trip seemed to interfere with the hardware interrupts being triggered by the PWM.  Eliminating this code appeared to make the interrupt execution regular.