• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 2418 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.

AM335X: EtherCAT AL Event Request register Latch bit issue

Paolo Mastrapasqua
Prodigy 160 points

I'm developing an application on an ICEv2 board using SYS/BIOS Industrial SDK v2.01.03.02 that has to timestamp rising an falling edges of some signals routed to latch0/1 inputs.

The application works almost perfectly, that meaning that I'm able to properly get the timestamps, but the after the first PDI interrupt due to a latch,  bit 1 of register 0x220 is never reset.

Because of that the application gets flodded by pdi interrupts.

In pseudo code this is what it does.

the Beckhoff slavestack has been modifed to notify the latch events to the application:

void PDI_Isr(void)

{

...

 UINT16  ALEvent = HW_GetALEventRegister_Isr();

...

if ( ALEvent & LATCH_EVENT ) /* LATCH_EVENT = 0x02*/
{

APPL_Latch();

}

...

}

 

Uint16 APPL_StartInputHandler(Uint16 *pIntMask)
{

bsp_write_word( pruIcss1Handle, 0x0303, 0x09A8 );

bsp_pdi_latch0_control(pruIcss1Handle, 0x03);

bsp_pdi_latch1_control(pruIcss1Handle, 0x03);

*pIntMask |= 0x0002 ;

return ALSTATUSCODE_NOERROR;

}

void APPL_Latch()
{

Uint8 latchreg = bsp_read_byte( pruIcss1Handle, 0x09AE);

if( latchreg & 0x01 )
{
/* Latch 0 positive edge */

bsp_get_latch0_posedge_time(pruIcss1Handle, (Uint32*)(&sSynchronisationFsm.latch0PositiveEdge), (Uint32*)(&sSynchronisationFsm.latch0PositiveEdge)+1);

}

if( latchreg & 0x0002 )
{
/* Latch 0 negative edge */
bsp_get_latch0_negedge_time(pruIcss1Handle, (Uint32*)(&sSynchronisationFsm.latch0NegativeEdge), (Uint32*)(&sSynchronisationFsm.latch0NegativeEdge)+1);
}

latchreg = bsp_read_byte( pruIcss1Handle, 0x09AF);

if( latchreg & 0x01 )

{

/* Latch 1 positive edge */
bsp_get_latch1_posedge_time(pruIcss1Handle, (Uint32*)(&sSynchronisationFsm.latch1PositiveEdge), (Uint32*)(&sSynchronisationFsm.latch1PositiveEdge)+1);
}

if( latchreg & 0x02 )
{
/* Latch 2 negative edge */
bsp_get_latch1_negedge_time(pruIcss1Handle, (Uint32*)(&sSynchronisationFsm.latch1NegativeEdge), (Uint32*)(&sSynchronisationFsm.latch1NegativeEdge)+1);
}

}

I verified that after having read the latch timestamp registers, the corresponding bits in latch status registers are correctly reset (0x9AE[1:0] = 0, 0x9AF[1:0] = 0), but the bit 1 of the AL Event register is still set (0x220[1]=1).

Based on Beckhoff ESC documentation this should not happen (see attached image).

 


 

So my question is: am I missing something?

Is there any esc bsp api call that I should add to reset it?

Or is there something to be fixed in the pru firmware?

 

Thanks for your help.

 

Paolo Mastrapasqua

  • 0
    TI__Guru**** 393215 points
    The EtherCAT experts have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 160 points
    Still no news from the experts?

    Thanks
  • 0 in reply to Paolo Mastrapasqua
    TI__Mastermind 43296 points
    Paolo,

    We checked previous known issues about AL Event Request register bits and did find two records, but those issues have been addressed. Also we are able to pass CTT test with the latest binary on AM335x. We are looking at the particular latch bit with latest application to see if the issue can be reproduced, will update you as soon as possible.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 160 points

    ok, thanks.

    I even tried this:

    bsp_send_command_to_firmware(pruIcss1Handle, CMD_DL_USER_CLEAR_AL_EVENT_LOW, ~((Uint16)0x0002), 0);

    after having read the latch timestamp registers, unfortunately without success.

     

    Paolo

  • 0 in reply to Paolo Mastrapasqua
    Prodigy 160 points

    I just did some more tests and verified that:

    1.

    if I never call

    bsp_send_command_to_firmware(pruIcss1Handle, CMD_DL_USER_CLEAR_AL_EVENT_LOW, ~((Uint16)0x0002), 0)

    0x220[1] never gets reset, no matter the state of the latch input.

     

    2.

    if I call

    bsp_send_command_to_firmware(pruIcss1Handle, CMD_DL_USER_CLEAR_AL_EVENT_LOW, ~((Uint16)0x0002), 0)

    when latch input is high, 0x220[1]  does not get reset.

     

    3.

    if I call

    bsp_send_command_to_firmware(pruIcss1Handle, CMD_DL_USER_CLEAR_AL_EVENT_LOW, ~((Uint16)0x0002), 0)

    when latch input is low, 0x220[1]  does get reset.

    Paolo

     

     

     

  • 0 in reply to Paolo Mastrapasqua
    Prodigy 160 points

    It looks like that this behaviour is due to the set up if the PRU INTC for latch inputs:

    #define PRU_ICSS1_INTC_INITDATA { \
    { PD_WD_EXPIRY_EVENT, PDI_WD_EXPIRY_EVENT, LATCH1_IN_EVENT, LATCH0_IN_EVENT,\
    SYNC1_OUT_EVENT, SYNC0_OUT_EVENT, ARM_PRU_EVENT0, ARM_PRU_EVENT1, PRU_ARM_EVENT0, /*PRU_ARM_EVENT1,*/ PRU_ARM_EVENT2,\
    PRU0_RX_ERR32_EVENT, PRU0_RX_OVF_EVENT, PORT0_TX_UNF_EVENT, PORT0_TX_OVF_EVENT, MII_LINK0_EVENT,\
    PRU1_RX_ERR32_EVENT, PRU1_RX_OVF_EVENT, PORT1_TX_UNF_EVENT, PORT1_TX_OVF_EVENT, MII_LINK1_EVENT, ICSS1_PRUSS0_HOST_INTR5, 0xFF },\
    { {PD_WD_EXPIRY_EVENT, CHANNEL1,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_EDGE },\
    {PDI_WD_EXPIRY_EVENT, CHANNEL1,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_EDGE}, \
    {LATCH1_IN_EVENT, CHANNEL1,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE },\
    {LATCH0_IN_EVENT, CHANNEL1,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_PULSE },\
    {SYNC1_OUT_EVENT,CHANNEL4, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {SYNC0_OUT_EVENT, CHANNEL3,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_EDGE },\
    {ARM_PRU_EVENT0, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE },\
    {ARM_PRU_EVENT1, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU_ARM_EVENT0, CHANNEL5, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU_ARM_EVENT2,CHANNEL6, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU0_RX_ERR32_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU0_RX_OVF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PORT0_TX_UNF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PORT0_TX_OVF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {MII_LINK0_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU1_RX_ERR32_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PRU1_RX_OVF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PORT1_TX_UNF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {PORT1_TX_OVF_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {MII_LINK1_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\
    {ICSS1_PRUSS0_HOST_INTR5, CHANNEL2,SYS_EVT_POLARITY_HIGH ,SYS_EVT_TYPE_EDGE }, \
    {0xFF,0xFF,0xFF,0xFF}},\
    { {CHANNEL0,PRU0}, {CHANNEL1, PRU1}, {CHANNEL2, PRU_EVTOUT0}, {CHANNEL3, PRU_EVTOUT1}, {CHANNEL4, PRU_EVTOUT2}, {CHANNEL5, PRU_EVTOUT3}, {CHANNEL6, PRU_EVTOUT4}, {0xFF,0xFF} },\
    (PRU0_HOSTEN_MASK | PRU1_HOSTEN_MASK | PRU_EVTOUT0_HOSTEN_MASK | PRU_EVTOUT1_HOSTEN_MASK | PRU_EVTOUT2_HOSTEN_MASK | PRU_EVTOUT3_HOSTEN_MASK | PRU_EVTOUT4_HOSTEN_MASK)\
    }

    It is set to level with polarity high, that seems to explain why I keep receiving the interrupt while the input is high.

    Unfortunately setting it to edge (SYS_EVT_TYPE_EDGE) does not completely help since only either the rising or the falling edge will be notified, but not both.

    Might be this the cause?

    Are there any workaround?

     

    Paolo

     

  • 0 in reply to Paolo Mastrapasqua
    TI__Mastermind 43296 points
    Hi Paolo,

    We are trying to fix the latch event bit reset and PDI interrupt flooding issue in firmware of next release. Meanwhile, you might be able to workaround the problem if you can predict max latch pulse width in your application, then mask AL event request Latch bit for this duration and re-enable via timer/timeout mechanism provided duration between consecutive latch pulses is known to be larger than overhead to re-enable mask.

    Regards,
    Garrett