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.

AWR1642: What happen when calling the HwiP_disable

Part Number: AWR1642

Hello team,

Customer is asking, when calling the HwiP_disable function, did the comming interrupt will be save to a buffer, and the RTOS will response it after we enable the interrupt again? Or all the interrupt will be ignore after calling the HwiP_disable function?

Is the HwiP_disableInterrupt function same as the HwiP_disable function?

Thanks.

Regards,

Wesley

  • Hello team,

    Here's a additional question. If the coming interrupt will be pending at any buffer after the HwiP_disable is calling. How many interrupt event  will be pending at buffer?

    Thanks.

    Regards,

    Wesley

  • Hello Wesley,

    HwiP_disable function is used to go into critical section when no interrupt disturb the execution, e.g. no interrupt to CPU. Disable preemption.

    So if any interrupt occurs after this (and before HwiP_restore) that would be missed, as HwiP_disable disables all the interrupt temporarily.

    However, HwiP_disableInterrupt disable the interrupt to CPU for specific H/W peripheral.

     

    Regards,

    Jitendra

  • Hello Jitendra,

    I found this function description in SYS/BIOS document. It makes me confuse again, can you please calirify which one is correct? Thanks.

    file:///C:/ti/bios_6_73_01_01/docs/cdoc/ti/sysbios/hal/Hwi.html

    Hwi_disable()  // module-wide

    Globally disable interrupts

    C synopsis target-domain
    macro UInt Hwi_disable();
     
    RETURNS
    opaque key for use by Hwi_restore()
    DETAILS
    Hwi_disable globally disables hardware interrupts and returns an opaque key indicating whether interrupts were globally enabled or disabled on entry to Hwi_disable(). The actual value of the key is target/device specific and is meant to be passed to Hwi_restore().
    Call Hwi_disable before a portion of a function that needs to run without interruption. When critical processing is complete, call Hwi_restore or Hwi_enable to reenable hardware interrupts.
    Servicing of interrupts that occur while interrupts are disabled is postponed until interrupts are reenabled. However, if the same type of interrupt occurs several times while interrupts are disabled, the interrupt's function is executed only once when interrupts are reenabled.
    A context switch can occur when calling Hwi_enable or Hwi_restore if an enabled interrupt occurred while interrupts are disabled.
    Hwi_disable may be called from main(). However, since Hwi interrupts are already disabled in main(), such a call has no effect.
    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.
    Swis always run with interrupts enabled. See Swi_post() for a discussion Swis and interrupts.
    Regards,
    Wesley
  • Hello Wesley,

    MY statement in last reply was based on the test I did with mmw demo, where I pressed GPIO switch while app is interrupt disabled (Hwi_Disable).

    But as per Bios explanation, if interrupt occurs multiple times then it will be called after Hwo_restore/enable.

    I would request you to do the experiment at your end to confirm this behaviour.

     

    Regards,

    Jitendra

  • Thanks Jitendra,

    I had repeat this test in my side, and yes, after HWIP_DISABLE, multiple interrupt will be missing, then after HWIP_ENABLE, it will be call only one time.

    Regards,

    Wesley