• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 771 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.

Query on HWI_Disable

Justin Antony G
Intellectual 775 points


Hi,

Is there any change in HWI for DSP-BIOS 6.x?

I see some constraints listed under HWI_disable() for DSP-BIOS 6.x: 

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_21_01_16/exports/docs/docs/cdoc/ti/sysbios/hal/Hwi.html

 

"CONSTRAINTS
If a Task switching API such as Semaphore_pend(), Semaphore_post(), Task_sleep(), or Task_yield() is invoked which results in a context switch while interrupts are disabled, an embedded call to Hwi_enable occurs on the way to the new thread context which unconditionally re-enables interrupts. Interrupts will remain enabled until a subsequent Hwi_disable invocation.
"

Is the same applicable for DSP-BIOS 5.x as well? I did not find this in : spru403o.pdf (as part of DSP-BIOS 5.33.03 "BIOS.5.33\bios_5_33\packages\ti\bios\doc" )

Regards,

Justin

  • 0
    TI__Mastermind 18260 points

    Justin,

    The BIOS 5.x behavior in regards to HWI disabling across TSK switches is undefined, and different for different TI architecture families, and it can even vary within an architecture depending on how the TSK switch happend (synchronous vs. preempted).  The state of a CPU's "global interrupt enable" mode was never specified as part of a TSK context in BISO 5.

    For example, I believe that for C6x, the GIE bit in the CSR (which is the bit used in HWI_disable/enable) is not preserved across a TSK switch, so if HWIs were disabled when calling SEM_pend() and a TSK switch results, the next TSK will also have HWIs disabled.  However, I believe it is different for C5000 family chips, where the global interrupt state would get saved/restored during TSK switches.  Also, for the C6x, I believe that the GIE state handling is different for a TSK that gets preempted vs. a TSK that gives up the CPU (i.e., calls SEM_pend() and blocks) - if a TSK has HWIs enabled, then gets preempted by a different TSK that disables HWIs (and doesn't reenable them), then the original preempted TSK would have its state "restored" to enabled when it was returned to.

    BIOS 6 has taken the trouble to define this behavior, which is a good thing, but keep in mind that no interrupt handling model is going to satisfy everyone.  This area of specification is a difficult one.  If a TSK disables HWIs and then calls a scheduling API, what is expected?  Does that TSK expect that interrupts remain disabled throughout the execution of the next TSK (and possibly next, and so on ...), up to the point at which it is returned to and then reenables interrupts?  That scenario suffers from indeterminate interrupt disabling time.  So, if not that handling, would the TSK expect that they get (possibly) reenabled for the "next" TSK and then get disabled upon returning back to the original TSK that disabled interrupts?  Such handling doesn't sound very useful, seeing that the original TSK disabled them for a reason and probably didn't want interrupts to be reenabled until it did so.

    The BIOS 5.x "story" was that you had better design your system such that interrupts are always enabled when calling a BIOS scheduling API (or, as mentioned in the BIOS 6 constraint, a "Task switching API"), in which case the TSK scheduling handling of GIE (when interrupts are disabled) is not an issue.  I haven't mentioned the "preemption" handling very much since a TSK can't get preempted when global interrupts are disabled.

    I don't know if it's documented already, but I would place a constraint on all BIOS 5.x scheduling APIs that interrupts must be enabled when calling them, and if that constraint is always honored then it doesn't matter what BIOS does when the app calls a scheduling API with interrupts disabled (since that won't ever happen when following the constraint).  In fact, I would argue that the BIOS 6 constraint that you list above is not a constraint at all, just a "word of warning".  It probably should read something like "don't call any BIOS 6 Task switching API with global interrupts disabled, but if you do this is what will happen".  With the given behavior of BIOS 6, it would be very misleading to see a program do
        Hwi_disable();
        Semaphore_pend();
        Hwi_restore();
    since the reader of that code would expect no interrupts to occur between the disable/restore operation, yet they easily could.

    Regards,

    - Rob