• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 191 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.

AM2432: bsp_global_mutex_lock not working

sahar schwartz
Prodigy 140 points
Part Number: AM2432


Hi

We recently encountered some issues with our EtherCAT product. Upon realizing they might be caused by race conditions on certain variables, we tested whether interrupts are truly disabled in the critical sections protected by bsp_global_mutex_lock.

We protected a section in sync0task so that Ecatisr wouldn't be triggered, but found that it was not blocked.

image.png

After going through the code i found that the interrupt number is as follows:

image.png 

While inside bsp_global_mutex_lock, the interrupt numbers are missing the subtraction of 20:

image.png

when i substracted 20 from the interrupt number the interrupt indeed blocked.

Looking forward to your thoughts,

Sahar

 

  • 0
    TI__Genius 11165 points

    Hi Sahar,

    Thank you for pointing out this mismatch. This looks like a bug. I’ll review this and get back to you.

    Regards,
    Aaron

  • 0
    TI__Genius 11165 points

    Hi Sahar,

    I've created a high priority JIRA ticket to track the fix for the upcoming Industrial Communications SDK release. Substraction of Interrupt Number by 20 is mandatory for the mutex_lock and mutex_unlock APIs. Following is the implementation after the fix:

    void bsp_global_mutex_lock(void)
{
    //escGlobalIArg = GateAll_enter (escGlobalGateHandle);
    //Disable PDI and SYNC0 ISR at ARM INTC (rather than global IRQ disable)
    HwiP_disableInt(HOST_AL_EVENT + g_bsp_params.interrupt_offset - 20);
    HwiP_disableInt(HOST_SYNC0_EVENT + g_bsp_params.interrupt_offset - 20);
    HwiP_disableInt(HOST_SYNC1_EVENT + g_bsp_params.interrupt_offset - 20);
}

void bsp_global_mutex_unlock(void)
{
    //GateAll_leave (escGlobalGateHandle, escGlobalIArg);
    //Enable back PDI and SYNC0 ISR at ARM INTC
    HwiP_enableInt(HOST_AL_EVENT + g_bsp_params.interrupt_offset - 20);
    HwiP_enableInt(HOST_SYNC0_EVENT + g_bsp_params.interrupt_offset - 20);
    HwiP_enableInt(HOST_SYNC1_EVENT + g_bsp_params.interrupt_offset - 20);
}

    Just to understand the environment, which EtherCAT MainDevice are you using? 

    Regards,
    Aaron

  • 0
    Prodigy 140 points

    Hi Aaron

    Thanks for the quick response.

    If you are referring to the controller we use, then the issues appear when we use Omron NX701-1700.
    The reason we are seeing the issue with this specific controller is due to the fact it sends the PDI's very close to the Sync0 interrupt, which causes the PDI interrupt to sometimes arrive while Sync0task is executed.

    I actually had one more concern:

    The interrupts enable/disable requests are not nested from my understanding, which can create a case where one task disables the interrupts, and before it finishes the critical section, another task can be executed and enables the interrupts again.
    I implemented a wrapper to monitor the requests and not enable the interrupts until all the disable requests have a corresponding enable request. I would love to hear your thoughts about this. Do you think it is necessary?

    In addition, can we have an impact analysis for the fix?

    Thank you for your support,
    Sahar

  • 0 in reply to sahar schwartz
    TI__Genius 11165 points

    Hi Sahar,

    sahar schwartz said:
    I implemented a wrapper to monitor the requests and not enable the interrupts until all the disable requests have a corresponding enable request. I would love to hear your thoughts about this. Do you think it is necessary?

    Thank you for pointing out the concern. I will discuss this internally and get back to you.

    sahar schwartz said:
    In addition, can we have an impact analysis for the fix?

    We have run CTT and ESC Test Suites within the EtherCAT Conformance Test Tool to make sure the implementation is correct.

    Regards,
    Aaron