• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 464 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM2434: Inquire about issues related to the EtherCAT Firmware Update

Chen Zhen-Wei
Prodigy 55 points
Part Number: AM2434

Hi,

We are using PRU-ICSSG to implement EtherCAT communication, and we have some questions regarding firmware updates.

Referring to the ETG5003.2 Firmware Update manual, it mentions that ESC shall not be reset during the confirmation of the Boot State by the slave.

In our firmware update flow, the APP mode jumps to Boot Mode through a software warm reset method. We noticed that when using the software warm reset method, the PRU-ICSSG is also reset together. Therefore, ESC is reset before the slave confirms the Boot State, and this seems to violate the specifications of the ETG5003.2 Firmware Update manual.

So, my questions are:

1. Is there any other recommended method for our firmware update flow?

2. Is there a way to perform a software warm reset without resetting PRU-ICSSG to avoid ESC reset?

  • 0
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    1. Is there any other recommended method for our firmware update flow?

    Hi Chen you can check for the frmware update flow here: AM243x INDUSTRIAL COMMUNICATIONS SDK: EtherCAT SubDevice Setup with TwinCAT

  • 0 in reply to Nilabh Anand
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    2. Is there a way to perform a software warm reset without resetting PRU-ICSSG to avoid ESC reset?

    Could you please clarify following:

     the APP mode jumps to Boot Mode through a software warm reset method- Do you mean to say you are running some other application on the same r5f core as the EtherCAT Subdevice.

    AM243x INDUSTRIAL COMMUNICATIONS SDK: EtherCAT SubDevice FWHAL

    Below is the details on ESC design, and r5f is part of esc.

    Let me know if you need any other info from me.

  • 0 in reply to Nilabh Anand
    Prodigy 55 points

    Hi,
    Thanks for your reply.

    Nilabh Anand said:
    Do you mean to say you are running some other application on the same r5f core as the EtherCAT Subdevice.

    Yes.

    We have own bootloader. When we need to load another APP, we initiate the software warm reset for R5F to APP Mode transition to Boot Mode.

    The key point is that before the EtherCAT Subdevice enters the Boot State, there is the software warm reset to R5F, and the PRU-ICSSG is also reset together. This seems to violate the specifications of the ETG5003.2 Firmware Update manual.

    So, we would like to inquire if there is another method to resolve this issue.

    Nilabh Anand said:
    Below is the details on ESC design, and r5f is part of esc.

    According to our understanding, is PRU-ICSS the part int the diagram below?

    If so, is there a method to reload only R5F without the need to reload PRU-ICSSG?

  • 0 in reply to Chen Zhen-Wei
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    The key point is that before the EtherCAT Subdevice enters the Boot State, there is the software warm reset to R5F, and the PRU-ICSSG is also reset together. This seems to violate the specifications of the ETG5003.2 Firmware Update manual.

    Hi Chen,

    BOOT state is managed by the master and going to boot state does not require a warm reset. 

  • 0 in reply to Nilabh Anand
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    there is the software warm reset to R5F, and the PRU-ICSSG is also reset together.

    Whenever we have a warm reset we rest both PRU ICSS and R5F. But this does not violate the Firmware update manual as during FW update it states that ESC reset can happen and allowed in BOOT-INIT sequence.

  • 0 in reply to Nilabh Anand
    Prodigy 55 points

    Hi,

    Thanks for your reply.

    Let me clarify my question.

    1. In our firmware update process, When the master initiates the boot state, EtherCAT Subdevice first enters Boot mode through the software warm reset before entering the boot state. Due to the software warm reset, the PRU is also reset together. This switching process seems to violate the ETG5003.2. Therefore, we would like to inquire if there are any other suggestions for our firmware update process.

    2. I'd like to inquire about the typical firmware update process. When the master initiates the boot state, what is the update process for the slave?

    Best Regards

  • 0 in reply to Chen Zhen-Wei
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    . In our firmware update process, When the master initiates the boot state, EtherCAT Subdevice first enters Boot mode through the software warm reset before entering the boot state. 

    Please help me understand this: Is this firmware written by you, because in our implementation we do not have such requirement to reset the SubDevice when master initiates boot state?

  • 0 in reply to Chen Zhen-Wei
    TI__Mastermind 34537 points
    Chen Zhen-Wei said:
    2. I'd like to inquire about the typical firmware update process. When the master initiates the boot state, what is the update process for the slave?

    Please refer to this file to go through the update pocess: ind_comms_sdk\examples\industrial_comms\ethercat_slave_beckhoff_ssc_demo\tiesceoefoe.c

  • 0 in reply to Nilabh Anand
    TI__Mastermind 34537 points

    Hi Chen,

    Hope the issue is resolved. Please create a new thread if you have any questions.