• 状态
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 690 视图
  • 用户 0 会员在此处
选项
选项
相关

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 事件请求寄存器锁存位问题

admin
Guru**** 2540720 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/596892/am335x-ethercat-al-event-request-register-latch-bit-issue

我正在使用 SYS/BIOS 工业 SDK v2.01.03.02在 ICEv2板上开发一个应用、该应用必须对路由到 latch0/1输入的某些信号的上升沿进行时间戳记。

该应用程序几乎可以完美运行、这意味着我能够正确获取时间戳、但在由于锁存而导致第一次 PDI 中断后 、寄存器0x220的位1永远不会复位。

因此、应用程序会被 PDI 中断悬空。

在伪代码中、这就是它所做的。

Beckhoff slavestack 已被修改、以向应用程序通知锁存事件：

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；

返回 ALSTATUSCODE_NOERROR；

｝

void APPL_Latch()
｛

uint8 latchreg = bsp_read_Byte (pruIcss1Handle、0x09AE)；

if (latchreg & 0x01)
｛
/*锁存0正边沿*/

bsp_get_latch0_POSetge_time (pruIcss1Handle、(uint32*)(&sSynchronizationFsm.latch0PositiveEdge)、(uint32*)(&sSynchronizationFsm.latch0PositiveEdge)+1)；

｝

if (latchreg & 0x0002)
｛
/*锁存0负边沿*/
bsp_get_latch0_negegedge_dime (pruIcss1Handle、(uint32*)(&sSynchronizationFsm.latch0NegativeEdge)、(uint32*)(&sSynchronizationFsm.latch0NegativeEdge)+1)；
｝

latchreg = bsp_read_Byte (pruIcss1Handle、0x09AF)；

if (latchreg & 0x01)

｛

/*闩锁1正边*/
bsp_get_latch1_POSetge_time (pruIcss1Handle、(uint32*)(&sSynchronizationFsm.latch1PositiveEdge)、(uint32*)(&sSynchronizationFsm.latch1PositiveEdge)+1)；
｝

if (latchreg & 0x02)
｛
/*闩锁2负边*/
bsp_get_latch1_negegedge_dime (pruIcss1Handle、(uint32*)(&sSynchronizationFsm.latch1NegativeEdge)、(uint32*)(&sSynchronizationFsm.latch1NegativeEdge)+1)；
｝

｝

我验证了在读取锁存时间戳寄存器后、锁存状态寄存器中的相应位被正确复位(0x9AE[1：0]= 0、0x9AF[1：0]= 0)、但 AL 事件寄存器的位1仍然被置位(0x220[1]=1)。

根据 Beckhoff ESC 文档、不应发生这种情况(请参见随附的图像)。

 


 

那么、我的问题是：我是否遗漏了什么？

我是否应该添加任何 ESC BSP API 调用来对其进行复位？

或者 PRU 固件中是否有需要修复的问题？

 

感谢你的帮助。

 

Paolo Mastrapasqua

  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    EtherCAT 专家已收到通知。 他们将在这里作出回应。
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    专家还没有消息？

    谢谢
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Paolo、

    我们检查了先前有关 Al Event Request 寄存器位的已知问题、找到了两条记录、但这些问题已经得到解决。 此外、我们还能够使用 AM335x 上的最新二进制文件通过 CTT 测试。 我们将查看最新应用中的特定 LATCH 位、以查看是否可以重现问题、并将尽快更新。

    此致、
    Garrett
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    好的、谢谢。

    我甚至尝试过以下操作：

    bsp_send_command_TO_firmware (pruIcss1Handle、CMD_DL_USER_CLEAR_AL_AL_AL_AL_AL_EVENT_LOW、~((UINT16) 0x0002)、0)；

    在读取锁存时间戳寄存器后、很遗憾没有成功。

     

    Paolo

  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我刚才做了一些测试、并验证了：

    1。

    我再也不会打电话了

    bsp_send_command_TO_firmware (pruIcss1Handle、CMD_DL_USER_CLEAR_AL_AL_AL_AL_EVENT_LOW、~((UINT16) 0x0002)、0)

    无论 锁存输入的状态如何、0x220[1]都不会被复位。

     

    2.

    如果我呼叫

    bsp_send_command_TO_firmware (pruIcss1Handle、CMD_DL_USER_CLEAR_AL_AL_AL_AL_EVENT_LOW、~((UINT16) 0x0002)、0)

    当 LATCH 输入为高电平时 、0x220[1] 不会复位。

     

    3.

    如果我呼叫

    bsp_send_command_TO_firmware (pruIcss1Handle、CMD_DL_USER_CLEAR_AL_AL_AL_AL_EVENT_LOW、~((UINT16) 0x0002)、0)

    当 LATCH 输入为低电平时 、0x220[1] 会复位。

    Paolo

     

     

     

  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    这种行为似乎是由于锁存输入的 PRU INTC 设置所致：

    #define PRU_ICSS1_INTC_INITDATA｛\
    ｛PD_WD_EXPI_EVENT、PDI_WD_EXPILOG_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 事件、PORT0_TX_UNF_EVENT、PORT0_TX_OVF 事件、MII_LINK0_EVENT、\
    PRU1_RX_ERR32_EVENT、PRU1_RX_OVF 事件、Port1_TX_UNF_EVENT、Port1_TX_OVF 事件、MII_Link1_EVENT、 ICSS1_PRUSS0_HOST_INTR5、0xFF｝、\
    ｛｛PD_WD_EXPIRY_EVENT、Channel1、SYS_EVT_POLICE_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PDI_WD_EXPILOCK_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛LATCH1_IN_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_PULSE｝、\
    ｛LATCH0_IN_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_PULSE｝、\
    ｛SYNC1_OUT_EVENT、CHANNEL4、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛SYNC0_OUT_EVENT、CHANNEL3、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛ARM_PRU_EVENT0、通道1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛ARM_PRU_EVENT1、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU_ARM_EVENT0、CHANNEL5、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU_ARM_EVENT2、CHANNEL6、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU0_RX_ERR32_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU0_RX_OVF 事件、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PORT0_TX_UNF_EVENT、Channel1、SYS_EVT_POLICE_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PORT0_TX_OVF 事件、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛MII_LINK0_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU1_RX_ERR32_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PRU1_RX_OVF 事件、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛PORT1_TX_UNF_EVENT、Channel1、SYS_EVT_POLICE_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛Port1_TX_OVF 事件、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛MII_Link1_EVENT、Channel1、SYS_EVT_POLARY_HIGH、SYS_EVT_TYPE_EDGE｝、\
    ｛ICSS1_PRUSS0_HOST_INTR5、CHANNEL2、SYS_EVT_POLARY_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)
    ｝

    它设置为极性高的电平、这似乎解释了我为什么在输入为高电平时继续接收中断。

    遗憾的是、将其设置为边缘(SYS_EVT_TYPE_EDGE)并不完全有用、因为只会通知上升沿或下降沿、但不会同时通知这两者。

    这可能是原因吗？

    是否有任何权变措施？

     

    Paolo

     

  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Paolo、

    我们正在尝试修复下一版本固件中的锁存事件位复位和 PDI 中断泛洪问题。 同时、如果您可以预测应用中的最大锁存脉冲宽度、 然后在此期间屏蔽 AL 事件请求锁存位、并通过计时器/超时机制重新启用、前提是连续锁存脉冲之间的持续时间已知大于重新启用屏蔽的开销。

    此致、
    Garrett