• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 786 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.

DSP BIOS execution time of SWI_Post function

Lars Djernis
Prodigy 130 points

DSP-BIOS issue on TMS320F2808PZS customer board:

While analysing a problem of excess CPU Load on some of our h/w boards, they came across a peculiar observation:

The execution time of SWI_post function of the DSP-BIOS is high on some boards. The readings were thus:

Board A: 1.04 uSec

Board B: 2.38 uSec

The measurements were taken by driving a GPIO pin HIGH and then LOW across the SWI_post function call. Same software was downloaded on both the boards, meaning that clock configuration remains the same.

Patches of logic which do not involve calls to the DSP-BIOS functions take the same time for execution on different boards. It is only when we make call to the SWI_post function that we observe that CPU load increases on Board B. We could pin point it down to the observation that SWI_post takes more time to execute on Board B.

Can you kindly let us know what are the parameters that impact the execution time of SWI_post function?

Also, let us know if you can explain the reason for different behavior on two different boards.

Thanks.

  • 0
    TI__Mastermind 26780 points

    From what context is SWI_post() called?  Is it possible that the SWI runs immediately when posted in certain cases, so the execution time can be different?

    Or, is the behavior completely consistent, meaning all posts on Board A are always faster than all posts on Board B?

    Are Board A and Board B two instances of the same board design?  Or are there different components that might lead to some different timings?

    Thanks,
    Scott

  • 0 in reply to ScottG
    TI__Prodigy 130 points

    Q: From what context is SWI_post() called?  Is it possible that the SWI runs immediately when posted in certain cases, so the execution time can be different?

    A: The SWI_post is called from a HWI (timer interrupt) to make sure that the context does not switch to the SWI as soon as it is posted. The timer HWI uses HWI_enter and HWI_exit calls.

    Q: Or, is the behavior completely consistent, meaning all posts on Board A are always faster than all posts on Board B?

    A: Yes, this behaviour is completely consistent. All posts on Board A are faster than those on board B.

    Q: Are Board A and Board B two instances of the same board design?  Or are there different components that might lead to some different timings?

    A: Yes, board A ad B are two instances of the same board design; this has been confirmed from the h/w team.

    Additionally, I tried using the SWI_or function and the observation is same: takes more time to execute on one board.

    For your reference, the test code looks like what follows:

    /* Set pin */

    GpioDataRegs.GPADAT.bit.GPIO29 = 1u;

    SWI_post (g_SchedObjSWIHandle);

    /* Reset pin */

    GpioDataRegs.GPADAT.bit.GPIO29 = 0u;

     And the HWI interrupt functions is called thus:

    _cpu_timer0_isr:

    HWI_enter C28_AR_CALLER_MASK, C28_AC_CALLER_MASK, C28_MISC_CALLER_MASK, 0

    lcr _hal_timer_CPUTimer0ISR

    HWI_exit C28_AR_CALLER_MASK, C28_AC_CALLER_MASK, C28_MISC_CALLER_MASK, 0

    '_cpu_timer0_isr' is registered in tcf.

     

    Thanks

    Lars

  • 0 in reply to Lars Djernis
    TI__Mastermind 26780 points

    Lars,

    OK, thanks.

    I will have to ask around for other ideas.  The same software on exactly the same hardware should obviously give the same results.  I wonder if you’ve tried a third board?  Maybe the timing on A or B is malfunctioning in some odd way?

    Also, I wonder if you’ve tried setting IERDISABLE mask in the HWI_enter/HWI_exit calls to mask off all other interrupts?  I’m wondering if somehow there is a preemption of the ISR on board B that is making it look like SWI_post() is taking longer there?  Just a guess, but it might be worth a try…

    Scott