Firmware downloading method, host, front end plate, ultrasonic diagnosis equipment and storage medium

Abstract

The embodiment of the invention discloses a firmware downloading method, a host, a front end plate, ultrasonic diagnosis equipment and a storage medium, the method is applied to the host of the ultrasonic diagnosis equipment, the ultrasonic diagnosis equipment further comprises the front end plate, the front end plate comprises a USB interface chip, a first memory and an FPGA, the USB interface chip is connected with the host through a USB bus, and the first memory is connected with the FPGA. Data transmission is carried out between the FPGA and the host through the USB interface chip, the first memory is connected with the USB interface chip, and the method comprises the following steps: controlling a starting mode of the USB interface chip to be configured to be started from a USB; downloading the communication interface firmware from the host to a second memory in the USB interface chip through the USB bus; controlling the communication interface firmware to be executed on the USB interface chip; and in the execution process of the communication interface firmware, sending the target firmware to the communication interface firmware through the USB bus so that the communication interface firmware stores the target firmware to the first memory. According to the scheme, online downloading of the firmware of the ultrasonic diagnosis equipment can be realized, and the firmware downloading cost can be reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of ultrasonic diagnostic equipment, in particular to a firmware download method, a host, a front-end board, an ultrasonic diagnostic equipment, a storage medium and a computer program product. BACKGROUND

[0002] The ultrasonic diagnostic equipment mainly comprises the following hardware structures: a front-end board, a back-end computing platform (also referred to as a host), and peripheral devices including a keyboard board. The front-end board is internally provided with a field programmable gate array (FPGA), which is mainly used for ultrasonic wave control, transmission, reception, beam synthesis, etc., and transmits the processed data to the back-end computing platform through a high-speed bus for doctors to view and analyze.

[0003] In the ultrasonic diagnostic equipment, the data interaction between the FPGA and the host is achieved through a universal serial bus (USB) interface chip, which is a very widely used design scheme. The USB interface chip itself can be considered as a single-chip microcomputer that can encode and decode USB data packets. In order to achieve high-speed data transmission between the FPGA and the host, a matching chip firmware (which can be referred to as a USB interface chip firmware) is needed to drive. On the other hand, the FPGA needs a specific chip firmware (which can be referred to as a FPGA firmware) to complete the complex functions such as specified mode ultrasonic wave control and beam synthesis. Therefore, the FPGA and the USB interface chip in the front-end board both need chip firmware to achieve the specified functions.

[0004] In the related art, the storage method for the FPGA firmware and the USB interface chip firmware is offline programming, that is, the firmware is programmed by a dedicated tool before the storage chip is pasted on the production line after the development is completed. This offline programming scheme has low firmware download efficiency. If the firmware in the storage chip needs to be updated, the machine has to be disassembled and reprogrammed, resulting in high firmware download cost. SUMMARY

[0005] The present application is proposed in consideration of the above problems. The embodiments of the present application provide a firmware download method, a host, a front-end board, an ultrasonic diagnostic equipment, a storage medium and a computer program product, which can achieve online download of the USB interface chip firmware and / or the FPGA firmware required by the front-end board of the ultrasonic diagnostic equipment, and has high firmware download efficiency and low download cost.

[0006] According to an aspect of the present application, a firmware download method is provided, which is applied to a host of an ultrasonic diagnostic device, the ultrasonic diagnostic device further comprising a front-end board, the front-end board comprising a USB interface chip, a first memory and a FPGA, the USB interface chip being connected with the host through a USB bus, the FPGA and the host performing data transmission through the USB interface chip, the first memory being connected with the USB interface chip, the method comprising: controlling a start mode of the USB interface chip to be configured as a start from USB; downloading a communication interface firmware from the host to a second memory in the USB interface chip through the USB bus; controlling the communication interface firmware to execute on the USB interface chip; in a process of execution of the communication interface firmware, sending a target firmware to the communication interface firmware through the USB bus so as to store the target firmware to the first memory by the communication interface firmware; wherein the target firmware comprises a USB interface chip firmware and / or a FPGA firmware, the USB interface chip firmware being used to drive data transmission between the FPGA and the host, and the FPGA firmware being used to drive the FPGA to work.

[0007] Optionally, the downloading of the communication interface firmware from the host to the second memory in the USB interface chip through the USB bus comprises: performing a first interactive operation with a boot program in the USB interface chip through the USB bus, so as to download the communication interface firmware from the host to the second memory, the first interactive operation comprising: reading the communication interface firmware from a third memory in the host; generating firmware transmission data corresponding to the communication interface firmware, the firmware transmission data comprising the communication interface firmware; and sending the firmware transmission data to the boot program, so as to write the firmware transmission data to the second memory by the boot program; wherein in the process of sending the firmware transmission data to the boot program, the first interactive operation further comprises: receiving first feedback information sent by the boot program; and determining a writing condition of the communication interface firmware based on the first feedback information.

[0008] Optionally, the communication interface firmware comprises at least one data segment, wherein the sending of the firmware transmission data to the boot program comprises: for each data segment of the communication interface firmware, sending the data segment to the boot program in batches, wherein the data of each sending of the data segment is a first data group; and the receiving of the first feedback information sent by the boot program comprises: for each first data group, receiving first sub-feedback information corresponding to the first data group and sent by the boot program, the first sub-feedback information being generated by the boot program according to a writing condition of the first data group, and the first feedback information comprising the first sub-feedback information.

[0009] Optionally, the firmware transmission data further comprises a read-back command, and sending the firmware transmission data to the bootloader further comprises: for each first data group, after receiving first sub-feedback information corresponding to the first data group and sent by the bootloader, issuing a read-back command to the bootloader to read back the first data group in the second memory by the bootloader; and receiving first feedback information sent by the bootloader, further comprising: according to each first data group, receiving second sub-feedback information corresponding to the first data group and sent by the bootloader, wherein the second sub-feedback information is generated by the bootloader according to the read-back first data group, and the second sub-feedback information is used to verify whether the first data group in the second memory is correct, and the first feedback information further comprises the second sub-feedback information.

[0010] Optionally, the firmware transmission data comprises a device request, and sending the firmware transmission data to the bootloader comprises: before sending the communication interface firmware to the bootloader, sending the device request to the bootloader; receiving configuration information of the USB interface chip sent by the bootloader in response to the device request; and sending the communication interface firmware to the bootloader based on the configuration information.

[0011] Optionally, the communication interface firmware comprises at least one data segment, and before reading the communication interface firmware from the third memory in the host, the first interaction operation further comprises: verifying a signature identification of the communication interface firmware; when the signature identification verification passes, for each data segment of the communication interface firmware, reading a length and a base address of the data segment; and reading the communication interface firmware from the third memory in the host comprises: for each data segment of the communication interface firmware, reading the data segment from the third memory according to the length and the base address of the data segment.

[0012] Optionally, sending the target firmware to the communication interface firmware through the USB bus to store the target firmware to the first memory by the communication interface firmware comprises: performing a second interaction operation with the communication interface firmware in the USB interface chip through the USB bus to download the target firmware to the first memory, the second interaction operation comprising: issuing the target firmware to the communication interface firmware in the USB interface chip to write the target firmware to the first memory by the communication interface firmware; and receiving second feedback information sent by the communication interface firmware, and determining a writing condition of the target firmware based on the second feedback information.

[0013] Optionally, the target firmware is issued to the communication interface firmware in the USB interface chip to write the target firmware into the first memory through the communication interface firmware, including: sending the target firmware to the communication interface firmware in batches, wherein the data of each sending of the target firmware is a second data group; issuing a write command corresponding to each second data group to the communication interface firmware to control the communication interface firmware to write the second data group into the first memory; and receiving second feedback information sent by the communication interface firmware, including: receiving third sub-feedback information corresponding to each second data group sent by the communication interface firmware, the third sub-feedback information being generated by the communication interface firmware according to the writing condition of the second data group, and the second feedback information including the third sub-feedback information.

[0014] Optionally, the second interaction operation further includes: after receiving the third sub-feedback information corresponding to each second data group sent by the communication interface firmware, issuing a read-back command to the communication interface firmware to control the communication interface firmware to read back the second data group in the first memory; and receiving the second feedback information sent by the communication interface firmware, further including: receiving fourth sub-feedback information corresponding to each second data group sent by the communication interface firmware, wherein the fourth sub-feedback information is generated by the communication interface firmware according to the read-back second data group, and the fourth sub-feedback information is used to verify whether the second data group in the first memory is correct, and the second feedback information further includes the fourth sub-feedback information.

[0015] Optionally, the first memory includes a FLASH for storing the FPGA firmware, and the FLASH is connected with the USB interface chip through an SPI interface; the target firmware is issued to the communication interface firmware in the USB interface chip to write the target firmware into the first memory through the communication interface firmware, further including: after issuing the write command corresponding to each second data group to the communication interface firmware, issuing a query command to the communication interface firmware in the USB interface chip to control the communication interface firmware to query whether the SPI interface is in a busy state; and wherein the third sub-feedback information is generated by the communication interface firmware according to the state query result of the SPI interface.

[0016] Optionally, the first memory includes a FLASH for storing the FPGA firmware, and the front-end board further includes a switch for controlling the communication between the FLASH and the USB interface chip, the switch being connected with the FLASH and the USB interface chip through an SPI interface; before the target firmware is sent to the communication interface firmware through the USB bus to store the target firmware into the first memory by the communication interface firmware, the method further includes: controlling the switch to communicate the FLASH with the USB interface chip.

[0017] Optionally, the sending of the target firmware to the communication interface firmware through the USB bus for storage of the target firmware to the first memory by the communication interface firmware comprises: after detecting the USB interface chip restart, sending the target firmware to the communication interface firmware through the USB bus for storage of the target firmware to the first memory by the communication interface firmware; wherein the USB interface chip restarts after the communication interface firmware starts to execute.

[0018] According to another aspect of the present application, there is also provided a firmware download method applied to a front-end board of an ultrasonic diagnostic device, the ultrasonic diagnostic device further comprising a host computer, the front-end board comprising a USB interface chip, a first memory and a FPGA, the USB interface chip being connected with the host computer through a USB bus, the FPGA and the host computer performing data transmission through the USB interface chip, the first memory being connected with the USB interface chip, after the host computer configures a startup mode of the USB interface chip as a slave USB startup, the method comprising: downloading a communication interface firmware in the host computer to a second memory in the USB interface chip through the USB bus when the startup mode of the USB interface chip is configured as the slave USB startup; executing the communication interface firmware on the USB interface chip under the control of the host computer; receiving a target firmware sent by the host computer through the USB bus by the communication interface firmware and storing the target firmware to the first memory by the communication interface firmware in the process of executing the communication interface firmware; wherein the target firmware comprises a USB interface chip firmware and / or a FPGA firmware, the USB interface chip firmware being used to drive data transmission between the FPGA and the host computer, and the FPGA firmware being used to drive the FPGA to work.

[0019] Optionally, the USB interface chip is provided with a boot program, and the downloading of the communication interface firmware in the host computer to the second memory in the USB interface chip through the USB bus comprises: performing a first interactive operation between the boot program and the host computer through the USB bus to download the communication interface firmware in the host computer to the second memory, the first interactive operation comprising: receiving, by the boot program, firmware transmission data corresponding to the communication interface firmware sent by the host computer, and writing, by the boot program, the communication interface firmware in the firmware transmission data to the second memory; wherein in the process of receiving, by the boot program, the firmware transmission data corresponding to the communication interface firmware sent by the host computer, the first interactive operation further comprises: sending, by the boot program, first feedback information to the host computer, the first feedback information being used to indicate a writing situation of the communication interface firmware.

[0020] Optionally, the communication interface firmware includes at least one data segment, the first feedback information includes first sub-feedback information, and wherein receiving, by the bootloader, the firmware transmission data corresponding to the communication interface firmware sent by the host and writing, by the bootloader, the communication interface firmware in the firmware transmission data into the second memory includes: for each data segment of the communication interface firmware, receiving, by the bootloader, the data segment sent by the host in batches, wherein each received data of the data segment is a first data group; writing, by the bootloader, each received first data group into the second memory; and sending, by the bootloader, the first feedback information to the host, including: for each first data group, generating, by the bootloader, first sub-feedback information corresponding to the first data group according to a writing condition of the first data group, and sending the first sub-feedback information to the host, and the first feedback information includes the first sub-feedback information.

[0021] Optionally, the firmware transmission data further includes a read-back command, receiving, by the bootloader, the firmware transmission data corresponding to the communication interface firmware sent by the host and writing, by the bootloader, the communication interface firmware in the firmware transmission data into the second memory further includes: for each first data group, after sending the first sub-feedback information corresponding to the first data group to the host, receiving, by the bootloader, the read-back command issued by the host, and performing, by the bootloader, read-back on the first data group in the second memory; and sending, by the bootloader, the first feedback information to the host further includes: for each first data group, generating, by the bootloader, second sub-feedback information corresponding to the first data group according to the read-back first data group, and sending the second sub-feedback information to the host, wherein the second sub-feedback information is used to verify whether the first data group in the second memory is correct, and the first feedback information further includes the second sub-feedback information.

[0022] Optionally, the firmware transmission data further includes a device request, and receiving, by the bootloader, the firmware transmission data corresponding to the communication interface firmware sent by the host includes: receiving, by the bootloader, the device request sent by the host before the bootloader receives the communication interface firmware; sending, by the bootloader, configuration information of the USB interface chip to the host in response to the device request; and receiving, by the bootloader, the communication interface firmware sent by the host based on the configuration information.

[0023] Optionally, the USB interface chip is provided with the bootloader, and the communication interface firmware is executed on the USB interface chip under control of the host, including: receiving, by the bootloader, an execution request sent by the host, and controlling, by the bootloader, a program counter pointer of the USB interface chip to jump to an entry address of the communication interface firmware in the second memory in response to the execution request; and wherein the communication interface firmware starts to be executed on the USB interface chip when the program counter pointer jumps to the entry address of the communication interface firmware in the second memory.

[0024] Optionally, the communication interface firmware receives the target firmware sent by the host via the USB bus and stores the target firmware in the first memory, including: the communication interface firmware performs a second interactive operation with the host via the USB bus to download the target firmware to the first memory, the second interactive operation including: the communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory; the communication interface firmware generates second feedback information based on the writing status of the target firmware and sends the second feedback information to the host.

[0025] Optionally, the communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory, including: receiving the target firmware sent by the host in batches, wherein the data received in each batch of the target firmware is a second data group; for each second data group, the communication interface firmware receives a write command sent by the host corresponding to the second data group, and writes the second data group into the first memory in response to the write command; the communication interface firmware generates second feedback information according to the writing status of the target firmware and sends the second feedback information to the host, including: for each second data group, the communication interface firmware generates third sub-feedback information corresponding to the second data group according to the writing status of the second data group, and sends the third sub-feedback information to the host, wherein the second feedback information includes the third sub-feedback information.

[0026] Optionally, the second interactive operation further includes: for each second data group, after sending the third sub-feedback information corresponding to the second data group to the host, the communication interface firmware receives a readback command issued by the host, and the communication interface firmware reads back the second data group in the first memory in response to the readback command; the communication interface firmware generates second feedback information according to the write status of the target firmware, and sends the second feedback information to the host, further including: for each second data group, the communication interface firmware generates a fourth sub-feedback information corresponding to the second data group according to the readback second data group, the fourth sub-feedback information is used to verify whether the second data group in the first memory is correct, and the second feedback information also includes the fourth sub-feedback information.

[0027] Optionally, the first memory includes a FLASH for storing FPGA firmware, and the FLASH is connected to the USB interface chip via an SPI interface. The communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory. The method also includes: for each second data group, after the communication interface firmware receives a write command sent by the host corresponding to the second data group, the communication interface firmware receives a query command sent by the host and queries whether the SPI interface is busy in response to the query command. The third sub-feedback information is generated by the communication interface firmware based on the status query result of the SPI interface.

[0028] Optionally, the first memory includes FLASH for storing FPGA firmware, and the front-end board also includes a switching switch for controlling the connection between FLASH and USB interface chip. The switching switch is connected to FLASH and USB interface chip respectively via SPI interface. Before the target firmware is written into the first memory by the communication interface firmware, the method further includes: controlling the switching switch to connect FLASH and USB interface chip under the control of the host.

[0029] Optionally, the first memory includes an EEPROM for storing the firmware of the USB interface chip, and the EEPROM is connected to the USB interface chip via an I2C interface.

[0030] According to another aspect of the present invention, a host computer is also provided, which is applied to an ultrasound diagnostic device. The ultrasound diagnostic device includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The host computer is used to connect to the USB interface chip via a USB bus. The host computer is also used to transmit data with the FPGA via the USB interface chip. The first memory is connected to the USB interface chip. The host computer is used to execute the above-described firmware download method.

[0031] According to another aspect of the present invention, a front-end board is also provided, which is applied to an ultrasound diagnostic device. The ultrasound diagnostic device includes a host, and the front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is used to connect to the host via a USB bus, the FPGA is used to transmit data with the host via the USB interface chip, the first memory is connected to the USB interface chip, and the front-end board is used to execute the above-described firmware download method.

[0032] According to another aspect of the present invention, an ultrasound diagnostic device is also provided, including a host and a front-end board. The front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA and the host transmit data through the USB interface chip. The first memory is connected to the USB interface chip. The host is used to execute the firmware download method described above, and the front-end board is used to execute the firmware download method described above.

[0033] According to another aspect of the present invention, a storage medium is also provided for use in the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA transmits data to the host via the USB interface chip. The first memory is connected to the USB interface chip, and program instructions are stored on the storage medium. When the program instructions are run, they are used to execute the above-described firmware download method.

[0034] According to another aspect of the present invention, a computer program product is also provided, which is applied to the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA transmits data to the host via the USB interface chip. The first memory is connected to the USB interface chip. The computer program product includes computer program instructions, which are used to execute the above-described firmware download method when running.

[0035] The above firmware download method can realize the online download of the target firmware (including USB interface chip firmware and / or FPGA firmware) required by ultrasound diagnostic equipment. This online download method helps to reduce the difficulty of disassembling and separating components required for offline burning, thus improving the firmware download efficiency and reducing the firmware download cost.

[0036] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0037] The above and other objects, features, and advantages of the present invention will become more apparent from the more detailed description of the embodiments of the invention in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same parts or steps.

[0038] Figure 1 A schematic diagram of the data transmission architecture between the front-end board and the host of an ultrasound diagnostic device according to an embodiment of the present invention is shown.

[0039] Figure 2 A schematic flowchart of a firmware download method according to an embodiment of the present invention is shown;

[0040] Figure 3 A schematic diagram of the communication link between a host and a USB interface chip according to an embodiment of the present invention is shown;

[0041] Figure 4 A schematic flowchart illustrating a method for downloading FPGA firmware and USB interface chip firmware according to an embodiment of the present invention is shown.

[0042] Figure 5 A schematic flowchart of a communication interface firmware download method according to an embodiment of the present invention is shown;

[0043] Figure 6 A schematic flowchart illustrating a method for interaction between a host and a bootloader according to an embodiment of the present invention is shown.

[0044] Figure 7 A schematic flowchart of an FPGA firmware download method according to an embodiment of the present invention is shown;

[0045] Figure 8 A schematic flowchart illustrating a method for interaction between a host and communication interface firmware according to an embodiment of the present invention is shown.

[0046] Figure 9 A schematic flowchart of a USB interface chip firmware download method according to an embodiment of the present invention is shown;

[0047] Figure 10 A schematic flowchart illustrating a method for interaction between a host and communication interface firmware according to an embodiment of the present invention is shown. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the present invention more apparent, exemplary embodiments according to the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein. Based on the embodiments of the present invention described herein, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of the present invention.

[0049] As mentioned above, in response to the problem of high firmware download costs caused by offline burning of FPGA firmware and USB interface chip firmware in the front-end board of ultrasound diagnostic equipment, this invention proposes a firmware download method that can complete online firmware download without disassembling the device or replacing the system.

[0050] According to an embodiment of the present invention, the firmware download method is applied to the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA transmits data to the host via the USB interface chip. The first memory is connected to the USB interface chip.

[0051] For example, the aforementioned ultrasound diagnostic equipment can be any type of ultrasound diagnostic equipment, such as an A-mode ultrasound diagnostic instrument, an M-mode ultrasound diagnostic instrument, a B-mode ultrasound examination instrument, or a color Doppler ultrasound, used for ultrasound imaging and diagnosis. The ultrasound diagnostic equipment can consist of components such as a host, a front-end board, an ultrasound probe, a display system, and a keyboard board. The host and the front-end board can be connected via a connection method such as a high-speed bus to achieve communication between them. The front-end board can be used to control the generation, transmission, and reception of ultrasound signals, and can also preprocess the received ultrasound signals and transmit the preprocessed ultrasound signals to the host. The host can be used to receive the ultrasound signals transmitted by the front-end board, and can amplify, filter, digitize, and reconstruct the received ultrasound signals to form two-dimensional, three-dimensional, or four-dimensional ultrasound images. The front-end board can consist of components such as a USB interface chip, a first memory, and an FPGA. The USB interface chip can be considered a microcontroller capable of encoding and decoding USB data packets, which can drive data interaction between the FPGA and the host through a matching chip firmware program, i.e., the USB interface chip firmware. FPGAs can implement complex functions such as ultrasonic control and beamforming in specified modes through matching FPGA firmware. The USB interface chip firmware and FPGA firmware can be stored in the internal memory of the USB interface chip, such as static random access memory (SRAM), or in external memory (referred to as the first memory in this document). The first memory can be connected to the USB interface chip via a target communication interface. The target communication interface can be any type of communication interface. For example, the target communication interface is a serial communication interface, which can realize data transmission between the first memory and the USB interface chip based on a preset serial communication protocol. Exemplarily, the target communication interface can be an Inter-Integrated Circuit (I2C) interface, a Serial Peripheral Interface (SPI) interface, a Universal Synchronous / Asynchronous Receiver / Transmitter (USART) interface, or a Universal Asynchronous Receiver / Transmitter (UART) interface, etc.The first memory can be, for example, Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash EEPROM Memory (FLASH), Ferroelectric Random Access Memory (FRAM), Magnetoresistive Random Access Memory (MRAM), Resistive Random Access Memory (RRAM), etc. The USB interface chip can connect to the host via a USB bus. The USB interface chip can connect to the FPGA via a specific interface. This specific interface can be, for example, a General Programmable Interface (GPIF) interface, a Direct Memory Access (DMA) interface, an SPI interface, an I2C interface, or a Peripheral Component Interconnect (PCI) interface. Interfaces such as Express and PCIe are available. The USB interface chip and the FPGA can also be connected via a custom-designed USB-FPGA bridge chip. In one specific embodiment, the USB interface chip has a GPIF interface. The FPGA and the USB interface chip can be connected via a GPIF bus adapted to the GPIF interface. When the host's data transfer target is the FPGA, the host can send data to the USB interface chip via the USB bus, and then the USB interface chip can send the received data back to the FPGA via the GPIF bus. Conversely, when the FPGA's data transfer target is the host, the FPGA can send data to the USB interface chip via the GPIF bus, and then the USB interface chip can send the received data back to the host via the USB bus.

[0052] To make it easier to understand, the following will be combined with Figure 1 An exemplary structure and communication method are described for the host and front-end board of an ultrasound diagnostic device.

[0053] Please see Figure 1The diagram illustrates the architecture of data transmission between the front-end board and the host computer of an ultrasound diagnostic device according to an embodiment of the present invention. The ultrasound diagnostic device 100 may include a host computer 110 and a front-end board 120 connected to the host computer 110. The front-end board 120 may include a USB interface chip 121, a first memory (including FLASH 123 and / or EEPROM 124), and an FPGA 122. The USB interface chip 121 is connected to the FPGA 122, the first memory, and the host computer 110, respectively. Data transmission between the FPGA 122 and the host computer 110 can be performed via the USB interface chip 121. Exemplarily, the USB interface chip 121 may include a USB device controller (UDC). Figure 1 As not shown, the host may include a host controller (UHC) 111. The USB bus 130 can connect the USB device controller and the host controller 111 respectively to enable communication between the USB interface chip and the host 110. The USB interface chip 121 may have multiple communication endpoints EP (hereinafter referred to as "EP endpoints") 1215. The USB interface chip 121 can interact with the host 110 via the EP endpoints 1215. For example, the USB device controller can be used to manage and control the EP endpoints 1215 (e.g., initialization, status monitoring, etc.) and can receive information sent by the host 110 via the EP endpoints 1215 (e.g., the communication interface firmware and target firmware described herein) and transmit the received information to corresponding components in the USB interface chip 121 (e.g., the second memory described herein). The host 110 can request configuration information from the USB interface chip 121 via the USB bus 130. The configuration information of the USB interface chip 121 may include configuration information of each EP endpoint 1215, such as the function, address, and transmission type of each EP endpoint 1215. EP endpoint 1215 can be considered a virtual channel in the USB communication protocol. Each EP endpoint 1215 is used for a specific interactive function, such as receiving information from host 110, providing a path for host 110 to read and write registers of FPGA 122, and uploading ultrasonic echo data to host 110. Among the multiple EP endpoints 1215, EP0 (also known as the "debug endpoint") is the default bidirectional communication endpoint. Host 110 can interact with USB interface chip 121 through EP0 endpoint using the control transmission method in the USB communication protocol.

[0054] The USB interface chip 121 may further include a processor 1211, a second memory 1212 connected to the processor 1211, and a shielded ROM 1213 connected to the second memory 1212. The second memory 1212 can be used to store the communication interface firmware described herein. Exemplarily, the second memory 1212 can be any type of semiconductor memory, including but not limited to various volatile memories, such as SRAM. The communication interface firmware can be used to write target firmware corresponding to the communication interface firmware into the corresponding first memory during execution. The communication interface firmware can be constructed as an image file, and the image file format can include bin format, nrg format, img format, etc. The target firmware can be, for example, USB interface chip firmware, or FPGA firmware. The shielded ROM 1213 can be used to store a bootloader, which can be used to receive data sent by the host 110 and execute instructions sent by the host 110. The data sent by the host 110 can be, for example, the communication interface firmware, the USB communication protocol, the target firmware, etc. The instructions sent by the host 110 can be, for example, instructions to instruct the bootloader to write the communication interface firmware into the second memory 1212. Figure 1 In the illustrated embodiment, the second memory 1212 may be SRAM, and the bootloader may be a boot program. Exemplarily, a GPIF controller 1214 may be provided within the USB interface chip 121. The GPIF controller 1214 may be connected to the FPGA 122 via the GPIF bus 128 for data interaction with the FPGA 122. The first memory may include a FLASH 123 and / or an EEPROM 124. Exemplarily, the FLASH 123 may be used to store FPGA firmware, and the EEPROM 124 may be used to store USB interface chip firmware. The EEPROM 124 may be connected to the USB interface chip 121 via the I2C bus 126, and the FLASH 123 may be connected to both the FPGA 122 and the USB interface chip 121 via the SPI bus 125. Exemplarily, a switch 127 may be provided between the FLASH 123 and the USB interface chip 121, and the switch 127 may be connected to the FPGA 123, the USB interface chip 121, and the FLASH 123 via the SPI bus 125. The switching switch 127 can be controlled by the host 110 to control its connection state. By setting the connection state of the switching switch 127, the connection between FLASH 123 and USB interface chip 121 and the connection between FLASH 123 and FPGA 122 can be controlled.

[0055] The USB interface chip 121 can have multiple Program Mode (PMODE) pins configured on its periphery. The host 110 can control the state of the PMODE pins by sending control signals to the USB interface chip 121. These control signals can be, for example, general-purpose input / output (GPIO) signals. Figure 1 In the illustrated embodiment, the GPIO signals may include GPIO1, GPIO2, and GPIO3. GPIO1 can be used to control the PMODE[0] pin of the USB interface chip 121 to control the boot mode of the USB interface chip 121. The default state of GPIO1 is high impedance. In this case, the USB interface chip 121 can run by loading the USB interface chip firmware in EEPROM 124 via I2C bus 126, or the FPGA 122 can run by loading the FPGA firmware in FLASH 123 via SPI bus 125. Before downloading the communication interface firmware corresponding to the target firmware to the second memory 1212 of the USB interface chip 121, the state of GPIO1 can be adjusted from high impedance to high level to control the boot mode of the USB interface chip 121 to boot via USB bus 130. GPIO2 can be used to control the reset pin (also known as the "reset pin") of the USB interface chip 121. After switching the boot mode of the USB interface chip 121, a reset operation can be performed on the USB interface chip 121 via GPIO2. GPIO3 can be used to control switch 127. GPIO3 is high by default, in which case FLASH 123 and FPGA 122 can be connected via SPI bus 125. When downloading FPGA firmware to FLASH 123, GPIO3 can be set low, in which case FLASH 123 and USB interface chip 121 can be connected via SPI bus 125. Figure 1In the illustrated embodiment, the bootloader can download the target firmware to the corresponding memory through multiple interfaces, including a USB interface, an I2C interface, and an SPI interface. For example, when the PMODE input pin of the USB interface chip 121 is set to a specific state value, and this specific state value enables the boot mode of the USB interface chip 121 to be configured to boot from USB, the bootloader can write the communication interface firmware corresponding to the FPGA firmware or the communication interface firmware corresponding to the USB interface chip firmware from the host 110 to the SRAM (i.e., the second memory 1212) of the USB interface chip 121 via the USB interface. The bootloader can also utilize the SPI interface to write the firmware that can form an FPGA into the FLASH 123 via the SPI bus 125. The bootloader can also utilize the I2C interface to write the firmware that can form a USB interface chip into the EEPROM 124 via the I2C bus 126. Those skilled in the art will understand that the control transmission method in the aforementioned USB communication protocol can be implemented by sending a specific type of device request (e.g., an 8-byte setup transaction). The USB communication protocol defines a standard USB device request, which may include a `GETDESCRIPTOR` request, such as a device descriptor, configuration descriptor, or string descriptor. These descriptors describe the purpose, configuration options, and other important information of the USB device. A standard USB device request may also include a `SETADDRESS` request, which assigns a unique USB address to the USB device to enable data communication between the host and the USB device. A standard USB device request may also include a `GET STATUS` request, which queries the status of the USB device, interface, or endpoint, such as checking for error states or readiness to receive data. It is understood that the above standard USB device requests are merely examples, and the USB standard requests are not limited to the embodiments described above. When conducting data communication with a USB device other than the standard USB device request, a custom device request can be defined within the USB device, and communication can be achieved by sending data corresponding to the device request to the USB device. In the embodiments provided in this application, the USB interface chip 121 can function as a USB device.For example, when the USB interface chip 121 is configured to boot from USB (that is, when the boot method selected by the bootloader is boot from USB), the host 110 can send a custom setup transaction to the bootloader through the EP0 endpoint. Through interaction with the bootloader, the communication interface firmware corresponding to the target firmware is downloaded to the SRAM (as the second memory 1212). The bootloader reads the downloaded communication interface firmware from the SRAM (as the second memory 1212) and moves the PC pointer (also known as the "program counter pointer") of the USB interface chip 121 to the program entry address of the communication interface firmware to start the communication interface firmware.

[0056] It should be noted that Figure 1 The various components included in the host and front-end board of the ultrasound diagnostic device shown, and the operation of each component, are merely examples and not limitations of the invention. For example, the first memory may include other types of memory besides FLASH 127 and EEPROM 128, such as FRAM. As another example, the USB interface chip firmware and FPGA firmware may both be stored in the same memory, for example, in FLASH 123.

[0057] The following is combined Figure 2 An exemplary flow describing a firmware download method according to an embodiment of the present invention is provided.

[0058] Please see Figure 2 As shown, it is a schematic flowchart of a firmware download method according to an embodiment of the present invention. Figure 2 As shown, the firmware download method may include steps S210, S220, S230, and S240.

[0059] In step S210, the boot mode of the control USB interface chip is configured to boot from USB.

[0060] For example, the boot method can be understood as the boot location from which the processor on the USB interface chip starts reading and running the program after the USB interface chip is powered on. The boot method of the USB interface chip can include: booting from SPI, booting from I2C, booting from USB, etc. In one specific embodiment, the first memory includes FLASH, which is connected to the USB interface chip via an SPI bus. When the processor on the USB interface chip needs to run a complex program, FLASH boot can be used. In this case, the boot method of the USB interface chip can be SPI boot. In another specific embodiment, the first memory includes EEPROM, which is connected to the USB interface chip via an I2C bus. When the processor on the USB interface chip does not need to run a complex program, EEPROM boot can be used. In this case, the boot method of the USB interface chip is I2C boot. It can be understood that when the USB interface chip needs to communicate with the host, host boot can be used. In this case, the boot method of the USB interface chip can be USB boot. For example, the boot mode of a USB interface chip can be configured by setting the state of its program mode pin. For instance, the program mode pin can be a PMODE pin, and the state of the PMODE pin can be the voltage level it is connected to, such as high, low, or high impedance. When the USB interface chip needs to be configured to boot from USB, the host can send a configuration control signal corresponding to booting from USB to the USB interface chip. The USB interface chip can then configure the state of its program mode pin to a specific state based on this configuration control signal, thus enabling the USB interface chip to boot from USB. This configuration control signal can be, for example, a GPIO signal.

[0061] In step S220, the communication interface firmware is downloaded from the host to the second memory in the USB interface chip via the USB bus.

[0062] For example, the USB interface chip and the host can be connected via a USB bus. The host may include a third memory, which may store the communication interface firmware. For example, the communication interface firmware stored in the host may be an image file. In a specific embodiment, the communication interface firmware is a binary image file in img format, which organizes the communication interface firmware based on logical or physical partition units. For example, on the host, business software for interacting with the front-end board may run, which may include an application layer and a kernel connected to the application layer. Please refer to [link to relevant documentation]. Figure 3 The diagram shown illustrates a communication link between a host computer and a USB interface chip according to an embodiment of the present invention. Figure 3In the illustrated embodiment, the application layer may include an ultrasound service software firmware download module. The kernel can serve as the transport layer, and may include a USB file module (Usbfs) for providing system access paths to the USB interface chip for user space, a host controller driver module (HCD) for providing a unified interface to the USB interface chip, and a USB core module connected between the host controller driver module and the USB file module. The USB core module can be used to control the drivers of the host controller driver module and the USB interface chip to achieve data transmission in the transport layer. Figure 3 In the illustrated embodiment, the ultrasound service software firmware download module can be connected to the USB file module via IOCTL (Device Control Interface Functions in Device Drivers). The host controller driver module can communicate with the USB interface chip through the EP0 endpoint of the USB interface chip. During the process of downloading the communication interface firmware from the host to the USB interface chip, the communication interface firmware can be transferred from the ultrasound service software firmware download module to the USB file module, then transferred from the USB file module to the host controller driver module via the USB core module, and finally transferred from the host controller driver module to the USB interface chip via the USB bus for storage in the second memory of the USB interface chip. The second memory can be any type of semiconductor memory, such as SRAM, Dynamic Random Access Memory (DRAM), cache memory, etc.

[0063] In step S230, the control communication interface firmware is executed on the USB interface chip.

[0064] For example, the host can interact with the USB interface chip via the USB bus. This interaction may include the host sending an execution request corresponding to the communication interface firmware to the USB interface chip. The USB interface chip can respond to the execution request and execute the communication interface firmware on the USB interface chip.

[0065] In step S240, during the execution of the communication interface firmware, the target firmware is sent to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory; wherein, the target firmware includes USB interface chip firmware and / or FPGA firmware, the USB interface chip firmware is used to drive data transmission between the FPGA and the host, and the FPGA firmware is used to drive the FPGA to work.

[0066] For example, the target firmware can be stored as chip firmware on an external storage chip, such as FLASH, EPROM, etc. It is understood that the first memory described herein can be considered as an external storage chip. During the execution of the communication interface firmware, the host can send the target firmware to the communication interface firmware in the USB interface chip via the USB bus. The communication interface firmware can then write the target firmware into the first memory. Different target firmwares can be stored in the same first memory or in different first memories. Different target firmwares can correspond to different communication interface firmwares. Specifically, the communication interface firmware can be the execution firmware for writing the target firmware. Since the USB interface chip and different first memories can be connected based on different communication protocols, when downloading the target firmware to the first memory, the host can send commands based on the communication protocol between the first memory and the USB interface chip to the communication interface firmware, causing the communication interface firmware to store the target firmware in the corresponding first memory. The communication protocol can be, for example, the I2C bus protocol, the SPI bus protocol, etc. Those skilled in the art will understand that the type of hardware connection bus between the first memory and the USB interface chip can determine the type of communication protocol, which will not be elaborated here. The primary memory can be, for example, EEPROM, FLASH, FRAM, MRAM, RRAM, etc. It is understood that FPGA firmware can be stored in various types of non-volatile memory, such as FLASH. Similarly, USB interface chip firmware can also be stored in various types of non-volatile memory, such as EEPROM.

[0067] The above technical solution allows for online firmware download via the existing communication link between the USB interface chip and the host, eliminating the need for additional auxiliary hardware. Furthermore, this solution can download the target firmware to the first memory via the communication interface firmware transmitted from the host to the USB interface chip. Therefore, this solution also eliminates the need to rely on the existing firmware state in the first memory, allowing downloading of the target firmware even when there is no existing firmware or the existing firmware is corrupted.

[0068] The above firmware download method can realize the online download of the target firmware (including USB interface chip firmware and / or FPGA firmware) required by ultrasound diagnostic equipment. This online download method helps to reduce the difficulty of disassembling and separating components required for offline burning, thus improving the firmware download efficiency and reducing the firmware download cost.

[0069] Optionally, downloading the communication interface firmware from the host to the second memory in the USB interface chip via the USB bus includes: performing a first interactive operation with the boot program in the USB interface chip via the USB bus to download the communication interface firmware from the host to the second memory. The first interactive operation includes: reading the communication interface firmware from a third memory in the host; generating firmware transmission data corresponding to the communication interface firmware, the firmware transmission data including the communication interface firmware; and sending the firmware transmission data to the boot program so that the boot program writes the firmware transmission data to the second memory. During the process of sending the firmware transmission data to the boot program, the first interactive operation further includes: receiving first feedback information sent by the boot program; and determining the writing status of the communication interface firmware based on the first feedback information.

[0070] For example, a bootloader can be built into the USB interface chip. The bootloader can be, for example, a boot loader, a Basic Input Output System (BIOS), or a Real-Time Operating System (RTOS). Taking the bootloader within the USB interface chip as an example, the bootloader can be executed when the USB interface chip is powered on or restored. It is used for basic hardware initialization and for interacting with the host to achieve data transfer. The interaction between the bootloader and the host can be implemented via the USB bus. The interaction can include a first interaction, through which the communication interface firmware can be downloaded from the host to a second memory. Specifically, the third memory within the host can store the communication interface firmware. The host can read the communication interface firmware and generate firmware transmission data including the communication interface firmware. For example, the firmware transmission data can also include a device request. The device request can be used to request the USB interface chip to send its configuration information. In one specific embodiment, the device request may be an 8-byte setup transaction. The setup transaction may include the host's request type and request data. The USB interface chip may transmit relevant configuration parameters of the USB interface chip corresponding to the received setup transaction to the host. Exemplarily, the firmware transmission data may also include additional information about the communication interface firmware, such as a signature used to verify that the communication interface firmware has not been modified during storage or updating. This signature may include a verification signature and / or a digital signature. The host may encapsulate the firmware transmission data according to the format of the USB communication protocol and send the encapsulated firmware transmission data to the bootloader. The bootloader may receive the encapsulated firmware transmission data, unpack it, and write the communication interface firmware from the firmware transmission data into the second memory within the USB interface chip. Exemplarily, the writing status of the communication interface firmware may include the writing status of each group of data of the communication interface firmware in the second memory, and / or, include the bootloader's readback results of the data written to the second memory. The bootloader may generate first feedback information based on the writing status of the communication interface firmware. For example, the first feedback information may include first sub-feedback information, which can be used to indicate whether the writing of the current set of transmitted data in the communication interface firmware is complete. The bootloader can also read back the communication interface firmware written to the second memory, and the first feedback information may further include second sub-feedback information, which may include the bootloader's readback result of the communication interface firmware in the second memory.For example, the above readback results may include the checksum, hash value, log record, status report, etc. of the communication interface firmware in the second memory read back by the bootloader.

[0071] The above technical solution enables bidirectional communication between the host and the boot program in the USB interface chip through interaction. This allows the communication interface firmware to be accurately written into the USB interface chip, and the host can obtain the writing status of the communication interface firmware in the USB interface chip, which is beneficial for the timely execution of subsequent download processes.

[0072] Optionally, the communication interface firmware includes at least one data segment, wherein sending firmware transmission data to the bootloader includes: sending each data segment of the communication interface firmware to the bootloader in multiple sessions, wherein each session of the data segment is a first data group; receiving first feedback information sent by the bootloader includes: for each first data group, receiving first sub-feedback information corresponding to the first data group sent by the bootloader, wherein the first sub-feedback information is generated by the bootloader based on the write status of the first data group, and the first feedback information includes the first sub-feedback information.

[0073] For example, the communication interface firmware can be a binary image file constructed according to a specific data structure. Before sending the firmware transmission data to the bootloader, the host can parse the communication interface firmware, and the parsed communication interface firmware can include at least one data segment. In the USB communication protocol, the endpoint descriptor of the USB interface chip can define the size of the data packet; that is, each endpoint has its Maximum Transfer Unit (MTU). For each data segment of the communication interface firmware, the size of the data segment may be larger than the MTU of the endpoint used to transmit the communication interface firmware. In this case, the host can send a data segment to the bootloader through multiple transmissions until all data segments are sent to the bootloader. In a specific embodiment, the image file of the communication interface firmware is in img format, and the communication interface firmware is organized according to data segments. In this embodiment, the communication interface firmware can include one or more data segments, and the attributes of each data segment can include length dLength and base address dAddress. Specifically, the host can send each data segment of the communication interface firmware sequentially. For each data segment sent to the bootloader, the data segment can be sent to the bootloader in multiple parts according to a preset single read / write size, such as 4KB per read / write. The size of a single read / write operation is less than or equal to the Maximum Transmission Unit (MTU) of the USB communication protocol. The data in each transmitted data segment can be recorded as a first data group. It can be understood that the size of each first data group can be equal to the preset single read / write size. After receiving a first data group, the bootloader can write the first data group to the second memory. After completing the writing of the first data group, it sends a first sub-feedback message to transmit information that the first data group has been written to the host. The data structure of this first sub-feedback message can be, for example, a handshake packet. In a specific embodiment, the host can send an OUT token packet to the bootloader. The OUT token packet can be used to specify the endpoint on the USB interface chip used for transmitting the communication interface firmware. After sending the OUT token packet, the host sends the current first data group of the current data segment and the write command for the current data segment to the bootloader. After receiving the first data group and the write command, the bootloader can write the first data group to the second memory and can send a handshake packet to the host after the writing of the first data group is complete. The type of handshake packet can include: ACK handshake packet, NAK handshake packet, or STALL handshake packet, etc.

[0074] In the above technical solution, after the host transmits the first data group of the communication interface firmware to the boot program, it can obtain the first sub-feedback information that reflects the writing status of the first data group. This helps to ensure that the host can know the writing status of the communication interface firmware in the second memory in a timely manner, and thus facilitates the host to perform subsequent operations according to the current writing status of the communication interface firmware.

[0075] Optionally, the firmware transmission data also includes a readback command, which sends the firmware transmission data to the bootloader. The process further includes: for each first data group, after receiving first sub-feedback information corresponding to that first data group sent by the bootloader, issuing a readback command to the bootloader so that the bootloader can read back the first data group in the second memory; receiving the first feedback information sent by the bootloader further includes: according to each first data group, receiving second sub-feedback information corresponding to that first data group sent by the bootloader, wherein the second sub-feedback information is generated by the bootloader based on the readback first data group, and the second sub-feedback information is used to verify whether the first data group in the second memory is correct; the first feedback information also includes the second sub-feedback information.

[0076] For example, after the host sends a first data group of the communication interface firmware to the bootloader, it can issue a readback command to the bootloader. Upon receiving the readback command, the bootloader can read back the first data group written to the second memory and generate second sub-feedback information based on the readback result. For example, the second sub-feedback information can include, but is not limited to, one or more of the following: checksum, check code, hash value, log record, status report, etc. After receiving the second sub-feedback information, the host can verify the first data group in the second memory corresponding to the second sub-feedback information based on the second sub-feedback information. Taking the second sub-feedback information as the checksum of any first data group in the second memory as an example, the host can calculate the checksum of the first data group on the host side and compare the checksum sent by the bootloader with the calculated checksum of the first data group on the host side. If the two checksums are equal, it can be determined that the first data group was written correctly to the second memory. In one specific embodiment, the first data group to be sent is denoted as the first data group A. The host can send the first data group A to the bootloader. After receiving the first data group A, the bootloader writes the first data group A into the second memory and generates first sub-feedback information based on the writing status of the first data group A, which is then sent to the host. When the first sub-feedback information indicates that the first data group A has been completely written into the second memory, the host can issue a readback command to the bootloader. After receiving the readback command, the bootloader reads back the first data group A in the second memory and generates second sub-feedback information based on the readback result, which is then sent to the host. The host verifies the first data group A in the second memory based on the second sub-feedback information. If the verification result meets the requirements, the host continues to send the next first data group B to be sent, repeating the aforementioned operation until the current data segment is sent. After the current data segment is sent, the aforementioned operation can be repeated for each first data group of the next data segment to be sent, until all data segments are written into the second memory. For example, if the first sub-feedback information indicates that the write operation is incomplete (incomplete write operations can include write errors and incomplete writes), or if the verification result obtained by the host based on the second sub-feedback information does not meet the requirements, the host can clear the communication interface firmware in the second memory through the bootloader and resend the firmware transmission data to the bootloader to rewrite the communication interface firmware into the second memory. For example, if the data in the first data group is not completely written or a write error occurs, the host can control the bootloader to clear the communication interface firmware in the second memory and control the bootloader to re-execute the operation of writing the communication interface firmware into the second memory until all the first data groups of the target firmware are correctly written into the second memory, at which point the write operation is complete. It is understood that when a write error is determined in the first data group, other corrective measures can also be taken according to the error handling logic, which will not be elaborated here.

[0077] In the above technical solution, after the host obtains the first sub-feedback information reflecting the write status of the first data group each time, it can obtain the second sub-feedback information reflecting the readback result of the first data group to verify the first data group. This allows for timely determination of whether the first data group written to the second memory is correct, which is beneficial for timely correction when problems occur during the writing of the communication interface firmware. By verifying the data already written to the second memory during the writing process of the communication interface firmware, it helps save the time spent writing the remaining data to the second memory after a write error occurs, and also helps ensure the accuracy of the communication interface firmware data written to the second memory.

[0078] Optionally, after receiving the first sub-feedback information corresponding to the most recently sent first data group, the first interactive operation further includes: determining that the writing of the communication interface firmware is complete when the amount of remaining data in the communication interface firmware that has not been sent to the USB interface chip is 0; wherein, the operation of sending the next first data group to the boot program and the operation of receiving the first sub-feedback information corresponding to the next first data group sent by the boot program are performed when the amount of remaining data is not 0, and the next first data group is the first data group sent after the most recently sent first data group.

[0079] For example, after receiving the first sub-feedback information corresponding to the most recently sent first data group, the host can determine whether the writing of the entire communication interface firmware is complete based on the amount of communication interface firmware data that has not yet been sent to the USB interface chip. Optionally, in an embodiment where the bootloader sends the second sub-feedback information to the host, the host can determine whether the writing of the entire communication interface firmware is complete based on the amount of communication interface firmware data that has not yet been sent to the USB interface chip after receiving the second sub-feedback information corresponding to the most recently sent first data group. When the amount of communication interface firmware data that has not yet been sent to the USB interface chip is 0, it can be determined that the communication interface firmware has been completely sent to the bootloader of the USB interface chip, and the host's transmission of the communication interface firmware is complete. When the amount of communication interface firmware data that has not yet been sent to the USB interface chip is not 0, the host can continue to send the next first data group to be sent to the bootloader of the USB interface chip and receive the first sub-feedback information sent by the bootloader according to the writing status of the first data group. For each first data group of each data segment, the host can execute the aforementioned process until the communication interface firmware is completely written to the second memory.

[0080] In the above technical solution, the host can monitor the amount of unsent data during data transmission and determine whether the communication interface firmware has been transmitted successfully based on the amount of unsent data. This helps to promote the autonomous advancement of subsequent operations and helps to ensure the integrity of the communication interface firmware downloaded to the USB interface chip.

[0081] Optionally, the firmware transmission data also includes a device request. Sending the firmware transmission data to the bootloader includes: sending the device request to the bootloader before sending the communication interface firmware to the bootloader; receiving configuration information of the USB interface chip sent by the bootloader in response to the device request; and sending the communication interface firmware to the bootloader based on the configuration information.

[0082] For example, the type of device request can be determined through the USB communication protocol between the host and the USB interface chip. In a specific embodiment, the device request can be an 8-byte setup transaction (also called a setup request). The setup transaction has been described in the previous scheme and will not be repeated here. After the host sends the setup transaction to the bootloader, the bootloader can send the configuration information of the USB interface chip based on the setup transaction. The configuration information may include the USB device identifier, interface number, and configuration information of each EP endpoint (e.g., the function, address, and transmission type of each EP endpoint). After obtaining the configuration information of the USB interface chip, the host can select a suitable transmission path that can transmit the communication interface firmware from the host to the USB interface chip based on the configuration information, so as to send the communication interface firmware to the bootloader through the transmission path.

[0083] The above technical solution enables the host to obtain the configuration information of the USB interface chip in advance before transmitting data and / or instructions to the USB interface chip, which helps to accurately transmit the data and / or instructions to be transmitted to the designated program.

[0084] Optionally, the communication interface firmware includes at least one data segment, wherein, before reading the communication interface firmware from the third memory within the host, the first interactive operation further includes: verifying the signature identifier of the communication interface firmware; when the signature identifier verification passes, reading the length and base address of each data segment of the communication interface firmware; reading the communication interface firmware from the third memory within the host includes: for each data segment of the communication interface firmware, reading the data segment from the third memory according to the length and base address of the data segment.

[0085] For example, the communication interface firmware can be an image file, which may include a specific signature identifier, such as a firmware digital signature, used to identify and authenticate the communication interface firmware. Before the host reads the communication interface firmware from the third memory, the host can verify the signature identifier of the communication interface firmware to be transmitted. The verification process may, for example, calculate the hash value of the communication interface firmware and design the signature identifier to obtain another hash value. If the two hash values ​​match, the signature identifier verification is considered successful. When the communication interface firmware is an image file, it can be organized and constructed according to a specific format. In a specific embodiment, the communication interface firmware is an image file in img format, organized according to data sections. The communication interface firmware may include one or more data sections, and the attributes of each data section may include a length dLength and a base address dAddress. The length dLength and base address dAddress of the data section can be stored in any memory of the host, but it is preferable to store them in the third memory. After the signature verification is successful, for each data segment, the host can read the length dLength and base address dAddress of the data segment, and then read the data segment from the third memory based on the length dLength and base address dAddress.

[0086] The above technical solution verifies the signature of the communication interface firmware to authenticate the firmware and ensure the correctness and security of the downloaded firmware. Furthermore, by individually reading each data segment of the communication interface firmware based on its length and base address, each data segment can be read quickly and accurately.

[0087] Optionally, controlling the execution of the communication interface firmware on the USB interface chip includes: sending an execution request to the bootloader in the USB interface chip, so that the bootloader controls the program counter pointer of the USB interface chip to jump to the entry address of the communication interface firmware in the second memory in response to the execution request; wherein, when the program counter pointer jumps to the entry address of the communication interface firmware in the second memory, the communication interface firmware begins to execute on the USB interface chip.

[0088] For example, the host can send an execution request to the bootloader of the USB interface chip via the USB bus based on the USB communication protocol. The execution request can be a specific control command (e.g., a jump instruction), and the specific operation indicated by the execution request can be the execution of the communication interface firmware in the second memory. When the bootloader receives the execution request from the host, it can control the program counter (also known as the "PC pointer") of the USB interface chip to jump to a specific code segment for execution, which is the entry address of the communication interface firmware in the second memory. It can be understood that when the PC pointer jumps to the corresponding entry address, the USB interface chip can execute the code logic corresponding to the communication interface firmware; that is, the communication interface firmware can begin execution on the USB interface chip. For example, the processor in the USB interface chip (e.g., ...) can... Figure 1 The processor 1211 shown executes the code logic corresponding to the communication interface firmware. The processor can be any suitable processor with instruction execution capability and / or data processing capability, such as an ARM processor.

[0089] The above technical solution enables the USB interface chip to respond to the execution request sent by the host and control the execution of the communication interface firmware within the USB interface chip, which helps to ensure the autonomous execution of the firmware download process.

[0090] Optionally, sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory includes: performing a second interactive operation with the communication interface firmware in the USB interface chip via the USB bus to download the target firmware to the first memory. The second interactive operation includes: sending the target firmware to the communication interface firmware in the USB interface chip so that the communication interface firmware can write the target firmware into the first memory; receiving second feedback information sent by the communication interface firmware, and determining the writing status of the target firmware based on the second feedback information.

[0091] For example, the first memory can be a non-volatile memory located outside the USB interface chip within the front-end board, such as FLASH or EEPROM. The number of first memories within the front-end board can be one or more. When the communication interface firmware has been downloaded to the second memory of the USB interface chip, the host can send target firmware to the communication interface firmware in the second memory. Specifically, the host can interact with the communication interface firmware in the second memory of the USB interface chip through the EP0 endpoint located on the USB interface chip. The interaction operation can include the host transmitting commands and / or data to the communication interface firmware. The command can be, for example, a write command, which instructs the communication interface firmware to write the target firmware to the first memory. Correspondingly, the data can be the target firmware to be written to the first memory, where the target firmware can be an image file. When the communication interface firmware is in execution, the communication interface firmware can receive the write command and target firmware sent by the host through the EP0 endpoint. The communication interface firmware can write the target firmware into the first memory according to the write command. More specifically, the USB interface chip can be connected to the first memory through a specific protocol bus, such as an SPI bus or an I2C bus. The communication interface firmware can use the protocol bus to write the target firmware into the first memory. After writing the target firmware into the first memory, the communication interface firmware can generate second feedback information based on the writing status of the target firmware. For example, the second feedback information may include third sub-feedback information, which can be used to indicate whether the writing of the current set of transmitted data of the target firmware is complete. The communication interface firmware can also read back the target firmware written to the first memory, and the second feedback information may further include fourth sub-feedback information, which may include the readback result of the target firmware in the first memory. For example, the readback result may include one or more of the following: checksum, hash value, log record, status report, etc., of the target firmware read back from the first memory by the communication interface firmware.

[0092] The above technical solution enables bidirectional communication between the host and the USB interface chip through the interaction between the host and the communication interface firmware in the USB interface chip. This allows the target firmware to be accurately written into the corresponding first memory, and the host can obtain the writing status of the target firmware in the first memory, which is beneficial for the timely execution of the subsequent download process.

[0093] Optionally, sending the target firmware to the communication interface firmware in the USB interface chip to write the target firmware into the first memory via the communication interface firmware includes: sending the target firmware to the communication interface firmware in multiple batches, wherein each batch of data sent by the target firmware is a second data group; for each second data group, sending a write command corresponding to the second data group to the communication interface firmware to control the communication interface firmware to write the second data group into the first memory; and receiving second feedback information sent by the communication interface firmware, including: for each second data group, receiving third sub-feedback information corresponding to the second data group sent by the communication interface firmware, wherein the third sub-feedback information is generated by the communication interface firmware according to the writing status of the second data group, and the second feedback information includes the third sub-feedback information.

[0094] For example, the host can send the target firmware to the communication interface firmware in multiple batches based on a preset single read / write volume, and each batch of data sent by the target firmware can be recorded as a second data group. The preset single read / write volume can be less than or equal to the maximum transmission unit of the endpoint of the USB interface chip used to transmit the target firmware. For each second data group, the host can send a write command to the communication interface firmware before, after, or simultaneously with sending the second data group. After receiving a second data group, the communication interface firmware can write the second data group to the first memory in response to the corresponding write command. After completing the writing of the second data group, the communication interface firmware can send a third sub-feedback message to the host to transmit information that the second data group has been written. The data structure of the third sub-feedback message can be, for example, a handshake packet. In a specific embodiment, the host can send an OUT token packet to the communication interface firmware, which can be used to specify the endpoint on the USB interface chip used to transmit the target firmware. After sending the OUT token packet, the host sends the current second data group and the write command for the current second data group to the bootloader. After receiving the second data group, the communication interface firmware writes the second data group into the first memory. After the second data group in the first memory is written, it sends a handshake packet to the host as the third sub-feedback information. The type of handshake packet may include: ACK handshake packet, NAK handshake packet, or STALL handshake packet, etc.

[0095] In the above technical solution, after the host transmits the second data group of the target firmware to the communication interface firmware, it can obtain third sub-feedback information that reflects the writing status of the second data group. This helps to ensure that the host can obtain the writing status of the target firmware in the first memory in a timely manner, and thus facilitates the host to perform subsequent operations based on the current writing status of the target firmware.

[0096] Optionally, the second interactive operation further includes: for each second data group, after receiving the third sub-feedback information corresponding to the second data group sent by the communication interface firmware, issuing a readback command to the communication interface firmware to control the communication interface firmware to read back the second data group in the first memory; receiving the second feedback information sent by the communication interface firmware further includes: for each second data group, receiving the fourth sub-feedback information corresponding to the second data group sent by the communication interface firmware, wherein the fourth sub-feedback information is generated by the communication interface firmware based on the readback second data group, and the fourth sub-feedback information is used to verify whether the second data group in the first memory is correct, and the second feedback information also includes the fourth sub-feedback information.

[0097] For example, after writing a second data group into the first memory, the communication interface firmware can also read back the second data group in the first memory and generate a fourth sub-feedback message based on the readback result, which is then sent to the host. The host can verify the second data group in the first memory based on the fourth sub-feedback message. Specifically, after the host sends a second data group of the target firmware to the communication interface firmware, it can issue a readback command to the communication interface firmware. After receiving the readback command, the communication interface firmware can read back the second data group written into the first memory and generate a fourth sub-feedback message based on the readback result. If the read second data group completely matches the original second data group, it can be determined that the second data group was correctly written to the first memory. Correspondingly, if they do not match, it can be determined that the data in the second data group is incomplete or written incorrectly. For example, in the case that the data in the second data group is incomplete or written incorrectly, the host can control the communication interface firmware to clear the target firmware already written to the first memory and re-execute the operation of writing each second data group of the target firmware into the first memory until all the second data groups of the target firmware are correctly written to the first memory, at which point the writing operation is complete. It is understandable that when a data write error is detected in the second data group, other corrective measures can be taken according to the error handling logic, which will not be elaborated here. The fourth sub-feedback information may include one or more of the following: checksum, check code, hash value, log record, status report, etc. After receiving the fourth sub-feedback information, the host can verify the second data group in the first memory according to the fourth sub-feedback information. Taking the fourth sub-feedback information as the checksum of the second data group in the first memory as an example, the host can calculate the checksum of the second data group on the host side and compare the checksum sent by the communication interface firmware with the calculated checksum of the second data group on the host side. If the values ​​of the two checksums are equal, it can be determined that the write of the second data group in the first memory is correct. In a specific embodiment, the second data group to be sent at the current time is denoted as the second data group a. The host can send the second data group a to the communication interface firmware. After receiving the second data group a, the communication interface firmware writes the second data group a into the first memory and generates a third sub-feedback information according to the write status of the second data group a and sends it to the host. When the third sub-feedback message indicates that the second data group a has been completely written to the first memory, the host can issue a readback command to the communication interface firmware. After receiving the readback command, the communication interface firmware reads back the second data group a in the first memory and generates a fourth sub-feedback message based on the readback result, which is then sent to the host. The host verifies the second data group a in the first memory based on the fourth sub-feedback message. If the verification result meets the requirements, the host continues to send the next second data group b to be sent, repeating the aforementioned operation until all second data groups of the target firmware have been sent.

[0098] In the above technical solution, after the host obtains the third sub-feedback information reflecting the write status of the second data group each time, it can obtain the fourth sub-feedback information reflecting the readback result of the second data group to verify the second data group. This allows for timely determination of whether the second data group written to the second memory is correct, which is beneficial for timely correction when there are problems with the writing of the target firmware. By verifying the data already written to the first memory during the writing process of the target firmware, it helps save the time of continuing to write the remaining data to the first memory after a write error occurs, and also helps ensure the accuracy of the target firmware data already written to the first memory.

[0099] Optionally, the first memory includes a FLASH for storing FPGA firmware, and the FLASH is connected to the USB interface chip via an SPI interface. Sending the target firmware to the communication interface firmware in the USB interface chip to write the target firmware into the first memory via the communication interface firmware further includes: for each second data group, after sending a write command corresponding to the second data group to the communication interface firmware, sending a query command to the communication interface firmware in the USB interface chip to control the communication interface firmware to query whether the SPI interface is busy; wherein, the third sub-feedback information is generated by the communication interface firmware based on the status query result of the SPI interface.

[0100] For example, the first memory may include FLASH memory, which may be equipped with an SPI interface that can be connected to one end of an SPI bus. Similarly, the USB interface chip may also be equipped with an SPI interface, and the other end of the SPI bus can be connected to the SPI interface of the USB interface chip. The USB interface chip and the FLASH memory can communicate based on the SPI protocol. FPGA firmware may be stored in the FLASH memory. When the target firmware includes FPGA firmware, the FPGA firmware can be transmitted in stages based on the maximum transmission unit (MPU) of the SPI bus, which may be, for example, 256 bytes. For example, before writing the target firmware into the FLASH memory, the host may send an erase command to the communication interface firmware. The communication interface firmware can then perform an erase operation on the FLASH memory according to the erase command to erase all historical data of the target firmware stored in the FLASH memory. For example, the host may also send a query command to the communication interface firmware in the USB interface chip. When sending any second data group to the communication interface firmware, the host can send a query command to the communication interface firmware every preset delay, such as 10ms. The query command instructs the firmware to query the status register of the USB interface chip to check the status of the SPI interface at one end of the USB interface chip. The firmware can then generate a third sub-feedback message based on the queried SPI interface status and send it to the host. Specifically, the SPI interface status can include busy and idle states. When the SPI interface is busy, it can be determined that the SPI interface is currently used for data transmission. More specifically, when the communication interface firmware receives the query command, it can check the SPI interface status by reading the status bit of the data transmission pin of the SPI controller in the FLASH memory used to receive the target firmware. If the SPI interface is busy, it can be determined that the SPI interface is transmitting the currently sent second data group. In this case, the FLASH write operation can continue until the query result shows that the SPI interface is idle, indicating that the write of the second data group is complete. This process can be repeated for each second data group of the FPGA firmware until all data of the FPGA firmware is written to the FLASH memory.

[0101] The above technical solution, by querying the status of the SPI interface, helps to accurately determine whether the SPI interface is performing data transmission operations, and thus accurately determine whether the transmission of the second data group currently being transmitted by the FPGA firmware is complete.

[0102] Optionally, the first memory includes a FLASH for storing FPGA firmware, and the front-end board also includes a switching switch for controlling the connection between the FLASH and the USB interface chip. The switching switch is connected to the FLASH and the USB interface chip respectively via an SPI interface. Before sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory, the method further includes: controlling the switching switch to connect the FLASH and the USB interface chip.

[0103] For example, when the first memory within the front-end board includes FLASH, a switch can be provided between the FLASH and the USB interface chip. This switch can be connected to both the FLASH and the USB interface chip via a protocol bus (e.g., SPI bus). The switch can be used to control the connection objects of the FLASH, which may include the FPGA and the USB interface chip within the front-end board. The host can control the connection state of the switch by sending control signals (e.g., GPIO signals) to the switch. In one specific embodiment, the host can control the connection state of the switch using a preset GPIO signal. In the default state, the preset GPIO signal is high, at which point the FLASH and FPGA are connected. Other states where the FLASH does not participate in data transmission include, for example, the FPGA running existing FPGA firmware in the FLASH. When the FPGA firmware to be written is to be written to the FLASH, the host can set the preset GPIO signal to low, at which point the FLASH can connect to the USB interface chip.

[0104] In the above technical solution, the host can control the connection object of the FLASH through a switch connected to the FLASH. Before writing the FPGA firmware into the FLASH, the connection state of the switch can be adjusted to connect the FLASH to the USB interface chip in advance, so that the communication interface firmware can successfully write the FPGA firmware into the FLASH.

[0105] Optionally, the first memory includes an EEPROM for storing the firmware of the USB interface chip, and the EEPROM is connected to the USB interface chip via an I2C interface.

[0106] For example, the first memory may include an EEPROM, which may be equipped with an I2C interface connected to one end of an I2C bus. The other end of the I2C bus may be connected to a USB interface chip, and the USB interface chip and the EEPROM may communicate based on the USB communication protocol, wherein the communication content may include data transmission. In a specific embodiment, the second memory of the USB interface chip may store communication interface firmware corresponding to the USB interface chip firmware, which can write data sent by the host from the USB interface chip into the EEPROM via the I2C bus.

[0107] The above technical solution can write the firmware of the USB interface chip into the EEPROM, so that the USB interface chip can be executed from the external memory of the USB interface chip, which helps to avoid the loss of data of the USB interface chip.

[0108] Optionally, sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory includes: after detecting that the USB interface chip has restarted, sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory; wherein the USB interface chip restarts after the communication interface firmware starts executing.

[0109] For example, after the communication interface firmware is stored in the second memory of the USB interface chip, the host can send a jump command to the USB interface chip. Upon receiving the jump command, the PC pointer of the USB interface chip can jump to the storage address of the communication interface firmware to execute the firmware in the second memory. After the communication interface firmware begins execution, the USB interface chip will undergo a "reboot" process, during which the host can detect a hot-plug event. After detecting the hot-plug event, the host can send the target firmware to the communication interface firmware in the USB interface chip via the USB bus, and the communication interface firmware in the USB interface chip will then store the target firmware in the first memory.

[0110] In the above technical solution, the host can re-enumerate the USB interface chip after the USB interface chip restarts, thereby enabling the loading of the control communication interface firmware, which helps the normal transmission of the target firmware.

[0111] Optionally, the first memory includes a first sub-memory for storing the firmware of the USB interface chip. The first sub-memory is connected to the USB interface chip via a first target communication interface. After the target firmware is sent to the communication interface firmware via the USB bus so that the communication interface firmware stores the target firmware in the first memory, the method further includes: controlling the boot mode of the USB interface chip to boot from the first target communication interface.

[0112] For example, the first memory may include a first sub-memory for storing USB interface chip firmware and / or a second sub-memory for storing FPGA firmware. For instance, when the target firmware includes USB interface chip firmware, the first memory may include a first sub-memory for storing the USB interface chip firmware. The first sub-memory can be connected to the USB interface chip via a first target communication interface, which may be, for example, an EEPROM, and the first target communication interface may be, for example, an I2C interface. After storing the USB interface chip firmware in the first sub-memory, the USB interface chip can be configured to boot from the first target communication interface under the control of the host. In one specific embodiment, the host can control the PMODE pin of the USB interface chip to adjust to a preset state value via GPIO signals. Figure 1 In the illustrated embodiment, GPIO1 and GPIO3 can be set to a floating state (neither connected to a high nor a low level), and GPIO2 can be set to a high level to configure the USB interface chip's startup mode to start from the first target communication interface. Figure 1 (Shown as "I2C interface") to start.

[0113] In the above technical solution, after the USB interface chip firmware has been downloaded to the first sub-memory, the host can adjust the boot mode of the USB interface chip, thereby enabling the ultrasound diagnostic equipment to switch from the firmware download running state to the normal operating state after the firmware loading is completed.

[0114] According to another aspect of the present invention, a firmware download method is also provided, applied to the front-end board of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a host computer. The front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host computer via a USB bus, and the FPGA and the host computer transmit data via the USB interface chip. The first memory is connected to the USB interface chip. After the host computer configures the boot mode of the USB interface chip to boot from USB, the method includes: when the boot mode of the USB interface chip is configured to boot from USB, downloading the communication interface firmware in the host computer to the second memory in the USB interface chip via the USB bus; executing the communication interface firmware on the USB interface chip under the control of the host computer; during the execution of the communication interface firmware, the communication interface firmware receives the target firmware sent by the host computer via the USB bus, and stores the target firmware in the first memory; wherein, the target firmware includes USB interface chip firmware and / or FPGA firmware, the USB interface chip firmware is used to drive data transmission between the FPGA and the host computer, and the FPGA firmware is used to drive the FPGA to work.

[0115] For example, the front-end board can interact with the host via a USB bus to download firmware. During the firmware download process, the host can send commands and data to the front-end board, receive and respond to data transmitted from the front-end board. The operations performed by the host during the firmware download process have been described in detail in the aforementioned scheme and will not be repeated here. It is understood that, correspondingly, the front-end board can receive commands and data sent by the host and can perform operations corresponding to the commands sent by the host.

[0116] The above technical solution allows for online firmware download via the existing communication link between the USB interface chip and the host, eliminating the need for additional auxiliary hardware. Furthermore, this solution can download the target firmware to the first memory via the communication interface firmware transmitted from the host to the USB interface chip. Therefore, this solution also eliminates the need to rely on the existing firmware state in the first memory, allowing downloading of the target firmware even when there is no existing firmware or the existing firmware is corrupted.

[0117] The above firmware download method can realize the online download of the target firmware (including USB interface chip firmware and / or FPGA firmware) required by ultrasound diagnostic equipment. This online download method helps to reduce the difficulty of disassembling and separating components required for offline burning, thus improving the firmware download efficiency and reducing the firmware download cost.

[0118] Optionally, the USB interface chip is equipped with a boot program that downloads the communication interface firmware from the host to the second memory in the USB interface chip via the USB bus. This includes: the boot program performing a first interactive operation with the host via the USB bus to download the communication interface firmware from the host to the second memory. The first interactive operation includes: the boot program receiving firmware transmission data corresponding to the communication interface firmware sent by the host, and the boot program writing the communication interface firmware from the firmware transmission data into the second memory. During the process of the boot program receiving the firmware transmission data corresponding to the communication interface firmware sent by the host, the first interactive operation further includes: the boot program sending first feedback information to the host, the first feedback information indicating the writing status of the communication interface firmware.

[0119] The above technical solution enables bidirectional communication between the host and the boot program in the USB interface chip through interaction. This allows the communication interface firmware to be accurately written into the USB interface chip, and the host can obtain the writing status of the communication interface firmware in the USB interface chip, which is beneficial for the timely execution of subsequent download processes.

[0120] Optionally, the communication interface firmware includes at least one data segment, and the first feedback information includes first sub-feedback information. The bootloader receives firmware transmission data corresponding to the communication interface firmware sent by the host, and writes the communication interface firmware from the firmware transmission data into a second memory. This includes: for each data segment of the communication interface firmware, the bootloader receives the data segment sent by the host in multiple sessions, wherein each received data segment is a first data group; the bootloader writes each received first data group into the second memory; and the bootloader sends first feedback information to the host, including: for each first data group, the bootloader generates first sub-feedback information corresponding to the first data group based on the writing status of the first data group, and sends the first sub-feedback information to the host, wherein the first feedback information includes the first sub-feedback information.

[0121] In the above technical solution, after the host transmits the first data group of the communication interface firmware to the boot program, it can obtain the first sub-feedback information that reflects the writing status of the first data group. This helps to ensure that the host can know the writing status of the communication interface firmware in the second memory in a timely manner, and thus facilitates the host to perform subsequent operations according to the current writing status of the communication interface firmware.

[0122] Optionally, the firmware transmission data further includes a readback command, wherein the bootloader receives firmware transmission data corresponding to the communication interface firmware sent by the host, and the bootloader writes the communication interface firmware in the firmware transmission data into the second memory. The process also includes: for each first data group, after sending the first sub-feedback information corresponding to the first data group to the host, the bootloader receives a readback command issued by the host and reads back the first data group in the second memory; the bootloader sends the first feedback information to the host. The process also includes: for each first data group, the bootloader generates second sub-feedback information corresponding to the first data group based on the read-back first data group, and sends the second sub-feedback information to the host. The second sub-feedback information is used to verify whether the first data group in the second memory is correct, and the first feedback information also includes the second sub-feedback information.

[0123] In the above technical solution, after the host obtains the first sub-feedback information reflecting the write status of the first data group each time, it can obtain the second sub-feedback information reflecting the readback result of the first data group to verify the first data group. This allows for timely determination of whether the first data group written to the second memory is correct, which is beneficial for timely correction when problems occur during the writing of the communication interface firmware. By verifying the data already written to the second memory during the writing process of the communication interface firmware, it helps save the time spent writing the remaining data to the second memory after a write error occurs, and also helps ensure the accuracy of the communication interface firmware data written to the second memory.

[0124] Optionally, the firmware transmission data also includes a device request, wherein the bootloader receives firmware transmission data corresponding to the communication interface firmware sent by the host, including: before the bootloader receives the communication interface firmware, the bootloader receives a device request sent by the host; the bootloader sends configuration information of the USB interface chip to the host in response to the device request; and the bootloader receives the communication interface firmware sent by the host based on the configuration information.

[0125] The above technical solution enables the host to obtain the configuration information of the USB interface chip in advance before transmitting data and / or instructions to the USB interface chip, which helps to accurately transmit the data and / or instructions to be transmitted to the designated program.

[0126] Optionally, the USB interface chip is equipped with a boot program that executes the communication interface firmware on the USB interface chip under the control of the host. This includes: the boot program receiving an execution request sent by the host, and the boot program controlling the program counter pointer of the USB interface chip to jump to the entry address of the communication interface firmware in the second memory in response to the execution request; wherein, when the program counter pointer jumps to the entry address of the communication interface firmware in the second memory, the communication interface firmware begins to execute on the USB interface chip.

[0127] The above technical solution enables the USB interface chip to respond to the execution request sent by the host and control the execution of the communication interface firmware within the USB interface chip, which helps to ensure the autonomous execution of the firmware download process.

[0128] Optionally, the communication interface firmware receives the target firmware sent by the host via the USB bus and stores the target firmware in the first memory, including: the communication interface firmware performs a second interactive operation with the host via the USB bus to download the target firmware to the first memory, the second interactive operation including: the communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory; the communication interface firmware generates second feedback information based on the writing status of the target firmware and sends the second feedback information to the host.

[0129] The above technical solution enables bidirectional communication between the host and the USB interface chip through the interaction between the host and the communication interface firmware in the USB interface chip. This allows the target firmware to be accurately written into the corresponding first memory, and the host can obtain the writing status of the target firmware in the first memory, which is beneficial for the timely execution of the subsequent download process.

[0130] Optionally, the communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory, including: receiving the target firmware sent by the host in batches, wherein the data received in each batch of the target firmware is a second data group; for each second data group, the communication interface firmware receives a write command sent by the host corresponding to the second data group, and writes the second data group into the first memory in response to the write command; the communication interface firmware provides second feedback information based on the write status of the target firmware and sends the second feedback information to the host, including: for each second data group, the communication interface firmware generates third sub-feedback information corresponding to the second data group based on the write status of the second data group, and sends the third sub-feedback information to the host, wherein the second feedback information includes the third sub-feedback information.

[0131] In the above technical solution, after the host transmits the second data group of the target firmware to the communication interface firmware, it can obtain third sub-feedback information that reflects the writing status of the second data group. This helps to ensure that the host can obtain the writing status of the target firmware in the first memory in a timely manner, and thus facilitates the host to perform subsequent operations based on the current writing status of the target firmware.

[0132] Optionally, the second interactive operation further includes: for each second data group, after sending the third sub-feedback information corresponding to the second data group to the host, the communication interface firmware receives a readback command issued by the host, and the communication interface firmware reads back the second data group in the first memory in response to the readback command; the communication interface firmware generates second feedback information according to the write status of the target firmware, and sends the second feedback information to the host, further including: for each second data group, the communication interface firmware generates a fourth sub-feedback information corresponding to the second data group according to the readback second data group, the fourth sub-feedback information is used to verify whether the second data group in the first memory is correct, and the second feedback information also includes the fourth sub-feedback information.

[0133] In the above technical solution, after the host obtains the third sub-feedback information reflecting the write status of the second data group each time, it can obtain the fourth sub-feedback information reflecting the readback result of the second data group to verify the second data group. This allows for timely determination of whether the second data group written to the second memory is correct, which is beneficial for timely correction when there are problems with the writing of the target firmware. By verifying the data already written to the first memory during the writing process of the target firmware, it helps save the time of continuing to write the remaining data to the first memory after a write error occurs, and also helps ensure the accuracy of the target firmware data already written to the first memory.

[0134] Optionally, the first memory includes a FLASH for storing FPGA firmware, and the FLASH is connected to the USB interface chip via an SPI interface. The communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory. The method also includes: for each second data group, after the communication interface firmware receives a write command sent by the host corresponding to the second data group, the communication interface firmware receives a query command sent by the host and queries whether the SPI interface is busy in response to the query command. The third sub-feedback information is generated by the communication interface firmware based on the status query result of the SPI interface.

[0135] The above technical solution, by querying the status of the SPI interface, helps to accurately determine whether the SPI interface is performing data transmission operations, and thus accurately determine whether the transmission of the second data group currently being transmitted by the FPGA firmware is complete.

[0136] Optionally, the first memory includes FLASH for storing FPGA firmware, and the front-end board also includes a switching switch for controlling the connection between FLASH and USB interface chip. The switching switch is connected to FLASH and USB interface chip respectively via SPI interface. Before the target firmware is stored in the first memory by the communication interface firmware, the method further includes: controlling the switching switch to connect FLASH and USB interface chip under the control of the host.

[0137] In the above technical solution, the host can control the connection object of the FLASH through a switch connected to the FLASH. Before writing the FPGA firmware into the FLASH, the connection state of the switch can be adjusted to connect the FLASH to the USB interface chip in advance, so that the communication interface firmware can successfully write the FPGA firmware into the FLASH.

[0138] Optionally, the first memory includes an EEPROM for storing the firmware of the USB interface chip, and the EEPROM is connected to the USB interface chip via an I2C interface.

[0139] The above technical solution can write the firmware of the USB interface chip into the EEPROM, so that the USB interface chip can be executed from the external memory of the USB interface chip, which helps to avoid the loss of data of the USB interface chip.

[0140] Please see Figure 4 The diagram shown is a schematic flowchart of a method for downloading FPGA firmware and USB interface chip firmware according to an embodiment of the present invention. Figure 4In the illustrated embodiment, the host sets the GPIO1 signal of the PMODE[0] pin of the USB interface chip to a high level to configure the USB interface chip's boot mode to boot from USB. The host sets the GPIO2 signal of the reset pin of the USB interface chip to a low pulse to reset the USB interface chip. The host can determine the operation to be performed based on the target firmware download object, which can be the first memory within the USB interface chip, including FLASH for storing FPGA firmware and EEPROM for storing USB interface chip firmware. Accordingly, the target firmware to be downloaded can include FPGA firmware and USB interface chip firmware. When the target firmware download object is FLASH, the host sets the GPIO3 signal of the switch to a low level to connect FLASH and USB interface chip. The switch is located between FLASH and USB interface chip and is connected to FLASH and USB interface chip respectively via the SPI bus. The host can download the FPGA firmware's communication interface firmware FW_SPI to the USB interface chip through the EP0 port and control FW_SPI execution through the EP0 port. When FW_SPI executes in the USB interface chip, the host can interact with FW_SPI through the EP0 port. The host can send the FPGA firmware image file FW to FW_SPI, which then writes the FW into the FLASH memory. After restarting the front-end board system, the FPGA on the front-end board can load and run the FPGA firmware downloaded to the FLASH. When the target firmware download object is EEPROM, the host can download the FPGA firmware's communication interface firmware FW_I2C to the USB interface chip through the EP0 port and control FW_I2C execution through the EP0 port. In this embodiment, the USB interface chip and EEPROM are connected via an I2C bus. When FW_I2C executes in the USB interface chip, the host can interact with FW_I2C through the EP0 port. The host can send the USB interface chip firmware image file FW to FW_I2C, which then writes the FW into the EEPROM via the I2C bus. After restarting the front-end board system, the USB interface chip can load and run the USB interface chip firmware that has been downloaded to the EEPROM.

[0141] Please see Figure 5 The diagram shown is a schematic flowchart of a communication interface firmware download method according to an embodiment of the present invention. In this embodiment, the host can set the PMODE[0] pin of the USB interface chip to a high level through the GPIO1 signal, so as to set the boot mode of the USB interface chip to boot from USB, that is, the USB interface chip ( Figure 5The USB interface chip (shown as "USB PHY") boots from the host's USB port. The host sets the GPIO2 signal, used to control the USB interface chip, to a low pulse to reset the USB interface chip. The host then resets the USB interface chip via the EP0 endpoint (set within the USB interface chip). Figure 5 The USB interface chip (represented as "Usb EP0") interacts with the bootloader to download the communication interface firmware (FW) into the secondary SRAM (also called "RAM") within the USB interface chip. After the firmware is downloaded to the SRAM, the host, through interaction with the bootloader, controls the PC pointer of the USB interface chip to jump to the entry address of the firmware, thus executing the firmware. Upon starting the execution of the firmware, the USB interface chip performs a reboot, which allows the host to detect hot-plug events on the USB interface chip.

[0142] Please see Figure 6The diagram illustrates a schematic flowchart of a host-bootloader interaction method according to an embodiment of the present invention. Exemplarily, the communication interface firmware to be downloaded to the USB interface chip can be an image file in img format. When the host opens the communication interface firmware, it can verify the signature identifier of the firmware. It should be noted that opening the communication interface firmware does not cause the firmware to run. The communication interface firmware may include at least one data section. If the signature identifier verification is successful, the host can sequentially download each data section of the communication interface firmware to the second memory (SRAM) within the USB interface chip via the bootloader. For the currently downloaded data section, the host can read the length and base address of the data section. Under the constraint of 4KB per read / write operation, the host sends the data section to the bootloader in stages based on the length and base address, and records each data section sent as a first data group. After receiving a first data group C, the bootloader writes the first data group C into the second memory (SRAM). The bootloader generates first sub-feedback information based on the writing progress of the first data group C and sends it to the host. After receiving the first sub-feedback information, when the first sub-feedback information indicates that the writing of the first data group C is complete, the host issues a readback command to the bootloader. The bootloader reads back the data in the SRAM within a 4KB read / write constraint and generates a second sub-feedback information based on the readback result, which is then sent to the host. The second sub-feedback information can be, for example, the checksum dCheckSum of the first data group C in the SRAM. The host verifies the correctness of the first data group C in the SRAM using the second sub-feedback information transmitted by the bootloader. Specifically, the host can compare the checksum CheckSum of the first data group C on the host side with the checksum dCheckSum sent by the bootloader. If the two checksums are equal, it can be determined that the writing of the first data group C in the SRAM is correct. When the verification result indicates that the first data group C in the SRAM is written correctly, the host obtains the remaining data amount of the currently unsent communication interface firmware to determine whether the writing of the communication interface firmware is complete. When the remaining data amount of the currently unsent communication interface firmware is not 0, the next first data group D to be sent is sent to the bootloader, and the host receives the first sub-feedback information sent by the bootloader. Repeat the above operations until all data segments of the communication interface firmware have been written.

[0143] Please see Figure 7 The diagram shown is a schematic flowchart of an FPGA firmware download method according to an embodiment of the present invention. Figure 7 In the illustrated embodiment, the USB interface chip (Figure 7 The first memory (shown as "USB PHY") includes FLASH, and the FPGA firmware to be downloaded is downloaded to the FLASH. After setting the boot mode of the USB interface chip to boot from USB and downloading the communication interface firmware corresponding to the FPGA firmware to the second memory SRAM of the USB interface chip, the host controls the PC pointer of the USB interface chip to jump to the entry address of the communication interface firmware. The host uses the EP0 endpoint (set in the USB interface chip) Figure 7 The interface (shown as "Usb EP0") interacts with the communication interface firmware in the USB interface chip and sends FPGA firmware and write commands to the communication interface firmware via the SPI bus. In response to the write commands, the communication interface firmware writes the FPGA firmware to the FLASH via the SPI bus.

[0144] Please see Figure 8 The diagram shown is a schematic flowchart illustrating a method for interaction between a host and communication interface firmware according to an embodiment of the present invention. Figure 8In the illustrated embodiment, the first memory of the USB interface chip includes FLASH, and the target of the FPGA firmware to be downloaded is the FLASH. Before the communication interface firmware writes the FPGA firmware into the FLASH, the host can interact with the communication interface firmware corresponding to the FPGA firmware through the EP0 endpoint on the USB interface chip, issuing an erase command to the communication interface firmware. The communication interface firmware then erases all historical data of the target firmware in the FLASH according to the erase command. In this embodiment, the FLASH includes 8 sectors, each sector being 256*256B in size. The communication interface firmware writes the FPGA firmware into the FLASH in multiple reads and writes within a 256B read / write limit. For each transmitted FPGA firmware data, the transmitted FPGA firmware data can be recorded as a second data group; each second data group is 256B in size. The FLASH and the USB interface chip communicate via an SPI interface. After the host issues a second data group E and a write command corresponding to the second data group E to the communication interface firmware, a query command can be issued to the communication interface firmware after 10ms. The communication interface firmware writes the second data group E into the FLASH memory according to the write command, and queries the SPI interface status according to the query command issued by the host to generate a third sub-feedback message, which is then sent to the host. The host can determine whether the writing of the second data group E is complete based on the third sub-feedback message. If the SPI interface is busy, the host can delay for 10ms and then issue the query command again to control the communication interface firmware to query the SPI interface status. If the SPI interface is not busy (i.e., it is idle), the communication interface firmware generates a third sub-feedback message based on the writing status of the second data group E in the FLASH memory and sends it to the host. After receiving the third sub-feedback message, when the third sub-feedback message indicates that the writing of the second data group E is complete, the host issues a readback command to the communication interface firmware. After receiving the readback command, the communication interface firmware reads back the second data group E in the FLASH memory and generates a fourth sub-feedback message based on the readback result, which is then sent to the host. The host verifies the second data group E in the FLASH memory based on the fourth sub-feedback message. If the verification result meets the requirements, and there are still other second data groups on the host side that have not been sent to the communication interface firmware, the next second data group F to be sent and the write command corresponding to the second data group F are sent to the communication interface firmware. The above operation is repeated until all FPGA firmware is written to FLASH.

[0145] Please see Figure 9 The diagram shown is a schematic flowchart of a USB interface chip firmware download method according to an embodiment of the present invention. Figure 9 In the illustrated embodiment, the USB interface chip ( Figure 9The first memory (shown as "USB PHY") includes an EEPROM, and the USB interface chip firmware to be downloaded is downloaded to the EEPROM. After setting the USB interface chip's boot mode to boot from USB and downloading the communication interface firmware corresponding to the USB interface chip firmware to the second memory (SRAM) of the USB interface chip, the host controls the PC pointer of the USB interface chip to jump to the entry address of the communication interface firmware. The host uses the EP0 endpoint (set within the USB interface chip) Figure 9 The interface (shown as "Usb EP0") interacts with the communication interface firmware in the USB interface chip, sending a write command to the communication interface firmware to write the USB interface chip firmware to the EEPROM, and the USB interface chip firmware responds to the write command by writing the USB interface chip firmware to the EEPROM. After the USB interface chip firmware is fully written to the EEPROM, the USB interface chip can be set to boot from the EEPROM.

[0146] Please see Figure 10 The diagram shown is a schematic flowchart illustrating a method for interaction between a host and communication interface firmware according to an embodiment of the present invention. Figure 10In the illustrated embodiment, the first memory of the USB interface chip includes an EEPROM, and the USB interface chip firmware to be downloaded is downloaded to the EEPROM. Before the communication interface firmware writes the USB interface chip firmware into the EEPROM, the host can interact with the communication interface firmware on the USB interface chip through the EP0 endpoint on the USB interface chip and issue commands to the communication interface firmware. The communication interface firmware writes the USB interface chip firmware into the EEPROM in multiple batches within the constraint of 4KB per read / write operation. For each batch of USB interface chip firmware data sent, the data of that batch of USB interface chip firmware can be recorded as the third data group. It can be understood that the size of each third data group is 4KB. The EEPROM communicates with the USB interface communication chip via an I2C interface. After the host issues a certain third data group K and a write command to the communication interface firmware, the communication interface firmware responds to the write command by writing the third data group K into the EEPROM and generates third sub-feedback information based on the writing status of the third data group and sends it to the host. After receiving the third sub-feedback information, when the third sub-feedback information indicates that the writing of the third data group K is complete, the host issues a readback command to the communication interface firmware. After receiving the readback command, the communication interface firmware reads back the third data group K in the EEPROM and generates a fourth sub-feedback message based on the readback result, which is then sent to the host. The host verifies the third data group K in the EEPROM based on the fourth sub-feedback message. If the verification result meets the requirements, and if there are other third data groups on the host that have not yet been sent to the communication interface firmware, the host sends the next third data group L to be sent and the write command for third data group L to the communication interface firmware, repeating the above operation until the USB interface chip firmware is completely written to the EEPROM.

[0147] According to another aspect of the present invention, a host computer is also provided, which is applied to an ultrasound diagnostic device. The ultrasound diagnostic device includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The host computer is used to connect to the USB interface chip via a USB bus. The host computer is also used to transmit data with the FPGA via the USB interface chip. The first memory is connected to the USB interface chip. The host computer is used to execute the above-described firmware download method.

[0148] For example, the host may include a kernel and an application layer connected to the kernel. The application layer may include a firmware download module. The kernel may include a host controller driver module for providing a unified interface for the USB interface chip, a USB file module for providing system access paths for the USB interface chip to user space, and a USB core module connected between the host controller driver module and the USB file module. The USB core module can be used to control the drivers of the host controller driver module and the USB interface chip. The USB file module and the firmware download module can be connected based on IOCTL. Specifically, IOCTL is an interface function provided by the kernel to user space programs for performing device-specific input / output control operations. This function allows user space applications to send commands, transmit parameters, and receive return results to the device driver of the host controller driver module in kernel space, thereby controlling or querying the status of the USB device (USB interface chip). IOCTL commands are typically used to perform device-specific functions beyond standard read / write operations, such as configuring hardware parameters and obtaining configuration information for the USB interface chip.

[0149] According to another aspect of the present invention, a front-end board is also provided, which is applied to an ultrasound diagnostic device. The ultrasound diagnostic device includes a host, and the front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is used to connect to the host via a USB bus, the FPGA is used to transmit data with the host via the USB interface chip, the first memory is connected to the USB interface chip, and the front-end board is used to execute the above-described firmware download method.

[0150] For example, the first memory can be connected to the USB interface chip via a target communication interface. The target communication interface can be located on the first memory, and the first memory can be connected to the USB interface chip via a protocol bus corresponding to the protocol of the target communication interface. Specifically, one end of the protocol bus corresponding to the protocol of the target communication interface can be connected to the USB interface chip, and the other end can be connected to the target communication interface of the first memory. The target communication interface can be, for example, an SPI interface, an I2C interface, etc. The protocol bus can be, for example, an SPI bus corresponding to an SPI interface, an I2C bus corresponding to an I2C interface, etc. The USB interface chip can have a shielded ROM for storing a bootloader. The shielded ROM can be connected to the host via the USB bus to enable interaction between the bootloader and the host. The bootloader can include a bootloader. The USB interface chip can also include a second memory, which can be connected to the shielded ROM. The second memory can be used to store communication interface firmware. During execution, the communication interface firmware can be used to store the target firmware corresponding to the communication interface firmware into the first memory. The first memory can include FLASH, which can be connected to the USB interface chip via an SPI interface. The target communication interface can include an SPI interface. The first memory may also include an EEPROM, which can be connected to the USB interface chip via an I2C interface. The target communication interface may also include an I2C interface.

[0151] According to another aspect of the present invention, an ultrasound diagnostic device is also provided, including a host and a front-end board. The front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA and the host transmit data through the USB interface chip. The first memory is connected to the USB interface chip. The host is used to execute the firmware download method described above, and the front-end board is used to execute the firmware download method described above.

[0152] According to another aspect of the present invention, a firmware download device is also provided, applied to the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA and the host transmit data via the USB interface chip. The first memory is connected to the USB interface chip via a target communication interface. The device includes:

[0153] The first control module is used to configure the boot mode of the USB interface chip to boot from USB.

[0154] The first storage module is used to download the communication interface firmware from the host to the second memory in the USB interface chip via the USB bus.

[0155] The second control module is used to control the execution of the communication interface firmware on the USB interface chip.

[0156] The second storage module is used to send the target firmware to the communication interface firmware via the USB bus during the execution of the communication interface firmware so that the communication interface firmware can store the target firmware in the first memory.

[0157] The target firmware includes USB interface chip firmware and / or FPGA firmware. The USB interface chip firmware is used to drive data transmission between the FPGA and the host, and the FPGA firmware is used to drive the FPGA to work.

[0158] According to another aspect of the present invention, a storage medium is also provided for use in the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA and the host transmit data via the USB interface chip. The first memory is connected to the USB interface chip. Program instructions are stored on the storage medium. When the program instructions are executed by a computer or processor, the computer or processor performs the corresponding steps of the firmware download method described in the embodiments of the present invention, and is used to implement the corresponding module in the firmware download device described in the embodiments of the present invention or the corresponding module in the firmware download device described above. The storage medium may include, for example, a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable compact disc read-only memory (CD-ROM), a USB memory, or any combination of the above storage media. A computer-readable storage medium may be any combination of one or more computer-readable storage media.

[0159] According to another aspect of the present invention, a computer program product is also provided, which is applied to the host of an ultrasound diagnostic device. The ultrasound diagnostic device further includes a front-end board, which includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host via a USB bus, and the FPGA transmits data to the host via the USB interface chip. The first memory is connected to the USB interface chip. The computer program product includes computer program instructions, which are used to execute the firmware download method described above when running.

[0160] Those skilled in the art can understand the specific implementation and beneficial effects of the above-described firmware download method by reading the detailed description above. For the sake of brevity, they will not be described in detail here.

[0161] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of the invention. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention. All such changes and modifications are intended to be included within the scope of the invention as claimed in the appended claims.

[0162] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0163] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0164] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0165] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of the invention. However, this approach should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with fewer features than all of those in a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0166] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or apparatus so disclosed can be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0167] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0168] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules in the firmware download apparatus according to embodiments of the present invention. The present invention can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing some or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can take the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0169] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0170] The above are merely specific embodiments or descriptions of the present invention, and the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A firmware download method, characterized in that, A host computer for use in ultrasound diagnostic equipment, the ultrasound diagnostic equipment further comprising a front-end board, the front-end board comprising: a USB interface chip, a first memory, and an FPGA, the USB interface chip being connected to the host computer via a USB bus, the FPGA and the host computer transmitting data via the USB interface chip, the first memory being connected to the USB interface chip, the method comprising: The boot mode of the USB interface chip is configured to boot from USB; The communication interface firmware is downloaded from the host to the second memory in the USB interface chip via the USB bus. The communication interface firmware is executed on the USB interface chip. During the execution of the communication interface firmware, the target firmware is sent to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory. The target firmware includes USB interface chip firmware and / or FPGA firmware. The USB interface chip firmware is used to drive data transmission between the FPGA and the host, and the FPGA firmware is used to drive the FPGA to work.

2. The method according to claim 1, characterized in that, The step of downloading the communication interface firmware from the host to the second memory in the USB interface chip via the USB bus includes: A first interaction operation is performed between the USB bus and the boot program in the USB interface chip to download the communication interface firmware from the host to the second memory. The first interaction operation includes: Read the communication interface firmware from the third memory within the host computer; Generate firmware transmission data corresponding to the communication interface firmware, wherein the firmware transmission data includes the communication interface firmware; The firmware transmission data is sent to the bootloader, so that the bootloader can write the communication interface firmware in the firmware transmission data into the second memory; In the process of sending the firmware transmission data to the bootloader, the first interactive operation further includes: receiving first feedback information sent by the bootloader; and determining the writing status of the communication interface firmware based on the first feedback information.

3. The method according to claim 2, characterized in that, The communication interface firmware includes at least one data segment, wherein, Sending the firmware transmission data to the bootloader includes: For each data segment of the communication interface firmware, the data segment is sent to the bootloader in multiple batches, wherein each batch of data sent is a first data group; The receipt of the first feedback information sent by the bootstrap program includes: For each of the first data groups, a first sub-feedback information corresponding to the first data group is received by the bootstrap program. The first sub-feedback information is generated by the bootstrap program based on the writing status of the first data group, and the first feedback information includes the first sub-feedback information.

4. The method according to claim 3, characterized in that, The firmware data transmission also includes readback commands. The step of sending the firmware transmission data to the bootloader further includes: For each of the first data groups, after receiving the first sub-feedback information corresponding to the first data group sent by the bootstrap program, a readback command is issued to the bootstrap program so that the bootstrap program can read back the first data group in the second memory; The step of receiving the first feedback information sent by the bootstrap program further includes: For each of the first data groups, a second sub-feedback information corresponding to the first data group is received by the bootstrap program. The second sub-feedback information is generated by the bootstrap program based on the first data group being read back. The second sub-feedback information is used to verify whether the first data group in the second memory is correct. The first feedback information also includes the second sub-feedback information.

5. The method according to claim 2, characterized in that, The firmware transmission data also includes a device request, and sending the firmware transmission data to the bootloader includes: Before sending the communication interface firmware to the bootloader, the device request is sent to the bootloader; Receive the configuration information of the USB interface chip sent by the bootloader in response to the device request; Based on the configuration information, the communication interface firmware is sent to the bootloader.

6. The method according to claim 2, characterized in that, The communication interface firmware includes at least one data segment, wherein, Before reading the communication interface firmware from the third memory within the host, the first interaction operation further includes: Verify the signature identifier of the communication interface firmware; When the signature verification passes, for each data segment of the communication interface firmware, the length and base address of that data segment are read. The step of reading the communication interface firmware from the third memory within the host includes: For each data segment of the communication interface firmware, the data segment is read from the third memory according to the length and base address of the data segment.

7. The method according to any one of claims 1-6, characterized in that, The step of sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory includes: A second interactive operation is performed between the USB bus and the communication interface firmware in the USB interface chip to download the target firmware to the first memory. The second interactive operation includes: The target firmware is sent to the communication interface firmware in the USB interface chip so that the target firmware is written into the first memory through the communication interface firmware; Receive the second feedback information sent by the communication interface firmware; The writing status of the target firmware is determined based on the second feedback information.

8. The method according to claim 7, characterized in that, The step of sending the target firmware to the communication interface firmware in the USB interface chip, so as to write the target firmware into the first memory through the communication interface firmware, includes: The target firmware is sent to the communication interface firmware in multiple batches, wherein each batch of data sent by the target firmware is a second data group; For each second data group, a write command corresponding to that second data group is sent to the communication interface firmware to control the communication interface firmware to write the second data group into the first memory; The receipt of the second feedback information sent by the communication interface firmware includes: For each of the second data groups, a third sub-feedback information corresponding to the second data group is received from the communication interface firmware. The third sub-feedback information is generated by the communication interface firmware based on the writing status of the second data group, and the second feedback information includes the third sub-feedback information.

9. The method according to claim 8, characterized in that, The second interactive operation also includes: For each of the second data groups, after receiving the third sub-feedback information corresponding to the second data group sent by the communication interface firmware, a readback command is sent to the communication interface firmware to control the communication interface firmware to read back the second data group in the first memory. The receiving of the second feedback information sent by the communication interface firmware further includes: For each of the second data groups, a fourth sub-feedback information corresponding to the second data group is received from the communication interface firmware. The fourth sub-feedback information is generated by the communication interface firmware based on the second data group read back. The fourth sub-feedback information is used to verify whether the second data group in the first memory is correct. The second feedback information also includes the fourth sub-feedback information.

10. The method according to claim 8, characterized in that, The first memory includes a FLASH for storing the FPGA firmware, and the FLASH is connected to the USB interface chip via an SPI interface; The step of sending the target firmware to the communication interface firmware in the USB interface chip, so as to write the target firmware into the first memory through the communication interface firmware, further includes: For each of the second data groups, after the write command corresponding to the second data group is sent to the communication interface firmware, a query command is sent to the communication interface firmware in the USB interface chip to control the communication interface firmware to query whether the SPI interface is in a busy state. The third sub-feedback information is generated by the communication interface firmware based on the status query result of the SPI interface.

11. The method according to any one of claims 1-6, characterized in that, The first memory includes a FLASH for storing the FPGA firmware, and the front-end board also includes a switching switch for controlling the connection between the FLASH and the USB interface chip. The switching switch is connected to the FLASH and the USB interface chip respectively via an SPI interface. Before sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory, the method further includes: The switch is controlled to connect the FLASH to the USB interface chip.

12. The method according to any one of claims 1-6, characterized in that, The step of sending the target firmware to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory includes: After the USB interface chip is detected to have restarted, the target firmware is sent to the communication interface firmware via the USB bus so that the communication interface firmware can store the target firmware in the first memory. The USB interface chip restarts after the communication interface firmware begins execution.

13. A firmware download method, characterized in that, A front-end board for use in ultrasound diagnostic equipment, the ultrasound diagnostic equipment also including a host, the front-end board including: a USB interface chip, a first memory and an FPGA, the USB interface chip being connected to the host via a USB bus, the FPGA and the host transmitting data via the USB interface chip, the first memory being connected to the USB interface chip, the method including: When the boot mode of the USB interface chip is configured to boot from USB, the communication interface firmware in the host is downloaded to the second memory in the USB interface chip via the USB bus; The communication interface firmware is executed on the USB interface chip under the control of the host. During the execution of the communication interface firmware, the communication interface firmware receives the target firmware sent by the host through the USB bus, and stores the target firmware in the first memory. The target firmware includes USB interface chip firmware and / or FPGA firmware. The USB interface chip firmware is used to drive data transmission between the FPGA and the host, and the FPGA firmware is used to drive the FPGA to work.

14. The method according to claim 13, characterized in that, The USB interface chip is equipped with a boot program. The step of downloading the communication interface firmware from the host to the second memory in the USB interface chip via the USB bus includes: The bootloader performs a first interaction operation with the host via the USB bus to download the communication interface firmware from the host to the second storage. The first interaction operation includes: The bootloader receives firmware transmission data corresponding to the communication interface firmware sent by the host, and the bootloader writes the communication interface firmware in the firmware transmission data into the second memory. In the process of the bootstrap receiving firmware transmission data corresponding to the communication interface firmware sent by the host, the first interaction operation further includes: the bootstrap sending first feedback information to the host, the first feedback information being used to indicate the writing status of the communication interface firmware.

15. The method according to claim 14, characterized in that, The communication interface firmware includes at least one data segment, and the first feedback information includes first sub-feedback information, wherein... The step of receiving firmware transmission data corresponding to the communication interface firmware sent by the host from the bootloader, and writing the communication interface firmware from the firmware transmission data into the second memory by the bootloader, includes: For each data segment of the communication interface firmware, the bootloader receives the data segment sent by the host in batches, wherein the data received each time for the data segment is the first data group; The bootloader writes each of the received first data groups into the second memory; the bootloader sending first feedback information to the host includes: For each of the first data groups, the bootloader generates the first sub-feedback information corresponding to the first data group based on the write status of the first data group, and sends the first sub-feedback information to the host. The first feedback information includes the first sub-feedback information.

16. The method according to claim 15, characterized in that, The firmware data transmission also includes readback commands. The step of receiving firmware transmission data corresponding to the communication interface firmware sent by the host from the bootloader, and writing the communication interface firmware from the firmware transmission data into the second memory by the bootloader, further includes: For each of the first data groups, after sending the first sub-feedback information corresponding to that first data group to the host, the bootstrap program receives the readback command issued by the host, and the bootstrap program reads back the first data group in the second memory; the step of the bootstrap program sending the first feedback information to the host further includes: For each of the first data groups, the bootloader generates a second sub-feedback information corresponding to the first data group based on the read-back first data group, and sends the second sub-feedback information to the host. The second sub-feedback information is used to verify whether the first data group in the second memory is correct, and the first feedback information also includes the second sub-feedback information.

17. The method according to claim 14, characterized in that, The firmware transmission data also includes a device request, wherein the firmware transmission data corresponding to the communication interface firmware sent by the host and received by the bootloader includes: Before the bootloader receives the communication interface firmware, the bootloader receives the device request sent by the host; The bootloader responds to the device's request by sending the configuration information of the USB interface chip to the host; The bootloader receives the communication interface firmware sent by the host based on the configuration information.

18. The method according to any one of claims 13-17, characterized in that, The USB interface chip is equipped with a boot program, and the execution of the communication interface firmware on the USB interface chip under the control of the host includes: The bootloader receives the execution request sent by the host, and in response to the execution request, controls the program counter pointer of the USB interface chip to jump to the entry address of the communication interface firmware in the second memory; Specifically, when the program counter pointer jumps to the entry address of the communication interface firmware in the second memory, the communication interface firmware begins to execute on the USB interface chip.

19. The method according to any one of claims 13-17, characterized in that, The step of receiving the target firmware sent by the host through the USB bus by the communication interface firmware and storing the target firmware in the first memory by the communication interface firmware includes: The communication interface firmware performs a second interaction operation with the host via the USB bus to download the target firmware to the first memory. The second interaction operation includes: The communication interface firmware receives the target firmware sent by the host and writes the target firmware into the first memory. The communication interface firmware generates second feedback information based on the writing status of the target firmware, and sends the second feedback information to the host.

20. The method according to claim 19, characterized in that, The step of receiving the target firmware from the host via the communication interface firmware and writing the target firmware into the first memory via the communication interface firmware includes: The target firmware is received in multiple batches by the host, wherein each batch of data received by the target firmware is a second data group. For each of the second data groups, the communication interface firmware receives a write command corresponding to the second data group issued by the host, and writes the second data group into the first memory in response to the write command; The step of generating second feedback information by the communication interface firmware based on the write status of the target firmware and sending the second feedback information to the host includes: For each of the second data groups, the communication interface firmware generates a third sub-feedback information corresponding to the second data group based on the writing status of the second data group, and sends the third sub-feedback information to the host. The second feedback information includes the third sub-feedback information.

21. The method according to claim 20, characterized in that, The second interactive operation also includes: For each of the second data groups, after sending the third sub-feedback information corresponding to the second data group to the host, the communication interface firmware receives the readback command issued by the host, and the communication interface firmware responds to the readback command to read back the second data group in the first memory; The step of generating second feedback information by the communication interface firmware based on the writing status of the target firmware and sending the second feedback information to the host further includes: For each of the second data groups, the communication interface firmware generates a fourth sub-feedback information corresponding to the second data group based on the read-back second data group. The fourth sub-feedback information is used to verify whether the second data group in the first memory is correct. The second feedback information also includes the fourth sub-feedback information.

22. The method according to claim 20, characterized in that, The first memory includes a FLASH for storing the FPGA firmware, and the FLASH is connected to the USB interface chip via an SPI interface; The step of receiving the target firmware from the host by the communication interface firmware and writing the target firmware into the first memory by the communication interface firmware further includes: For each of the second data groups, after the communication interface firmware receives the write command corresponding to the second data group issued by the host, the communication interface firmware receives the query command issued by the host, and the communication interface firmware responds to the query command to query whether the SPI interface is in a busy state. The third sub-feedback information is generated by the communication interface firmware based on the status query result of the SPI interface.

23. The method according to any one of claims 13-17, characterized in that, The first memory includes a FLASH for storing the FPGA firmware, and the front-end board also includes a switching switch for controlling the connection between the FLASH and the USB interface chip. The switching switch is connected to the FLASH and the USB interface chip respectively via an SPI interface. Before the target firmware is stored in the first memory by the communication interface firmware, the method further includes: Under the control of the host, the switching switch is controlled to connect the FLASH and the USB interface chip.

24. The method according to any one of claims 13-17, characterized in that, The first memory includes an EEPROM for storing the firmware of the USB interface chip, and the EEPROM is connected to the USB interface chip via an I2C interface.

25. A host computer, characterized in that, This invention relates to an ultrasound diagnostic device, which includes a front-end board comprising a USB interface chip, a first memory, and an FPGA. A host computer is configured to connect to the USB interface chip via a USB bus. The host computer is also configured to transmit data with the FPGA via the USB interface chip. The first memory is connected to the USB interface chip. The host is used to perform the firmware download method as described in any one of claims 1-12.

26. A front-end board, characterized in that, This invention relates to an ultrasound diagnostic device, which includes a host computer. The front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is used to connect to the host computer via a USB bus. The FPGA is used to transmit data between the FPGA and the host computer via the USB interface chip. The first memory is connected to the USB interface chip. The front-end board is used to perform the firmware download method as described in any one of claims 13-24.

27. An ultrasound diagnostic device, characterized in that, Including the main unit and front-end board, The front-end board includes a USB interface chip, a first memory, and an FPGA. The USB interface chip is connected to the host computer via a USB bus. The FPGA and the host computer transmit data through the USB interface chip. The first memory is connected to the USB interface chip. The host is used to perform the firmware download method as described in any one of claims 1-12; The front-end board is used to perform the firmware download method as described in any one of claims 13-24.

28. A storage medium, characterized in that, A host computer for use in ultrasound diagnostic equipment, the ultrasound diagnostic equipment further includes a front-end board, the front-end board including: a USB interface chip, a first memory, and an FPGA, the USB interface chip being connected to the host computer via a USB bus, the FPGA transmitting data with the host computer via the USB interface chip, and the first memory being connected to the USB interface chip. The storage medium stores program instructions that, when executed, perform the firmware download method as described in any one of claims 1-12.

29. A computer program product, characterized in that, A host computer for use in ultrasound diagnostic equipment, the ultrasound diagnostic equipment further includes a front-end board, the front-end board including: a USB interface chip, a first memory, and an FPGA, the USB interface chip being connected to the host computer via a USB bus, the FPGA transmitting data with the host computer via the USB interface chip, and the first memory being connected to the USB interface chip. The computer program product includes computer program instructions that, when executed, perform the firmware download method as described in any one of claims 1-12.

Images