CN112199103B - 一种设备升级方法及终端设备 - Google Patents

Abstract

本申请适用于通信技术领域，提供了一种设备升级方法，包括：若接收到主站设备下发的升级指令，则控制所述从站设备启动自升级模式；在所述自升级模式下根据从站设备的文件接收状态接收升级文件，实现了设备的可靠升级，保证了设备升级的稳定性的同时还能提高升级效率。

Description

一种设备升级方法及终端设备

技术领域

本申请属于通信技术领域，尤其涉及一种设备升级方法及终端设备。

背景技术

以太网控制自动化技术(Ethernet Control Automation Technology，EtherCAT)是一种高性能、低成本、应用简易、拓扑灵活的工业以太网技术，EtherCAT系统是以工业以太网为基础的现场总线控制系统，其由主站设备和多个从站设备组成。目前市场上的EtherCAT从站设备大多采用EtherCAT专用芯片加一个微控制处理器实现。当设备应用软件设计存在缺陷时，就需要对微处理器的应用软件进行升级。而最常用的一种升级方式是使用JATG接口对处理器程序重新进行烧写，然而在升级过程中若发生断电或文件错误等问题时，就会出现文件写入错误而导致升级失败的情况。

综上可知，目前存在EtherCAT设备升级稳定性差的问题。

发明内容

本申请实施例提供了一种设备升级方法及终端设备，可以解决目前EtherCAT设备升级稳定性差的问题。

第一方面，本申请实施例提供了一种设备升级方法，包括：

若接收到主站设备下发的升级指令，则启动自升级模式；

在所述自升级模式下根据从站设备的文件接收状态接收升级文件，其中，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发。

上述从站设备的文件接收状态是指从站设备所处的各种文件接收状态，上述从站设备的文件接收状态可以包括读文件请求状态、写文件请求状态、写数据请求状态、数据接收响应状态、错误状态以及繁忙状态。根据从站设备的文件接收状态可以对主站设备11下发的升级文件进行接收可以避免升级文件的接收过程出现问题而导致升级失败，提高升级的可靠性。

在第一方面的一种可能的实现方式中，若接收到主站设备下发的升级指令，则启动自升级模式之后，还包括：

当检测到所述从站设备的微处理器软复位完成时，判断在预设时间间隔内是否有接收到升级数据帧，所述升级数据帧由所述主站设备下发；

若在预设时间间隔内接收到升级数据帧，则确认进入自升级模式。

在第一方面的一种可能的实现方式中，上述设备升级方法还包括：若检测到所述从站设备的微处理器未进行软复位或者在预设时间间隔内没有接收到升级数据帧，则跳转至应用软件。

在第一方面的一种可能的实现方式中，当所述从站设备的文件接收状态为写文件请求状态时，所述在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理，包括：

根据所述升级文件的文件信息确定升级文件的数据包总长度；

根据升级文件的数据包总长度对闪存中的应用软件存储区进行数据擦除。

在第一方面的一种可能的实现方式中，当所述从站设备的文件接收状态为写数据请求状态时，所述在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理，包括：

将接收到的数据写入到已擦除数据的应用软件存储区中；

将从站设备的文件接收状态从写数据请求状态转换为数据接收响应状态。

在第一方面的一种可能的实现方式中，所述将接收到的数据写入到已擦除数据的应用软件存储区中，包括：

按地址自增的方式将接收到的数据写入到已擦除数据的应用软件存储区中。

在第一方面的一种可能的实现方式中，上述设备升级方法还包括：判断升级文件是否传输完成。

第二方面，本申请实施例提供了一种终端设备，包括：

启动单元，用于若接收到主站设备下发的升级指令，则启动自升级模式；

接收单元，用于在所述自升级模式下根据从站设备的文件接收状态接收升级文件，其中，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发。

第三方面，本申请实施例提供了一种终端设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述的方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

本申请实施例与现有技术相比存在的有益效果是：通过在接收到主站设备的升级指令时启动自升级模式，并在自升级模式下，按照升级文件接收流程，根据从机设备的从站设备的文件接收状态对主站设备下发的升级文件进行接收，实现了设备的可靠升级，保证了设备升级的稳定性的同时还能提高升级效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的一种EtherCAT系统示意图；

图2是本申请一实施例提供的设备升级方法所适用于的终端设备的结构示意图；

图3是本申请一实施例提供的设备升级方法的流程示意图；

图4是本申请一实施例提供的自升级确认流程的流程示意图；

图5是本申请另一实施例提供的升级文件接收流程的流程示意图；

图6是本申请另一实施例提供的终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的设备升级方法主要应用于EtherCAT系统中主站设备对从站设备的升级，接下来以执行主体为EtherCAT系统的从站设备为例，对本申请实施例提供的升级方法进行说明。

请参阅图1，图1是本申请实施例提供的一种升级方法的应用场景示意图。如图1所示，EtherCAT系统包括主站设备11和至少一个从站设备12。主站设备可以采用嵌入式和PC机两种方式，需要配备标准以太网MAC控制器，从站设备通常具备有I/O端子、伺服设备、微处理器等。主站设备11与从站设备12之间的传输介质可使用100BASE-TX规范的5类非屏蔽双绞线(Unshielded Twisted Pair，UTP)。

当从站设备12的应用软件设计存在缺陷或者从站设备12需要升级其应用软件时，可以发送升级请求给到主站设备11，主站设备在接收到升级请求时就会对从站设备12的微处理器的应用软件进行升级，即主站设备11可以将用于升级应用软件的bin文件发送给从站设备12。

目前主站设备11将用于升级应用软件的bin文件发送给从站设备，通常是使用JATG接口对微处理器的应用软件重新进行烧写，或者通过COE(CANopen Over EtherCAT)来进行文件传输，然而在升级过程中若发生断电或文件错误等问题时，就会出现文件写入错误而导致升级失败的情况。而本申请实施例中，主站设备11采用EtherCAT文件传输方式(File Access over EtherCAT，FOE)将升级文件发送给从站设备12，在自升级模式下，按照本申请实施例提供的升级文件接收流程，根据从站设备12的文件接收状态对主站设备11下发的升级文件进行接收，可以实现设备的可靠升级，保证设备升级的稳定性。

主站设备11可以在接收到从站设备12的升级请求后，向从站设备12下发升级指令，从站设备12在接收到主站设备11下发的升级指令后，就会控制它的微处理器启动自升级模式，在进入了自升级模式后，就可以根据从站设备12的文件接收状态来接收升级文件，完成升级。

在本申请实施例中，上述升级指令可以是boot指令，从站设备12在接收到主站设备11下发的boot指令后，会控制其微处理器进行软复位。在微处理器软复位完成后，就会进入到boot程序以启动自升级模式。

在本申请实施例中，上述自升级模式是指按照本申请实施例提供的升级文件接收流程对主站设备11下发的升级文件进行接收的工作模式，具体的可以是根据从站设备12的文件接收状态对主站设备11下发的升级文件进行接收。需要说明的是，主站设备11向从站设备12发送升级文件是以数据帧的方式来发送的，即主站设备11会以升级数据帧(例如FOE数据帧)的形式将升级文件下发到从站设备12。

由于在接收到主站设备11下发的boot指令后，从站设备12会控制其微处理器进行软复位。因此，从站设备12需要先检测微处理器是否已进行了软复位，若检测到微处理器已进行了软复位，就会进一步检测在预设时间间隔内是否接收到主站设备11下发的升级数据帧。在预设时间间隔内接收到主站设备11下发的升级数据帧的情况下，就会启动自升级模式，按照本申请实施例提供的升级文件接收流程，根据从站设备12的文件接收状态对主站设备11下发的升级文件进行接收。这样可以实现设备的可靠升级，保证设备升级的稳定性。

需要说明的是，从站设备的文件接收状态是指从站设备所处的各种文件接收状态，上述从站设备的文件接收状态包括读文件请求状态、写文件请求状态、写数据请求状态、数据接收响应状态、错误状态以及繁忙状态。根据从站设备的文件接收状态可以对主站设备11下发的升级文件进行接收可以避免升级文件的接收过程出现问题而导致升级失败，提高升级的可靠性。

在本申请实施例中，若检测到微处理器未进行软复位，则跳转至应用软件。

在本申请实施例中，若在预设时间间隔内没有接收到主站设备11下发的升级数据帧，则跳转至应用软件。

需要说明的是，上述预设时间间隔可以根据实际需求进行设置，在本申请实施例中，可以将该预设时间间隔设置为5秒。

图2给出了一种终端设备20的示例，在本申请实施例中，上述终端设备可以是上述从站设备12，该终端设备20可以包括处理器、存储器、通信模块和电源管理模块等。

其中，处理器可以包括微处理器(Micro Control Unit，MCU)。具体的，上述微处理器可以是ESC(EtherCAT Slave Controller)从站控制芯片，目前市场上主要是LAN8595和ET1100。上述处理器可以是从站设备的神经中枢和指挥中心。处理器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。存储器可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器通过运行存储在存储器的指令，从而执行终端设备的各种功能应用以及数据处理。存储器可以包括存储程序区和存储数据区，比如存储应用软件的升级文件等。例如，该存储器可以是闪存Flash。闪存Flash可以被划分为存储bootloader代码的第一存储区和存储应用层代码的第二存储区。

通信模块可以提供应用在终端设备上的以太网控制自动化技术(EthernetControl Automation Technology，EtherCAT)通信的解决方案。通信模块可以是集成至少一个通信处理模块的一个或多个器件。该通信模块可以包括天线，该天线可以只有一个阵元，也可以是包括多个阵元的天线阵列。该通信模块可以通过天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器。通信模块还可以从处理器接收待发送的信号，对其进行调频、放大，经天线转为电磁波辐射出去。

电源管理模块可以接收电池和/或充电器的输入，为处理器、存储器和通信模块等供电。

需要说明的是，上述图2并不构成对终端设备20结构的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如终端设备20还可以显示屏、指示灯、马达、控件(例如按键)、陀螺仪传感器、加速度传感器等，在此不加以限制。

图3示出了本申请提供的一种设备升级方法的示意性流程图，作为示例而非限定，该方法可以应用于上述从站设备12中。

S101：若接收到主站设备下发的升级指令，则启动自升级模式。

在本申请实施例中，上述升级指令可以是主站设备根据在接收到从站设备上传的升级请求而下发的，该升级指令用于指示从站设备启动自升级模式。为了保障设备升级的可靠性，从站设备可以通过自升级确认流程来保证确保从站设备已进入自升级模式以保证升级过程的稳定性。

在本申请实施例中，若接收到主站设备下发的升级指令，则控制所述从站设备的微处理器进行软复位。

请参阅图4，图4示出了本申请实施例提供的自升级确认流程的流程示意图，如图4所示，上述自升级确认流程可以包括S41至S43，详述如下：

S41：检测从站设备的微处理器是否进行软复位，若检测到所述从站设备的微处理器软复位完成，则执行S42，否则跳转至应用软件。

在本申请实施例中，微处理器具有备用寄存器，该备用寄存器可以用来记录软复位状态，通过查找备用寄存器是否存在软复位状态就可以检测出从站设备的微处理器是否进行了软复位。即，若查找到的备用寄存器记录了软复位状态，则说明该微处理器已经进行了软复位；否则说明该微处理器未进行软复位。

在具体应用中，若检测到从站设备的微处理器未进行软复位，则说明此时不需要对应用软件进行升级，因此只需要跳转至应用软件，用户就能够通过该应用软件进行所需的操作。

S42：判断在预设时间间隔内是否接收到升级数据帧；若是，则执行S43，否则跳转至应用软件。

在本申请实施例中，通过检测预设时间间隔内是否有接收到主站设备的升级数据帧来确定数据传输是否已经完成，如果在预设时间间隔内没有接收数据帧，可以说明数据已经传输完成，此时，就无需进入自升级模式，只需要跳转到应用软件，用户就能够通过该应用软件进行所需的操作。

S43：确认已进入自升级模式。

在本申请实施例中，当检测到从站设备的微处理器软复位完成且在预设时间间隔内有接收到主站设备下发的升级数据帧，就可以说明此时已经进入了自升级模式。

需要说明的是，上述预设时间间隔可以根据实际需求进行设置，在本申请实施例中，可以将该预设时间间隔设置为5秒。

S102：在所述自升级模式下根据从站设备的文件接收状态接收升级文件，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发。

在本申请实施例中，在进入了自升级模式后，从站设备就可以根据从站设备的文件接收状态来接收升级文件，完成升级。在本申请实施例中需要用到的从站设备的文件接收状态包括但不限于写文件请求状态、写数据请求状态、数据接收响应状态。

在一种可能的实现方式中，从站设备可以根据如图5所示的升级文件接收流程来接收主站设备下发的升级文件。如图5所示，上述升级文件接收流程可以包括S51至S57，详述如下：

S51：从站设备的文件接收状态是否为写文件请求状态；若是，则执行S52；否则，执行S54。

S52：保存所述升级文件的文件信息，并根据所述升级文件的文件信息确定升级文件的数据包总长度。

在具体应用中，当从站设备的文件接收状态为写文件请求状态时，说明从站设备可以接收主站设备下发的升级文件，从站设备可以根据接收到的升级信息来确定升级文件的文件信息，然后根据升级文件的文件信息来确定升级文件的数据包总长度。

S53：根据升级文件的数据包总长度对闪存中的应用软件存储区进行数据擦除。

在具体应用中，从站设备的存储器可以被划分为存储bootloader代码的第一存储区和存储应用层代码的第二存储区。即第二存储区就是应用软件存储区。可以预先设定哪个地址段用来存储bootloader代码，哪个地址段用来存储应用层代码，这样就能够确定出闪存中的应用软件存储区的开始地址，然后基于升级文件的数据包总长度对该存储区进行数据擦除，以便于后续将接收到的升级数据存储到应用软件存储区中。

S54：从站设备的文件接收状态是否为写数据请求状态；若是，则执行S55；否则，执行S56。

S55：将接收到的数据写入到已擦除数据的应用软件存储区中，并将从站设备的文件接收状态从写数据请求状态转换为数据接收响应状态。

在本申请实施例中，当从站设备的文件接收状态为写数据请求状态，则说明此时从站设备已经可以开始写入升级数据，因此，可以将主站设备发送的升级数据写入到已擦除数据的应用软件存储区中，然后再将写数据请求状态转换为数据接收响应状态，以告知主站设备可以继续发送升级数据帧。

在本申请实施例中，可以按地址自增的方式将接收到的数据写入到已擦除数据的应用软件存储区中。需要说明的是，按地址自增的方式是指从站设备会从0地址开始写入升级文件，在0地址写完后再将数据写入到1地址，以此类推。

S56：判断升级文件是否传输完成；若是，则确定升级完成；否则，执行S51。

在实际应用中，主站设备在将所有升级数据帧发送给从站设备后，会发送升级文件传输完成的指令给到从站设备。若从站设备接收到该指令，则说明升级文件传输完成，否则，就需要继续确定是否需要接收升级文件，即重新执行S51。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

综上可知，本申请实施例提供的设备升级方法，通过在接收到主站设备的升级指令时启动自升级模式，并在自升级模式下，按照升级文件接收流程，根据从机设备的从站设备的文件接收状态对主站设备下发的升级文件进行接收，实现了设备的可靠升级，保证了设备升级的稳定性的同时还能提高升级效率。

对应于上文实施例所述的设备升级方法，图6示出了本申请实施例提供的终端设备的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图6，该终端设备60包括：启动单元61和接收单元62。

启动单元61用于若接收到主站设备下发的升级指令，则启动自升级模式；

接收单元62用于在所述自升级模式下根据从站设备的文件接收状态接收升级文件，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发。

在一种可能的实现方式中，上述终端设备60还可以包括判断单元，上述判断单元主要用于当检测到所述从站设备的微处理器软复位完成时，则判断在预设时间间隔内是否有接收到升级数据帧，所述升级数据帧由所述主站设备下发；若在预设时间间隔内接收到升级数据帧，则确认进入自升级模式。

在一种可能的实现方式中，当所述从站设备的文件接收状态为写文件请求状态时，上述接收单元62主要用于保存所述升级文件的文件信息；根据所述升级文件的文件信息确定升级文件的数据包总长度；根据升级文件的数据包总长度对闪存中的应用软件存储区进行数据擦除。

在一种可能的实现方式中，当所述从站设备的文件接收状态为写数据请求状态时，上述接收单元62主要用于将接收到的数据写入到已擦除数据的应用软件存储区中；将从站设备的文件接收状态从写数据请求状态转换为数据接收响应状态。

在一种可能的实现中，上述岸段单元还用于判断升级文件是否传输完成。

需要说明的是，上述单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种终端设备，该终端设备包括：至少一个处理器、存储器以及存储在所述存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的终端设备和方法，可以通过其它的方式实现。例如，以上所描述的终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种设备升级方法，其特征在于，应用于EtherCAT系统的从站设备，其特征在于，包括：

若接收到主站设备下发的升级指令，则启动自升级模式；其中，所述自升级模式为根据升级文件接收流程对主站设备下发的升级文件进行接收的工作模式，所述启动自升级模式包括控制微处理器进行软复位；

在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理，其中，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发；在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理包括根据从站设备的文件接收状态对主站设备下发的升级数据帧进行接收，所述从站设备的文件接收状态包括读文件请求状态、写文件请求状态、写数据请求状态、数据接收响应状态。

2.如权利要求1所述的设备升级方法，其特征在于，在若接收到主站设备下发的升级指令，则启动自升级模式之后，还包括：

当检测到所述从站设备的微处理器软复位完成时，判断在预设时间间隔内是否有接收到升级数据帧，所述升级数据帧由所述主站设备下发；

若在预设时间间隔内接收到升级数据帧，则确认进入自升级模式。

3.如权利要求2所述的设备升级方法，其特征在于，还包括：

若检测到所述从站设备的微处理器未进行软复位或者在预设时间间隔内没有接收到升级数据帧，则跳转至应用软件。

4.如权利要求1所述的设备升级方法，其特征在于，当所述从站设备的文件接收状态为写文件请求状态时，所述在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理，包括：

根据所述升级文件的文件信息确定升级文件的数据包总长度；

根据升级文件的数据包总长度对闪存中的应用软件存储区进行数据擦除。

5.如权利要求4所述的设备升级方法，其特征在于，当所述从站设备的文件接收状态为写数据请求状态时，所述在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理，包括：

将接收到的数据写入到已擦除数据的应用软件存储区中；

将从站设备的文件接收状态从写数据请求状态转换为数据接收响应状态。

6.如权利要求5所述的设备升级方法，其特征在于，所述将接收到的数据写入到已擦除数据的应用软件存储区中，包括：

按地址自增的方式将接收到的数据写入到已擦除数据的应用软件存储区中。

7.如权利要求4至6任意一项所述的设备升级方法，其特征在于，还包括：

判断升级文件是否传输完成。

8.一种终端设备，其特征在于，包括：

启动单元，用于若接收到主站设备下发的升级指令，则启动自升级模式，其中，所述自升级模式为根据升级文件接收流程对主站设备下发的升级文件进行接收的工作模式，所述启动自升级模式包括控制微处理器进行软复位；

接收单元，用于在所述自升级模式下根据从站设备的文件接收状态接收升级文件，其中，所述升级文件由所述主站设备采用EtherCAT文件传输方式进行下发；在所述自升级模式下根据从站设备的文件接收状态对升级文件进行处理包括根据从站设备的文件接收状态对主站设备下发的升级数据帧进行接收，所述从站设备的文件接收状态包括读文件请求状态、写文件请求状态、写数据请求状态、数据接收响应状态。

9.一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。