AM2434: Inquire about issues related to the EtherCAT Firmware Update

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

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?

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. 

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.

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

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?

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