• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 167 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: PRU reset indication in Ethercat application

sahar schwartz
Prodigy 140 points
Part Number: AM2432


Tool/software:

Hi

We are experiencing an issue with one of our customers who complains about sudden node address change.

The issue only appears sometime after the system is properly configured and running and we see that register 0x0012 changes from the original node address to 0.

We want to make sure there wasn't an unwanted PRU reset. is there a way to check that? this scenario sounds possible?

We are using ICSSG0 to run out ECAT stack

Thank you,

Sahar Schwartz

  • 0
    TI__Genius 10795 points

    Hi Sahar,

    sahar schwartz said:
    We want to make sure there wasn't an unwanted PRU reset. is there a way to check that? this scenario sounds possible?
    • PRU Reset happening is very unlikely.
    • Make sure 0x0103.bit0 is set to activate 0x012:0x013.

    If non-FPxx packets are getting processed (WKC incremented) after 0x012 is changed, that means PRU is still running and processing the incoming packets. Additionally, could you share the wireshark logs for this scenario also is 0x010 Register getting over-written by 0? How frequent is this observed?

    Also you can refer to ICSSG_PRU_STATUS Register (address offset 0x30022004 and 0x30024004) for the Program Counter value and see if the PRU is still running:

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 140 points

    Hi Aaron.

    Thank you for the reply.

    Aaron Thomas said:
    Make sure 0x0103.bit0 is set to activate 0x012:0x013.

    I actually tried that. i wrote 1 to this bit before changing state to OP, and after the controller sets the node to OP, this bit is overwritten again to 0.

    I can try to set it to 1 while in OP. will it have the same impact?

    Aaron Thomas said:
    Additionally, could you share the wireshark logs for this scenario also is 0x010 Register getting over-written by 0? How frequent is this observed?

    This issue is not very frequent and hard to "catch". that is why we don't have the wireshark logs yet. we hope to find the reproduction steps for that issue and then we will be able to get them. 

    regarding 0x010 register- it is not showing 0 but it changes to some garbage value. register 0x012 on the other hand, sometimes shows 0 and sometimes shows garbage (different garbage then 0x010)

    could you please share a link to the document from which you took the status register description?

  • 0 in reply to sahar schwartz
    TI__Genius 10795 points

    Hi Sahar,

    sahar schwartz said:
    I can try to set it to 1 while in OP. will it have the same impact?
    • Yes this should be fine I believe.
    sahar schwartz said:
    This issue is not very frequent and hard to "catch". that is why we don't have the wireshark logs yet. we hope to find the reproduction steps for that issue and then we will be able to get them. 
    • I understand that the frequency of error is very low.
    • We will have to see who is over-writing these values, is it the EtherCAT MainDevice or the EtherCAT SubDevice stack or the EtherCAT SubDevice firmware.
      • EtherCAT MainDevice intervention can be ruled out if the wireshark logs are available.
      • EtherCAT SubDevice stack intervention can be checked by adding a Hardware Watchpoint at address 0x30090103 (assuming you are using ICSSG1 instance). You can add a watchpoint using the following steps:
        • Right click on the Breakpoints Window and choose Breakpoint -> Hardware Watchpoint.
        • In the Hardware Watchpoint Box, enter the address 0x30090103 in "Location field" and choose Write in the "Memory" field.
      • You can do this for all the address space that gets over-written to rule out stack intervention.
    • With the status of above checks, we can see if the firmware is interfering.

    Also, when you're able to reproduce the issue, please provide the complete memory dump of the ESC Register space. Additionally, which EtherCAT MainDevice are you using for your testing? Is it the same one mentioned in this thread ?

    Regards,
    Aaron