RTOS/AM4377: Hardware interrupt lock in EtherCAT Slave

Part Number: AM4377

Tool/software: TI-RTOS

Hi,

There is an interrupt lock and unlock call in  "bsp_send_command_to_firmware"  function of tiescbsp.c  file. The Critical Section code under interrupt lock contains multiple function calls and also a do-while loop which in turn calls an other function to validate the while True/false condition, which could probably last more time. Please refer the code below:

void bsp_send_command_to_firmware(PRUICSS_Handle pruIcssHandle, Uint32 command, Uint16 param1, Uint16 param2)
{
    uint32_t evtoutNum = 0;
    volatile t_host_interface* pHost2PruIntfc = (volatile t_host_interface *)((((PRUICSS_HwAttrs *)(pruIcssHandle->hwAttrs))->baseAddr) + PRU_ICSS_DATARAM(0));
    {
#if defined(ENABLE_PDI_TASK) || defined(ENABLE_PDI_SWI)
        Semaphore_pend(semcmdlow_handle, BIOS_WAIT_FOREVER);

#else
        Hwi_disable();
#endif
        bsp_pruss_cmd_intfc_write_word(command, &pHost2PruIntfc->cmdlow);
        bsp_pruss_cmd_intfc_write_word(param1, &pHost2PruIntfc->param1low);
        bsp_pruss_cmd_intfc_write_word(param2, &pHost2PruIntfc->param2low);
#ifdef SUPPORT_CMDACK_POLL_MODE
        bsp_pruss_cmd_intfc_write_word(1, &pHost2PruIntfc->cmdlow_ack);
#endif
        PRUICSS_pruSendEvent(pruIcss1Handle, ARM_PRU_EVENT1);
        ASSERT_DMB();
        ASSERT_DSB();
        {
#ifdef SUPPORT_CMDACK_POLL_MODE
            volatile Uint16 ack;
            do {
                ack = bsp_pruss_cmd_intfc_read_word ( &pHost2PruIntfc->cmdlow_ack);
            } while (ack);
#else
            evtoutNum = HOST_CMD_LOW_ACK_EVENT - 20;
            PRUICSS_pruWaitEvent((PRUICSS_Handle)pruIcss1Handle, evtoutNum);
#endif
        }
        bsp_pruss_cmd_intfc_write_word(0xFF,    &pHost2PruIntfc->cmdlow);
#if defined(ENABLE_PDI_TASK) || defined(ENABLE_PDI_SWI)
        Semaphore_post(semcmdlow_handle);
#else
        Hwi_enable();
#endif
    }
}

1. Why is there a need for an Hardware lock in interrupt mode?

2. If needed, is it correct to have a big critical section of code within interrupt lock?

Due to the interrupt lock here, we are facing an issue of CPU being completely utilised by that function alone and the application task interrupts expected to receive is being lost. 

Expecting your reply earlier.

Thanks,

Sunil.