[参考译文] 66AK2G12：EtherCAT 固件更新

团队将收到通知。 他们将直接在此处发布反馈。

BR
Tsvetolin Shulev

Hiroyasu、

在通过 foo 进行"固件更新"期间、实际上是应用程序更新、PRU-ICSS 仍然正常工作。 只有在下载并重新加载应用程序后、PRU-ICSS 才会复位、并且其固件会更新并重新启动。 用户可以通过删除 PRU-ICSS 固件负载、将固件刷写到 SPI 闪存中、并使用定制 SBL 将固件加载到 PRU 存储器中、这与我们对 AMIC110无 DDR EtherCAT processors.wiki.ti.com/.../PRU_ICSS_EtherCAT 实施的操作类似

此致、
Garrett

您好、Garrett

感谢你的答复。

很抱歉、我迟到了。

因此、客户无需担心 K2G 固件更新。

但它们担心复位会导致通信中断

位于菊花链的背面。

因为他们的终端客户的系统可以运行24小时。

我们需要一种在不丢失通信的情况下重置和更新固件的机制。

实际上是否有复位其他功能(ARM 和 DSP 以及外设等)的机制

运行 PRU-ICSS (通信 EtherCAT 时)时进行固件更新？

请告诉我您的意见。

此致

高贵须

Hiroyasu、

客户可能能够开发一种机制来检查 PRU-ICSS 是否超出复位范围、然后不再更新固件。 但是、有一些问题：
INTC 映射。 不确定如果 ARM 处于复位状态并且从 PRU 侧触发 INTC 中断、会发生什么情况。
2.如果我们只是重置 ARM 内核、即重新启动堆栈、则不确定固件的运行方式。 更改栈的 PRU 的初始状态可能会产生一些意外结果。

此致、
Garrett

Garrett San、您好！

 

非常感谢您一如既往的大力支持。  抱歉、我的跳入/中断。  首先，我想确认 客户的要求是否与合理性不大。

您是否有任何客户信息想要像这位客户一样使用 PRU-ICSS/ARM？

换言之，与其他客户相比，客户在应用程序更新中对 foo 的要求“arm reset”、“EtherCAT communication do do do do do do do reset”是合理的要求。

 

1. 24小时工作系统(我认为是合理的)。

2.仅更新 ARM 内核(我认为是合理的)。

3.当高于#2时，EtherCAT 通信不会停止(我不确定此要求是否合理)。

我认为您的回答是合理的、但我的客户可能会觉得很麻烦。

此致、

高

Paula-San、
感谢您的支持。
发起此主题的 Hiroyasu-san 将很快关闭此主题。 因为我在这个线程中跳转、所以我无法关闭这个线程。
此致、
高