• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 1540 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.

EtherCAT Application upgrade over FoE complying to SEMI TWG guidelines - AM335x Industrial SDK

Jonathan Marrs
Intellectual 555 points

Hello,

First of all, I would like to applaud TI for including support for EtherCAT online application upgrade over FoE since SDK 1.0.0.6. I think it adds a lot of value to the SDK, and is a very desirable feature for virtually all EtherCAT devices.

"Semiconductor Device Profile: Firmware Upgrade over EtherCAT v0.1.11" has not been published by the ETG yet, but TI has done a good job at implementing it anyway. There are some features mentioned in this document (even though it is still in draft form) that I think would greatly improve the sample implementation of firmware upgrade via FoE.

  • Firmware manifest: The firmware file shall include a header / identifier such that the slave can recognize the download with the expected signature so it can accept the firmware file (before erasing the current application). This enables the vendor to “certify” valid downloads.

  • The slave shall be able to recover from a failed download by having a permanent image that can restart a download (by FOE) if the firmware upgrade has failed.

  •  After a power supply failure during a firmware upgrade, firmware shall be upgradable by upgrade method defined herein.

 The document also describes using an md5 algorithm hash/checksum to verify file integrity. You can have two versions of the firmware (original version supplied by manufacturer and upgradable version) stored in two different areas of the flash chip. The manufacturer-supplied default firmware can be stored in a write-protected region of the flash chip. A bootloader can check the integrity of the updatable firmware (e.g., by computing the md5 hash/checksum and comparing it with the md5 checksum value stored in the file header). If the updatable firmware is valid, the bootloader loads that firmware. Otherwise, the updated firmware has been corrupted or is not there, and the manufacturer-supplied default firmware is loaded. This way another FoE firmware updated can be attempted, and the device will not become a paperweight if something goes wrong during the firmware update.

I think it would add a lot of vaule if TI fully implements "Semiconductor Device Profile: Firmware Upgrade over EtherCAT"  if/when it is published by the ETG.

It would probably also be beneficial to implement some features in "ETG.5003 Semiconductor Device Profile - ETG.5003.1 Common Device Profile (CDP)" even though it is still in draft form.

Regards

  • 0
    TI__Mastermind 47731 points

    Hi,

    Thank you for the positive feedback. Main intent behind supporting firmware upgrade was to demonstrate application upgrade and reload of the new application without resetting the AM335X and disrupting the EtherCAT communication. We felt that remaining functionality might vary depending on the customer use cases and an area which customers may add differentiation of their own.

    We will revisit this based on the overall feedback we receive on SDK and once specs get solidified.