Firmware upgrade method, device and medium for dual-chip RFID system supporting IO-link protocol

Abstract

The application relates to the technical field of industrial automation, in particular to a dual-chip RFID system firmware upgrading method supporting an IO-Link protocol, equipment and a medium, the method comprising the following steps: acquiring an upgrading instruction issued by an upper computer through an IO-Link interface and determining a target upgrading object; when the target upgrading object is a second control chip, maintaining an IO-Link communication connection by a first control chip, transmitting firmware data to the second control chip through an internal communication channel and acquiring an internal state signal; converting the internal state signal into IO-Link protocol response information according to a protocol mapping rule and feeding back to the upper computer; performing version consistency checking after the second control chip is restarted, and determining an upgrading state and a control communication state according to a checking result. The application has the effects of improving controllability and operation stability of dual-chip system firmware upgrading.

Description

Technical Field

[0001] This application relates to the field of industrial automation technology, and in particular to a firmware upgrade method, device and medium for a dual-chip RFID system supporting the IO-Link protocol. Background Technology

[0002] Currently, in industrial automation control scenarios, RFID systems are often used for material tracking and information identification. The IO-Link protocol, as a point-to-point serial communication protocol, is widely used to connect sensors and actuators. RFID readers that support this protocol typically adopt a dual-chip architecture where the first control chip is responsible for the communication protocol stack and the second control chip is responsible for radio frequency signal processing.

[0003] Existing dual-chip RFID systems typically employ a data pass-through mode during firmware upgrades. This involves the host computer forwarding firmware data packets from the first control chip to the second control chip for programming. In this mode, the first control chip merely acts as a physical transmission channel and cannot analyze underlying hardware execution anomalies during the programming process of the second control chip in real time. Furthermore, there is a lack of automatic verification of version consistency between the two chips after the upgrade. If the second control chip upgrade fails and service is resumed directly, the dual-chip RFID system may perform RFID tag reading and writing operations under inconsistent version conditions, leading to abnormal business data processing or communication status. Therefore, there is room for improvement. Summary of the Invention

[0004] To improve the controllability and operational stability of firmware upgrades for dual-chip systems, this application provides a firmware upgrade method, device, and medium for dual-chip RFID systems that support the IO-Link protocol.

[0005] The above-mentioned objective of this application is achieved through the following technical solution:

[0006] A firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol, applied to a dual-chip RFID system including a first control chip and a second control chip, the firmware upgrade method for the dual-chip RFID system includes:

[0007] Obtain the upgrade command issued by the host computer through the IO-Link interface, and determine the target upgrade object based on the upgrade command;

[0008] If the target upgrade object is the second control chip, then the first control chip takes over the IO-Link communication link to maintain the IO-Link communication connection state, and an internal communication channel is built between the first control chip and the second control chip;

[0009] Based on the internal communication channel, the internal status signal of the second control chip during the firmware update process is obtained;

[0010] According to the preset protocol mapping rules, IO-Link protocol standard response information is constructed based on the internal status signals, and the IO-Link protocol standard response information is fed back to the host computer;

[0011] In response to the signal that the second control chip has completed the firmware update and restarted, the first control chip is used to perform a version consistency check on the second control chip to determine the version matching result.

[0012] Based on the version matching result, the upgrade status of the dual-chip RFID system is determined, and the communication status of the IO-Link communication link is controlled based on the upgrade status result.

[0013] By adopting the above technical solutions, and by obtaining upgrade instructions and determining the target upgrade object, it is possible to distinguish between the self-upgrade process of the first control chip and the proxy upgrade process of the second control chip, thereby providing a basis for subsequent upgrade path selection. By having the first control chip take over the IO-Link communication link and build an internal communication channel during the upgrade of the second control chip, it is possible to maintain the communication response on the host computer side during the suspension of business processing by the second control chip, thereby reducing the probability of the device being mistakenly judged as offline during the upgrade process. By obtaining the internal status signal of the second control chip and building IO-Link protocol standard response information, it is possible to convert the burning status of the second control chip into diagnostic information that can be recognized by the host computer, thereby reducing the probability of the status being imperceptible in the transparent upgrade mode. By performing version consistency verification and controlling the communication status of the IO-Link communication link after the second control chip restarts, it is possible to restore business after version matching and restrict business recovery when the version is abnormal, thereby improving the status feedback capability and business recovery controllability during the firmware upgrade process of the dual-chip RFID system, and thus improving the controllability and operational stability of the dual-chip system firmware upgrade.

[0014] In a preferred embodiment, this application can be further configured such that: determining the target upgrade object according to the upgrade instruction specifically includes:

[0015] Based on the upgrade instruction, the target device identifier, target version number, and firmware data package are obtained;

[0016] The target upgrade object is determined based on the target device identifier;

[0017] If the target device identifier matches the preset identifier of the first control chip, then the target upgrade object is determined to be the first control chip;

[0018] If the target device identifier matches the preset identifier of the second control chip, then the target upgrade object is determined to be the second control chip.

[0019] By adopting the above technical solution, the target device identifier, target version number, and firmware data packet can be obtained from the upgrade command, and the target upgrade object can be determined based on the target device identifier. This can clearly identify the chip object and target version corresponding to this upgrade, thereby avoiding the firmware data packet being sent to the wrong chip and providing a comparison basis for subsequent version consistency verification.

[0020] In a preferred embodiment, this application can be further configured such that: the step of taking over the IO-Link communication link through the first control chip to maintain the IO-Link communication connection state specifically includes:

[0021] By controlling the first control chip to stop the transmission of radio frequency tag read / write service data between it and the second control chip;

[0022] The first control chip receives periodic process data requests from the host computer, generates corresponding response messages based on the periodic process data requests, and feeds back the response messages to the host computer. The response messages are configured with status parameters indicating the maintenance status so that the host computer maintains the communication connection with the dual-chip RFID system.

[0023] By adopting the above technical solution, by stopping the transmission of radio frequency tag read / write service data between the first control chip and the second control chip, the conflict between service data and upgrade data on the internal communication channel can be reduced; by having the first control chip respond to periodic process data requests and feed back maintenance status parameters, the host computer can identify that the device is in maintenance status during the upgrade, thereby reducing the probability that the device is judged as having a communication interruption.

[0024] In a preferred embodiment, this application can be further configured such that: obtaining the internal status signal of the second control chip during the firmware update process based on the internal communication channel specifically includes:

[0025] The first control chip sends an upgrade trigger command to the second control chip via the internal communication channel, so that the second control chip enters the boot loading mode.

[0026] If a ready signal is detected from the second control chip, the first control chip sends the received firmware data packet to the second control chip through the internal communication channel.

[0027] Monitor the internal status signals transmitted back by the second control chip.

[0028] By adopting the above technical solution, by sending an upgrade trigger command to the second control chip and putting it into boot loading mode, the second control chip can be switched to a state that can receive firmware data; by sending firmware data packets after detecting a ready signal, the probability of data loss caused by unready transmission can be reduced; by monitoring the internal status signals returned by the second control chip, the execution status during firmware reception, verification, and writing can be obtained, thereby providing a basis for subsequent status mapping.

[0029] In a preferred embodiment, this application can be further configured as follows: the step of constructing IO-Link protocol standard response information based on the internal state signals according to preset protocol mapping rules specifically includes:

[0030] Identify the hardware execution state corresponding to the internal status signal to determine the current update state of the second control chip. The hardware execution state includes at least write timeout, verification error, or write protection exception.

[0031] Based on the hardware execution state, retrieve the corresponding IO-Link event code from the protocol mapping rules;

[0032] The IO-Link event code is written into a preset protocol stack diagnostic buffer within the first control chip to generate the IO-Link protocol standard response information.

[0033] By adopting the above technical solution, the abnormality type of the second control chip during the firmware update process can be determined by identifying the hardware execution state corresponding to the internal state signal; by retrieving the corresponding IO-Link event code in the protocol mapping rules, the private hardware state of the second control chip can be converted into IO-Link event information; by writing to the protocol stack diagnostic buffer, standard IO-Link protocol response information that can be recognized by the host computer can be generated, thereby realizing standardized feedback of upgrade abnormal states.

[0034] In a preferred embodiment, this application can be further configured such that: the version consistency verification of the second control chip using the first control chip to determine the version matching result specifically includes:

[0035] The first control chip initiates a version query request to the restarted second control chip to obtain the current running firmware version number fed back by the second control chip;

[0036] Compare the current firmware version number with the target version number;

[0037] If the current running firmware version number is consistent with the target version number, then the version matching result is determined to be a successful verification.

[0038] If the current firmware version number is inconsistent with the target version number, then the version matching result is determined to be a verification error.

[0039] By adopting the above technical solution, the actual firmware version of the second control chip can be obtained by sending a version query request to the restarted second control chip. By comparing the current firmware version number with the target version number, it can be determined whether the firmware update has actually taken effect, thereby providing a basis for subsequently restoring RFID tag reading and writing services or continuing to restrict service request forwarding.

[0040] In a preferred embodiment, this application can be further configured as follows: determining the upgrade status result of the dual-chip RFID system based on the version matching result, and controlling the communication status of the IO-Link communication link based on the upgrade status result, specifically includes:

[0041] If the version matching result is verified, the upgrade status result is determined to be successful. The first control chip is controlled to resume the RFID tag read / write service data transmission with the second control chip, and the target version number is written into the IO-Link device parameter storage area stored in the first control chip.

[0042] If the version matching result is an error, the upgrade status result is determined to be an upgrade failure. The first control chip is then controlled to continue to stop forwarding RFID tag read / write service requests to the second control chip. At the same time, a version conflict error event is reported to the host computer through the IO-Link interface.

[0043] By adopting the above technical solution, and by resuming the RFID tag read / write service data transmission between the first and second control chips when the verification passes, the second control chip can participate in RFID service processing only after version matching, thereby reducing the probability of anomalies caused by resuming services in an unconfirmed version state. By writing the target version number into the IO-Link device parameter storage area, the host computer can easily read the updated version information. By continuing to stop forwarding RFID tag read / write service requests and reporting version conflict anomalies when the verification fails, the second control chip with a mismatched version can be restricted from participating in service operation, thereby reducing the probability of abnormal versions affecting RFID read / write services.

[0044] In a preferred embodiment, this application can be further configured such that the dual-chip RFID system firmware upgrade method also includes:

[0045] If the target upgrade object is the first control chip, then control the first control chip to enter the firmware self-upgrade state;

[0046] In the firmware self-upgrade state, the first control chip maintains the IO-Link communication state with the host computer based on the preset maintenance response rules, and receives the firmware data packet sent by the host computer;

[0047] The firmware self-update operation of the first control chip is performed based on the firmware data package;

[0048] After the firmware self-update operation is completed, the first control chip is switched to the application running state.

[0049] By adopting the above technical solution, when the target upgrade object is the first control chip, it is controlled to enter the firmware self-upgrade state, which can distinguish and process the self-upgrade process of the first control chip from the proxy upgrade process of the second control chip; by maintaining the IO-Link communication state based on the preset maintenance response rules and receiving firmware data packets, the host computer can identify that the first control chip is in the maintenance process, thereby reducing the probability of being mistakenly judged as offline during the self-upgrade; by executing the firmware self-update operation and switching to the application running state, the first control chip can resume normal business processing after completing its own upgrade.

[0050] The above-mentioned objective 2 of this application is achieved through the following technical solution:

[0051] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol.

[0052] The above-mentioned objective three of this application is achieved through the following technical solution:

[0053] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol.

[0054] In summary, this application includes at least one of the following beneficial technical effects:

[0055] 1. By acquiring upgrade instructions and identifying the target upgrade object, the system can distinguish between the self-upgrade process of the first control chip and the proxy upgrade process of the second control chip, thus providing a basis for subsequent upgrade path selection. 2. By having the first control chip take over the IO-Link communication link and build an internal communication channel during the second control chip's upgrade, the system can maintain communication response on the host computer side during the second control chip's business processing suspension, thereby reducing the probability of the device being mistakenly judged as offline during the upgrade process. 3. By acquiring the internal status signals of the second control chip and building IO-Link protocol standard response information, the system can convert the second control chip's programming status into diagnostic information recognizable by the host computer, thereby reducing the probability of imperceptible status during transparent upgrade mode. 4. By performing version consistency verification and controlling the communication status of the IO-Link communication link after the second control chip restarts, the system can restore business after version matching and restrict business recovery when the version is abnormal, thereby improving the status feedback capability and business recovery controllability during the firmware upgrade process of the dual-chip RFID system, and ultimately improving the controllability and operational stability of the dual-chip system firmware upgrade.

[0056] 2. By controlling the first control chip to enter the firmware self-upgrade state when the target upgrade object is the first control chip, the self-upgrade process of the first control chip and the proxy upgrade process of the second control chip can be distinguished and processed; by maintaining the IO-Link communication state based on the preset maintenance response rules and receiving firmware data packets, the host computer can identify that the first control chip is in the maintenance process, thereby reducing the probability of being mistakenly judged as offline during the self-upgrade; by executing the firmware self-update operation and switching to the application running state, the first control chip can resume normal business processing after completing its own upgrade. Attached Figure Description

[0057] Figure 1 This is a flowchart illustrating the implementation of a firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol in one embodiment of this application.

[0058] Figure 2 This is another implementation flowchart of a firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol in one embodiment of this application. Detailed Implementation

[0059] The following embodiments will help those skilled in the art to further understand the function of this application, but do not limit this application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application. These all fall within the protection scope of this application.

[0060] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0061] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0062] The present application will be further described in detail below with reference to the accompanying drawings.

[0063] In one embodiment, the dual-chip RFID system includes an IO-Link interface, a first control chip, a second control chip, and an RF front-end module. The first control chip is connected to the IO-Link interface and is used to process the IO-Link communication protocol stack and to communicate with a host computer for process data, parameter data, and diagnostic events. The second control chip is connected to the RF front-end module and is used to perform RFID tag identification, tag data reading, and tag data writing. The first and second control chips are connected via an internal communication interface, which can be a UART interface, SPI interface, I2C interface, or other inter-chip communication interface. Under normal operating conditions, the internal communication interface is used to transmit RFID tag read / write service data; under firmware upgrade conditions, it is used to transmit upgrade trigger commands, firmware data packets, internal status signals, and version query information.

[0064] In one embodiment, such as Figure 1 As shown, this application discloses a firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol, which specifically includes the following steps:

[0065] S10. Obtain the upgrade command issued by the host computer through the IO-Link interface, and determine the target upgrade object according to the upgrade command.

[0066] In this embodiment, the upgrade command is a firmware update request message initiated by the host computer to the device through the IO-Link interface or IO-Link communication link. This message contains the target information of this upgrade operation, which is used to inform the device which control chip needs to be updated. For example, in the RFID reader on the automobile production line, the host computer needs to specify whether to upgrade the first control chip responsible for IO-Link communication or the second control chip responsible for radio frequency processing, so as to ensure the targeting and accuracy of the upgrade operation.

[0067] Specifically, the first control chip, as the device-side communication processing end of the IO-Link protocol, continuously listens to the communication messages on the IO-Link bus. When the host computer initiates an upgrade request, the first control chip receives the upgrade instruction through the IO-Link interface and parses it to extract information used to identify the upgrade target, so as to determine whether the target of this upgrade operation is the first control chip itself or the second control chip.

[0068] S20. If the target upgrade object is the second control chip, the first control chip takes over the IO-Link communication link to maintain the IO-Link communication connection state and builds an internal communication channel between the first control chip and the second control chip.

[0069] In this embodiment, taking over the IO-Link communication link refers to the first control chip responding to periodic queries from the host computer instead of the dual-chip system during the upgrade of the second control chip. For example, in an industrial automation production line, the IO-Link master station periodically exchanges process data with the equipment. If the equipment does not respond for a long time, the master station will determine that the equipment is offline and trigger an alarm. Therefore, the first control chip needs to maintain normal communication with the master station during the upgrade to reduce the probability of abnormal production line stoppages caused by equipment offline alarms. The internal communication channel refers to a dedicated data transmission path built between the first and second control chips through a hardware interface. It is connected point-to-point through a UART serial port or SPI interface and is used to transmit upgrade commands, firmware data packets, and status feedback information. For example, when the second control chip restarts and enters the boot loading mode, the first control chip acts as a proxy to maintain the handshake with the master station, which helps the upgrade data to be forwarded to the second control chip.

[0070] Specifically, when the target for upgrade is determined to be the second control chip, the first control chip switches to upgrade agent mode, actively takes over the communication response processing of the IO-Link communication link, suspends normal RFID tag read / write service interaction, and establishes a point-to-point internal communication channel with the second control chip through the internal serial peripheral interface or universal asynchronous transceiver. This channel is used to transmit upgrade trigger commands, firmware data packets and status feedback information, thereby enabling upgrade data interaction between the first control chip and the second control chip.

[0071] S30. Based on the internal communication channel, obtain the internal status signal of the second control chip during the firmware update process.

[0072] In this embodiment, the internal status signal refers to the hardware execution status information fed back to the first control chip through the internal communication interface during the process of receiving and burning firmware data by the second control chip. For example, when the second control chip writes to the Flash memory, it may generate status signals such as write timeout, verification error or write protection abnormality. These signals can reflect the real progress and abnormal situation of the firmware update of the second control chip, which helps the first control chip to perceive the execution status of the underlying hardware in a timely manner.

[0073] Specifically, the first control chip forwards firmware data packets to the second control chip through an internal communication channel and simultaneously listens to the internal status signals returned by the second control chip. These internal status signals include, but are not limited to, hardware execution status information such as burning progress confirmation, data verification results, and write timeout alarms, thereby enabling real-time perception of the firmware update progress and abnormal situations of the second control chip.

[0074] S40. Based on the preset protocol mapping rules, construct the IO-Link protocol standard response information based on the internal status signals, and feed the IO-Link protocol standard response information back to the host computer.

[0075] In this embodiment, the protocol mapping rule refers to a predefined correspondence table between internal status signals and IO-Link standard protocol responses. For example, the internal error code returned by the second control chip is mapped to the event code under the IO-Link diagnostic mechanism. Through this mapping rule, the host computer does not need to understand the internal communication protocol of the second control chip, but can obtain the real status of the underlying hardware through the standard IO-Link protocol interface, thereby realizing a cross-chip status feedback closed loop.

[0076] Specifically, after acquiring the internal status signal, the first control chip queries the locally stored mapping rule table, which records the correspondence between the internal status signal and the IO-Link event code. When the first control chip acquires the internal status signal returned by the second control chip, it converts the internal status signal into standard response information conforming to the IO-Link protocol specification according to the mapping rule table, writes the standard response information into the diagnostic buffer of the IO-Link protocol stack in the first control chip, and sends the standard response information to the host computer through the IO-Link interface, thereby enabling the host computer to identify the actual hardware execution status of the second control chip.

[0077] S50, in response to the signal that the second control chip has completed the firmware update and restarted, uses the first control chip to perform version consistency verification on the second control chip to determine the version matching result.

[0078] In this embodiment, version consistency verification refers to the process whereby the first control chip actively queries the current firmware version number of the second control chip after the second control chip completes firmware burning and restarts, and compares it with the target version number preset in the upgrade command by the host computer to verify whether the firmware update has truly taken effect. For example, in practical applications, if the second control chip encounters a sudden power outage during the burning process, it may result in incomplete firmware writing but still be able to start the old version program. At this time, version consistency verification can identify this abnormal situation and prevent the system from resuming business operation under the condition of version mismatch.

[0079] Specifically, after the second control chip completes firmware burning and performs a reboot, when the first control chip detects the hardware reset completion signal or communication ready signal sent by the second control chip, it determines that the second control chip has completed firmware update and reboot. At this time, the first control chip sends a version query request to the second control chip through the internal communication channel, receives the current running firmware version number returned by the second control chip, and compares the version number with the target version number specified in the upgrade instruction. Based on the comparison result, it generates a version matching result that passes or fails verification, thereby verifying whether the firmware update of the second control chip has truly taken effect.

[0080] S60. Based on the version matching result, determine the upgrade status result of the dual-chip RFID system, and control the communication status of the IO-Link communication link based on the upgrade status result.

[0081] In this embodiment, the upgrade status result refers to the result information generated by the dual-chip RFID system for this firmware upgrade process. For example, when the version matching result is "verification passed," it means that the current firmware version number of the second control chip is consistent with the target version number, and the first control chip can resume the RFID tag read / write service data transmission with the second control chip. When the version matching result is "verification failed," it means that the current firmware version number of the second control chip is inconsistent with the target version number, the first control chip continues to stop forwarding RFID tag read / write service requests to the second control chip, and feeds back the abnormal information to the host computer through the IO-Link interface. The communication status of the IO-Link communication link refers to the communication status presented by the dual-chip RFID system to the host computer through the IO-Link interface, including normal operation status, maintenance status, or abnormal event reporting status.

[0082] Specifically, the first control chip generates an upgrade status result based on the version matching result, and adjusts the forwarding strategy of RFID tag read / write service requests and the status feedback content of the IO-Link interface according to the upgrade status result; if the version matching result is a successful verification, the forwarding of RFID tag read / write service requests is resumed, and the normal operation status is reported to the host computer; if the version matching result is an abnormal verification, the forwarding of RFID tag read / write service requests is stopped, and a version conflict abnormal event is reported to the host computer through the IO-Link interface.

[0083] In one embodiment, step S10, namely determining the target upgrade object according to the upgrade instruction, specifically includes:

[0084] S11. Based on the upgrade command, obtain the target device identifier, target version number, and firmware data package.

[0085] In this embodiment, the target device identifier is a unique number or address information used in the upgrade command to distinguish different control chips. For example, in a dual-chip RFID system, the preset identifier of the first control chip can be defined as 0x01, and the preset identifier of the second control chip can be defined as 0x02. By carrying the corresponding device identifier in the upgrade command, the host computer can accurately specify the target chip for this upgrade. The target version number is the firmware version that the host computer expects the target chip to reach after the upgrade, such as v2.0.1. This version number will be used as a comparison benchmark in the subsequent version consistency verification. The firmware data package is a binary file containing the complete program code of the target chip, which is sent by the host computer in frames through the IO-Link interface.

[0086] Specifically, after receiving the upgrade instruction message sent by the host computer, the first control chip unpacks the message according to the predetermined protocol frame format, extracts the target device identifier field, the target version number field, and the firmware data payload, temporarily stores the target device identifier and the target version number in the local random access memory, and stores the firmware data packet in the temporary buffer of the internal flash memory for use in the subsequent upgrade process.

[0087] S12. Based on the target device identifier, determine the target upgrade object.

[0088] In this embodiment, the target upgrade object is determined by matching the target device identifier in the upgrade command with the chip identifier information stored locally. For example, when the target device identifier is 0x01, it matches the preset identifier of the first control chip, and the upgrade object is determined to be the first control chip. When the target device identifier is 0x02, it matches the preset identifier of the second control chip, and the upgrade object is determined to be the second control chip. This provides a basis for judgment for establishing the corresponding upgrade channel in the future.

[0089] Specifically, the first control chip matches the extracted target device identifier with the locally stored chip identifier information, thereby accurately determining the target object of this upgrade based on the identifier matching result.

[0090] S13. If the target device identifier matches the preset identifier of the first control chip, then the target upgrade object is determined to be the first control chip.

[0091] In this embodiment, the preset identifier of the first control chip refers to the unique address number burned into the first control chip at the factory. When the target device identifier matches the preset identifier, it indicates that the host computer requests an upgrade to the firmware of the first control chip itself. For example, if the preset identifier of the first control chip is 0x01, and the target device identifier is also 0x01, it can be determined that the upgrade operation is for the first control chip itself.

[0092] Specifically, if the target device identifier matches the preset identifier stored locally in the first control chip, then the target of this upgrade is determined to be the first control chip itself.

[0093] S14. If the target device identifier matches the preset identifier of the second control chip, then the target upgrade object is determined to be the second control chip.

[0094] In this embodiment, the preset identifier of the second control chip refers to the unique address number burned into the second control chip at the factory. When the target device identifier matches the preset identifier, it indicates that the host computer is requesting an upgrade to the firmware of the second control chip. For example, if the preset identifier of the second control chip is 0x02, and the target device identifier is also 0x02, it can be determined that this upgrade operation is for the second control chip.

[0095] Specifically, if the target device identifier matches the preset identifier of the second control chip stored in the local configuration table, then the target of this upgrade is determined to be the second control chip.

[0096] Furthermore, if the target device identifier does not match the preset identifier of the first control chip or the preset identifier of the second control chip, an abnormal target device identifier is generated, and an invalid upgrade command response is sent to the host computer via the IO-Link interface.

[0097] In one embodiment, step S20, namely, taking over the IO-Link communication link by the first control chip to maintain the IO-Link communication connection state, specifically includes:

[0098] S21. Control the first control chip to stop the transmission of radio frequency tag reading and writing service data between the first control chip and the second control chip.

[0099] In this embodiment, RFID tag read / write service data refers to the tag identification, data reading, and data writing service information transmitted between the first and second control chips in the normal operating mode of the dual-chip RFID system. For example, in a warehousing and logistics scenario, the RFID reader needs to continuously read the ID and batch information on the goods tags. This data is collected by the RFID front-end of the second control chip and transmitted to the first control chip, which then reports it to the host computer through the IO-Link interface. Stopping the transmission of this service data during the upgrade process can form a pause forwarding control for RFID tag read / write service requests, avoiding conflicts between service data and upgrade data on the internal communication channel, and helping to maintain the integrity and reliability of firmware data packet transmission.

[0100] Specifically, after determining that the target upgrade object is the second control chip, the first control chip sends a service suspension command to the internal communication channel to suspend forwarding any RFID tag read / write requests from the host computer to the second control chip. At the same time, after receiving the service suspension command, the second control chip stops sending tag response data to the first control chip, thereby avoiding conflicts between service data and upgrade data on the internal communication channel.

[0101] S22. Receive periodic process data requests from the host computer via the first control chip, generate corresponding response messages based on the periodic process data requests, and feed the response messages back to the host computer. The response messages are configured with status parameters indicating the maintenance status so that the host computer can maintain the communication connection with the dual-chip RFID system.

[0102] In this embodiment, periodic process data requests are a standard mechanism for periodic data exchange between the master station and the device in the IO-Link protocol. For example, the IO-Link master station will send process data requests to the device at fixed communication intervals such as 2ms or 10ms. The device must respond within the specified time; otherwise, the master station will determine that the communication has timed out and trigger an offline alarm. The status parameter is a field in the response message used to identify the current operating status of the device. For example, setting the device status byte to 0x02 in the response message indicates maintenance mode. After receiving the response, the master station can identify the device as being in maintenance mode, thereby reducing the probability of triggering a communication timeout alarm due to non-response and maintaining the IO-Link communication connection status.

[0103] Specifically, during the period when the first control chip takes over the IO-Link communication link, it continuously listens for periodic process data request messages on the IO-Link physical layer interface. When it receives such a request message, the first control chip reads the pre-configured maintenance status parameters from the local storage area, fills the maintenance status parameters into the specified byte position of the process data response message, and sends the response message to the host computer through the IO-Link physical layer interface, thereby maintaining the IO-Link communication connection without relying on the business data of the second control chip.

[0104] More specifically, the maintenance status parameters include a maintenance status identifier and an upgrade stage identifier. The maintenance status identifier indicates that the dual-chip RFID system is currently in a firmware upgrade maintenance state; the upgrade stage identifier indicates whether it is currently in the upgrade trigger stage, firmware transmission stage, firmware writing stage, restart waiting stage, or version verification stage. During the takeover of the IO-Link communication link, the first control chip generates a process data response message according to the IO-Link communication cycle and fills the maintenance status parameters into the process data response message. After receiving the process data response message containing the maintenance status parameters, the host computer identifies the dual-chip RFID system as being in an online maintenance state, rather than a communication offline state.

[0105] In one embodiment, step S30, namely, acquiring the internal status signal of the second control chip during the firmware update process based on the internal communication channel, specifically includes:

[0106] S31. The first control chip sends an upgrade trigger command to the second control chip through the internal communication channel, so that the second control chip enters the boot loading mode.

[0107] In this embodiment, the upgrade trigger instruction is a predefined command frame sent by the first control chip to the second control chip through an internal communication interface. For example, the instruction frame may contain a specific frame header identifier such as 0xAA55 and a command code such as 0x01 to indicate upgrade trigger. After receiving the instruction, the second control chip will set the local upgrade flag and store it in non-volatile memory. Then, it will perform a reset operation and jump to the bootloader, thereby entering the bootloader mode that can receive firmware data. In this mode, the second control chip only runs a minimal bootloader and has Flash erasure and writing and data reception capabilities.

[0108] Specifically, the first control chip sends a predefined upgrade trigger instruction frame to the second control chip through an internal communication interface. After receiving the instruction frame, the application program of the second control chip sets the upgrade flag in the non-volatile memory and then performs a chip reset operation. After the chip is reset, the bootloader reads the upgrade flag and, if the flag is valid, stays in the bootloader mode to wait for the firmware data to be sent.

[0109] S32. If a ready signal is detected from the second control chip, the received firmware data packet is sent to the second control chip through the internal communication channel via the first control chip.

[0110] In this embodiment, the ready signal refers to the acknowledgment frame returned by the second control chip to the first control chip through the internal communication interface after the second control chip enters the boot loading mode. For example, the acknowledgment frame may contain a specific status code such as 0x00 to indicate readiness. After the first control chip detects the ready signal, it confirms that the second control chip is ready to receive firmware data and then begins to forward data packets. This ready confirmation mechanism can ensure that the firmware data is transmitted only after the second control chip is ready, avoiding communication conflicts or data loss caused by sending data before the second control chip has entered the boot loading mode.

[0111] Specifically, after sending the upgrade trigger command, the first control chip starts an internal timer and listens for feedback data from the second control chip on the internal communication channel. When it successfully receives the ready signal sent by the second control chip, the first control chip stops the timer and reads the firmware data packet from the local flash memory buffer. It then sends the firmware data packet frame by frame to the second control chip through the internal communication channel according to the predetermined frame format.

[0112] S33, Monitor the internal status signals returned by the second control chip.

[0113] In this embodiment, the internal status signal is the hardware execution status information that the second control chip sends back to the first control chip through the internal communication interface during the process of receiving and burning firmware data. For example, after receiving each data frame, the second control chip will return a status frame containing the CRC check result. If the CRC check passes, it will return an ACK confirmation signal; if the CRC check fails, it will return a NACK negation signal and the corresponding error code. By continuously monitoring these status signals, the first control chip can keep track of the burning progress and abnormal situations of the second control chip in real time.

[0114] Specifically, during firmware data packet transmission, the first control chip switches to listening mode after sending each frame of data, waiting for the status feedback frame returned by the second control chip. This status feedback frame contains the data verification result and the flash memory write result. The first control chip extracts the corresponding internal status signal by parsing the status feedback frame to obtain the current data reception and burning status of the second control chip.

[0115] In one embodiment, step S40, which involves constructing IO-Link protocol standard response information based on internal state signals according to preset protocol mapping rules, specifically includes:

[0116] S41. Identify the hardware execution state corresponding to the internal status signal to determine the current update state of the second control chip. The hardware execution state includes at least write timeout, verification error, or write protection exception.

[0117] In this embodiment, hardware execution status refers to the low-level hardware anomalies that the second control chip may encounter during firmware burning. For example, write timeout means that when the second control chip writes data to the Flash memory, the write operation fails to complete within the specified time due to excessive Flash erase / write time or bus congestion; check error means that when the second control chip performs CRC check after receiving firmware data, it finds that the data packet content is inconsistent with expectations; write protection anomaly means that the Flash storage area of ​​the second control chip is set to write protection, preventing the write operation from being performed. Identifying these hardware execution states helps the first control chip accurately determine the current update progress of the second control chip and whether there are any anomalies.

[0118] Specifically, the first control chip decodes the internal status signal returned by the second control chip, identifies the hardware execution status code contained therein, and matches the status code field with a predefined hardware status mapping table. If the status code is 0x01, the current update status is determined to be write timeout; if the status code is 0x02, the current update status is determined to be verification error; and if the status code is 0x03, the current update status is determined to be write protection exception, thereby determining the current update status of the second control chip.

[0119] S42. Based on the hardware execution status, retrieve the corresponding IO-Link event code in the protocol mapping rules.

[0120] In this embodiment, the protocol mapping rule is a predefined correspondence table between the internal hardware execution state and IO-Link event codes. For example, the mapping rule can be configured such that write timeout corresponds to the first IO-Link event code, verification error corresponds to the second IO-Link event code, and write protection exception corresponds to the third IO-Link event code. The first IO-Link event code, the second IO-Link event code, and the third IO-Link event code can be standard event codes under the IO-Link diagnostic mechanism or device-defined event codes. Through this mapping rule, the host computer does not need to understand the internal communication protocol of the second control chip to obtain the real state of the underlying hardware through the standard IO-Link protocol interface.

[0121] Specifically, after determining the hardware execution state, the first control chip uses the hardware execution state as an index key to query the locally stored protocol mapping rule table, locates the IO-Link event code corresponding to the hardware execution state in the mapping rule table, and the IO-Link event code conforms to the diagnostic event definition in the IO-Link specification, thereby realizing the conversion from internal private state to IO-Link event information.

[0122] S43. Write the IO-Link event code into the preset protocol stack diagnostic buffer in the first control chip to generate IO-Link protocol standard response information.

[0123] In this embodiment, the protocol stack diagnostic buffer refers to a memory area in the IO-Link protocol stack specifically used to store device diagnostic information. When IO-Link event codes are written into this buffer, the protocol stack can generate response messages that conform to the IO-Link frame format. For example, this buffer usually corresponds to the Event mechanism in the IO-Link protocol. When a device malfunctions, the protocol stack will write the corresponding event code into this buffer and report the event code as diagnostic information to the host computer in the next communication cycle with the master station. After receiving the diagnostic information, the host computer can decide whether to resend the firmware data packet, terminate the upgrade operation, or trigger manual intervention.

[0124] Specifically, the first control chip writes the retrieved IO-Link event code into a preset diagnostic buffer in the local IO-Link protocol stack. The event code in the diagnostic buffer will be automatically encapsulated into a standard diagnostic response message and sent to the host computer in subsequent IO-Link communication cycles, thereby enabling the host computer to obtain the actual hardware execution status of the second control chip through the standard IO-Link diagnostic mechanism.

[0125] More specifically, after the first control chip writes the IO-Link event code into the protocol stack diagnostic buffer, the IO-Link protocol stack reads the event code from the protocol stack diagnostic buffer in subsequent communication cycles and generates a diagnostic event response message according to the IO-Link diagnostic event format. After receiving the diagnostic event response message, the host computer can determine the type of exception encountered by the second control chip during the firmware update process based on the event code within it.

[0126] In one embodiment, step S50, which involves using the first control chip to perform version consistency verification on the second control chip to determine the version matching result, specifically includes:

[0127] S51. Use the first control chip to send a version query request to the restarted second control chip to obtain the current running firmware version number fed back by the second control chip.

[0128] In this embodiment, the version query request is a predefined query command frame sent by the first control chip to the second control chip through the internal communication interface. For example, the query frame may contain command code 0x10, which indicates a version query. After receiving the query frame, the second control chip reads the currently running firmware version number from its own firmware storage area and returns it to the first control chip through the internal communication interface. The version number is usually represented in the format of major version number, minor version number and revision number, such as v2.0.1.

[0129] Specifically, the first control chip initiates a version query request to the restarted second control chip. After receiving the request, the second control chip reads the currently running firmware version number from the local firmware storage area and returns it to the first control chip through the internal communication interface, thereby obtaining the firmware version information that the second control chip is currently running.

[0130] S52. Compare the current firmware version number with the target version number.

[0131] In this embodiment, the version comparison is a process of matching the current running firmware version number fed back by the second control chip with the target version number carried in the upgrade command field by field. For example, if the target version number is v2.0.1, and the current running firmware version number fed back by the second control chip is also v2.0.1, it means that the versions are completely matched; if the version number fed back by the second control chip is still the old version v1.0.0, it means that the versions are not matched. The comparison result will serve as a key basis for determining whether the upgrade is successful, and will help identify upgrade failures caused by power outages or other abnormalities.

[0132] Specifically, the first control chip compares the current firmware version number fed back by the second control chip with the target version number carried in the upgrade instruction field by field, thereby determining whether the two version numbers are completely consistent.

[0133] S53. If the current firmware version number matches the target version number, the version matching result is determined to be a successful verification.

[0134] In this embodiment, a successful verification indicates that the firmware update of the second control chip has been successfully completed, and the currently running firmware version is completely consistent with the target version expected by the host computer. For example, when the target version number is v2.0.1 and the currently running firmware version number fed back by the second control chip is also v2.0.1, the verification can be determined to be successful. At this time, the dual-chip system can safely resume service operation.

[0135] Specifically, if all fields of the current firmware version number and the target version number are consistent, the version matching result is determined to be a successful verification, thus providing a basis for judgment for the subsequent recovery of RFID tag read and write service data transmission.

[0136] S54. If the current firmware version number is inconsistent with the target version number, the version matching result is determined to be a verification error.

[0137] In this embodiment, a verification failure indicates that the firmware update of the second control chip may not have actually taken effect, and there is a difference between the currently running firmware version and the target version expected by the host computer. For example, when the target version number is v2.0.1 but the current running firmware version number fed back by the second control chip is still the old version v1.0.0, a verification failure can be determined. This failure may be caused by power failure, data packet loss or Flash writing failure during the burning process.

[0138] Specifically, if any field between the current firmware version number and the target version number is inconsistent, the version matching result is determined to be a verification anomaly, which can trigger the reporting of a version conflict anomaly event and provide a basis for determining whether to continue to stop forwarding RFID tag read / write service requests to the second control chip.

[0139] In one embodiment, step S60, namely, determining the upgrade status result of the dual-chip RFID system based on the version matching result, and controlling the communication status of the IO-Link communication link based on the upgrade status result, specifically includes:

[0140] S61. If the version matching result is verified, the upgrade status result is determined to be successful. The first control chip is controlled to resume the data transmission of radio frequency tag reading and writing services between the first control chip and the second control chip, and the target version number is written into the IO-Link device parameter storage area stored in the first control chip.

[0141] In this embodiment, restoring RFID tag read / write data transmission means that after the first control chip confirms that the current firmware version number of the second control chip is consistent with the target version number, it allows the second control chip to participate in RFID tag identification, data reading, and data writing services again. The IO-Link device parameter storage area is a local storage area in the first control chip used to store device parameters. The device version parameters in this local storage area can be read by the host computer through the IO-Link parameter access method.

[0142] Specifically, when the version matching result is verified, the first control chip marks the upgrade status result as successful, resumes forwarding of RFID tag read / write service requests, enabling the second control chip to continue processing RFID tag read / write services. At the same time, the target version number is written into the storage location corresponding to the firmware version parameter in the local device parameter storage area of ​​the first control chip, so that the host computer can read the updated firmware version information through the IO-Link interface.

[0143] S62. If the version matching result is an error, the upgrade status result is determined to be an upgrade failure. The first control chip is controlled to continue to stop forwarding RFID tag read / write service requests to the second control chip. At the same time, the version conflict error event is reported to the host computer through the IO-Link interface.

[0144] In this embodiment, continuing to stop forwarding RFID tag read / write service requests to the second control chip means that after the first control chip confirms that the current firmware version number of the second control chip is inconsistent with the target version number, it continues to intercept RFID tag read / write service requests from the host computer, thus preventing the second control chip from participating in tag identification, data reading, or data writing processes when the versions are mismatched. The version conflict exception event is diagnostic information reported by the first control chip to the host computer through the IO-Link interface, indicating that the current firmware version number of the second control chip is inconsistent with the target version number.

[0145] Specifically, when the version matching result is an error, the first control chip marks the upgrade status result as an upgrade failure, maintains the interception of RFID tag read / write service requests, does not forward new RFID tag read / write service requests to the second control chip, and simultaneously calls the event reporting interface of the IO-Link protocol stack to generate a diagnostic event message containing a version conflict identifier, and sends the diagnostic event message to the host computer through the IO-Link interface so that the host computer is aware of the version inconsistency anomaly in the second control chip.

[0146] In one embodiment, such as Figure 2 As shown, prior to step S20, the dual-chip RFID system firmware upgrade method further includes:

[0147] S201. If the target upgrade object is the first control chip, then control the first control chip to enter the firmware self-upgrade state.

[0148] In this embodiment, the firmware self-upgrade state refers to the running state in which the first control chip performs its own firmware update. The firmware self-upgrade state may include a bootloader mode. In this state, the first control chip does not execute the complete RFID business processing logic, but instead executes maintenance processing logic for receiving firmware data packets and maintaining IO-Link communication state.

[0149] Specifically, when the first control chip parses the upgrade command and determines that the target upgrade object is itself, the first control chip can set a self-upgrade flag and trigger a chip reset. After the chip restarts, it enters the boot loading mode so that the first control chip is in a firmware self-upgrade state that can receive firmware data packets and perform firmware self-update operations.

[0150] S202. In the firmware self-upgrade state, the first control chip maintains the IO-Link communication state with the host computer based on the preset maintenance response rules, and receives the firmware data packets sent by the host computer.

[0151] In this embodiment, the preset maintenance response rule refers to the processing rule used by the first control chip to respond to the communication request of the host computer when the firmware is in the self-upgrade state. The preset maintenance response rule may include the response rule for periodic process data request, the filling rule for maintenance status parameters, and the receiving rule for firmware data packets, so that the host computer can identify that the first control chip is in the firmware maintenance process.

[0152] Specifically, in firmware self-upgrade mode, the first control chip initializes the minimum communication processing logic to maintain IO-Link communication, and listens for periodic process data requests and firmware data packets sent by the host computer through the IO-Link interface; when a periodic process data request is received, the first control chip generates a response message containing maintenance status parameters according to the preset maintenance response rules and sends it back to the host computer; when a firmware data packet is received, the first control chip writes the firmware data packet into a temporary buffer area for subsequent firmware self-update operations.

[0153] More specifically, the program storage space of the first control chip includes a bootloader area and an application area. The bootloader area stores the self-upgrade control program and the minimum IO-Link communication processing logic, while the application area stores the business application of the first control chip. When the first control chip enters the firmware self-upgrade state, it runs the self-upgrade control program in the bootloader area and responds to periodic process data requests from the host computer and receives firmware data packets from the host computer through the minimum IO-Link communication processing logic. During the erasure and writing of the application area, the first control chip generates a response message containing maintenance status parameters according to preset maintenance response rules to maintain the IO-Link maintenance communication state.

[0154] S203. Perform firmware self-update operation on the first control chip based on the firmware data package.

[0155] In this embodiment, the firmware self-update operation refers to the process by which the first control chip updates its own application code based on the received firmware data packet. For example, the first control chip can perform frame reception, integrity verification and writing processing on the firmware data packet to write the new application data into the corresponding program storage area.

[0156] Specifically, the first control chip performs integrity verification on the received firmware data packet. If the verification passes, it calls the internal memory write interface to write the program data in the firmware data packet into the application storage area of ​​the first control chip. If the verification fails, it can report firmware data abnormality information to the host computer based on preset maintenance response rules, so that the host computer can resend the corresponding firmware data packet or terminate the current self-update operation.

[0157] S204. After the firmware self-update operation is completed, control the first control chip to switch to the application running state.

[0158] In this embodiment, the application running state refers to the state in which the first control chip runs the updated application code after completing the firmware self-update operation. In this state, the first control chip can resume normal processing of the IO-Link communication protocol stack and the dual-chip RFID service process.

[0159] Specifically, after the firmware data packet is written and verified, the first control chip clears the self-upgrade flag and performs a reset operation. After the chip restarts, it jumps to the updated application area to resume processing of the host computer IO-Link communication requests and dual-chip RFID business data interaction.

[0160] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0161] In one embodiment, a computer device is provided, which can be installed in a dual-chip RFID system or communicatively connected to a first control chip of the dual-chip RFID system. The computer device includes a processor, a memory, and a communication interface. The communication interface is used for data interaction with an IO-Link interface and an internal communication channel between the first and second control chips. The memory stores a computer program, and when the processor executes the computer program, it implements a firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol.

[0162] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0163] Obtain the upgrade command issued by the host computer through the IO-Link interface, and determine the target upgrade object based on the upgrade command;

[0164] If the target upgrade object is the second control chip, the first control chip takes over the IO-Link communication link to maintain the IO-Link communication connection state and builds an internal communication channel between the first control chip and the second control chip.

[0165] Based on the internal communication channel, the internal status signals of the second control chip during the firmware update process are obtained;

[0166] According to the preset protocol mapping rules, construct the IO-Link protocol standard response information based on the internal status signals, and feed the IO-Link protocol standard response information back to the host computer;

[0167] In response to the signal that the second control chip has completed the firmware update and restarted, the first control chip is used to perform a version consistency check on the second control chip to determine the version matching result.

[0168] Based on the version matching results, the upgrade status of the dual-chip RFID system is determined, and the communication status of the IO-Link communication link is controlled based on the upgrade status results.

[0169] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0170] Obtain the upgrade command issued by the host computer through the IO-Link interface, and determine the target upgrade object based on the upgrade command;

[0171] If the target upgrade object is the second control chip, the first control chip takes over the IO-Link communication link to maintain the IO-Link communication connection state and builds an internal communication channel between the first control chip and the second control chip.

[0172] Based on the internal communication channel, the internal status signals of the second control chip during the firmware update process are obtained;

[0173] According to the preset protocol mapping rules, construct the IO-Link protocol standard response information based on the internal status signals, and feed the IO-Link protocol standard response information back to the host computer;

[0174] In response to the signal that the second control chip has completed the firmware update and restarted, the first control chip is used to perform a version consistency check on the second control chip to determine the version matching result.

[0175] Based on the version matching results, the upgrade status of the dual-chip RFID system is determined, and the communication status of the IO-Link communication link is controlled based on the upgrade status results.

[0176] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0177] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0178] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol, characterized in that, A firmware upgrade method for a dual-chip RFID system, comprising a first control chip and a second control chip, is provided, comprising: Obtain the upgrade command issued by the host computer through the IO-Link interface, and determine the target upgrade object based on the upgrade command; If the target upgrade object is the second control chip, then the first control chip takes over the IO-Link communication link to maintain the IO-Link communication connection state, and an internal communication channel is built between the first control chip and the second control chip; Based on the internal communication channel, the internal status signal of the second control chip during the firmware update process is obtained; According to the preset protocol mapping rules, IO-Link protocol standard response information is constructed based on the internal status signals, and the IO-Link protocol standard response information is fed back to the host computer; In response to the signal that the second control chip has completed the firmware update and restarted, the first control chip is used to perform a version consistency check on the second control chip to determine the version matching result. Based on the version matching result, the upgrade status of the dual-chip RFID system is determined, and the communication status of the IO-Link communication link is controlled based on the upgrade status result.

2. The firmware upgrade method for a dual-chip RFID system according to claim 1, characterized in that, The step of determining the target upgrade object according to the upgrade instruction specifically includes: Based on the upgrade instruction, the target device identifier, target version number, and firmware data package are obtained; The target upgrade object is determined based on the target device identifier; If the target device identifier matches the preset identifier of the first control chip, then the target upgrade object is determined to be the first control chip; If the target device identifier matches the preset identifier of the second control chip, then the target upgrade object is determined to be the second control chip.

3. The firmware upgrade method for a dual-chip RFID system according to claim 2, characterized in that, The step of taking over the IO-Link communication link through the first control chip to maintain the IO-Link communication connection state specifically includes: By controlling the first control chip to stop the transmission of radio frequency tag read / write service data between it and the second control chip; The first control chip receives periodic process data requests from the host computer, generates corresponding response messages based on the periodic process data requests, and feeds back the response messages to the host computer. The response messages are configured with status parameters indicating the maintenance status so that the host computer maintains the communication connection with the dual-chip RFID system.

4. The firmware upgrade method for a dual-chip RFID system according to claim 2, characterized in that, The step of acquiring the internal status signal of the second control chip during the firmware update process based on the internal communication channel specifically includes: The first control chip sends an upgrade trigger command to the second control chip via the internal communication channel, so that the second control chip enters the boot loading mode. If a ready signal is detected from the second control chip, the first control chip sends the received firmware data packet to the second control chip through the internal communication channel. Monitor the internal status signals transmitted back by the second control chip.

5. The firmware upgrade method for a dual-chip RFID system according to claim 4, characterized in that, The step of constructing IO-Link protocol standard response information based on the internal state signals according to the preset protocol mapping rules specifically includes: Identify the hardware execution state corresponding to the internal status signal to determine the current update state of the second control chip. The hardware execution state includes at least write timeout, verification error, or write protection exception. Based on the hardware execution state, retrieve the corresponding IO-Link event code from the protocol mapping rules; The IO-Link event code is written into a preset protocol stack diagnostic buffer within the first control chip to generate the IO-Link protocol standard response information.

6. The firmware upgrade method for a dual-chip RFID system according to claim 3, characterized in that, The step of using the first control chip to perform version consistency verification on the second control chip to determine the version matching result specifically includes: The first control chip initiates a version query request to the restarted second control chip to obtain the current running firmware version number fed back by the second control chip; Compare the current firmware version number with the target version number; If the current running firmware version number is consistent with the target version number, then the version matching result is determined to be a successful verification. If the current firmware version number is inconsistent with the target version number, then the version matching result is determined to be a verification error.

7. The firmware upgrade method for a dual-chip RFID system according to claim 6, characterized in that, The step of determining the upgrade status of the dual-chip RFID system based on the version matching result, and controlling the communication status of the IO-Link communication link based on the upgrade status result, specifically includes: If the version matching result is verified, the upgrade status result is determined to be successful. The first control chip is controlled to resume the RFID tag read / write service data transmission with the second control chip, and the target version number is written into the IO-Link device parameter storage area stored in the first control chip. If the version matching result is an error, the upgrade status result is determined to be an upgrade failure. The first control chip is then controlled to continue to stop forwarding RFID tag read / write service requests to the second control chip. At the same time, a version conflict error event is reported to the host computer through the IO-Link interface.

8. The firmware upgrade method for a dual-chip RFID system according to claim 2, characterized in that, The firmware upgrade method for the dual-chip RFID system also includes: If the target upgrade object is the first control chip, then control the first control chip to enter the firmware self-upgrade state; In the firmware self-upgrade state, the first control chip maintains the IO-Link communication state with the host computer based on the preset maintenance response rules, and receives the firmware data packet sent by the host computer; The firmware self-update operation of the first control chip is performed based on the firmware data package; After the firmware self-update operation is completed, the first control chip is switched to the application running state.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the firmware upgrade method for a dual-chip RFID system supporting the IO-Link protocol as described in any one of claims 1 to 8.

Images