TWI793774B - Method and apparatus and computer program product for debugging solid state disk devices - Google Patents

Abstract

The invention relates to a method for debugging solid state disk (SSD) devices, which is performed by a processing unit of a raspberry Pi. The method includes: emulating a first Joint Test Action Group (JTAG) command to an SSD device through a General-Purpose Input/Output (GPIO) interface to stop running by a processing unit of a flash controller of the SSD device; emulating a second JTAG command to the SSD device through the GPIO interface to force the SSD device to exit a sleep mode; and emulating a third JTAG command to the SSD device through the GPIO interface to read a designated length of data from a designated address of a static random access memory (SRAM) of the SSD device. By executing the debugging method with the GPIO interface in the raspberry Pi as described above, it would be more flexible than the in-circuit emulator (ICE) to solve problems encountered during debugging.

Description

Debugging method and device of solid-state hard disk device and computer program product

The invention relates to a storage device, in particular to a debugging method and device for a solid-state hard disk device and a computer program product.

At present, using a commercially available in-circuit emulator (ICE) to collect the firmware status of a solid state disk (SSD) during operation will encounter the following problem: the in-circuit emulator cannot be accessed Control to meet all application environments, for example, when the in-circuit emulator stops, it will perform some fixed operations, such as stopping the central processing unit in the solid-state hard disk product, so that the host cannot continue to access the solid-state hard disk information in the product. The current in-circuit emulator needs to change the address to read the hardware register, for example, when the engineer wants to access the hardware register to know the state of the NAND flash memory when the firmware is stuck, the response speed is very slow. In addition, in-circuit emulators are very expensive, and debugging costs need to be further reduced. Therefore, the present invention proposes a debugging method, device and computer program product of a solid-state hard disk device to solve the above-mentioned problems.

In view of this, how to alleviate or eliminate the deficiencies in the above-mentioned related fields is a problem to be solved.

This specification relates to an embodiment of a debugging method for a solid-state hard disk, which is executed by the processing unit of the Raspberry Pi. The method includes: simulating the first joint test working group command to the solid-state hard disk device through the general input and output interface, and is used to stop the flash controller in the solid-state hard disk device the operation of the processing unit of the controller; simulate the second joint test working group command to the solid state hard disk device through the general input and output interface, and use it to let the solid state hard disk device leave the sleep mode; and simulate the third joint test through the general input and output interface The workgroup command is given to the solid-state hard disk device, and is used for reading data of a specified length from a specified address of the static random access memory in the solid-state hard disk device.

The specification further relates to an embodiment of a computer program product, which includes a debugging program code of a solid-state hard disk device. When the processing unit of the Raspberry Pi executes the debugging program code, the above-mentioned debugging method for the solid state hard disk is implemented.

The specification further relates to an embodiment of a debugging device for a solid-state hard disk device, including: a general-purpose input and output interface; and a processing unit. The processing unit is coupled with the general input and output interface, and is used for implementing the above-mentioned debugging method for the solid-state hard disk when loading and executing the above-mentioned debugging code.

One of the advantages of the above-mentioned embodiment is that by using the debugging method with the GPIO in the Raspberry Pi as described above, it can be more flexible than the internal circuit emulator to solve the problems encountered during debugging.

Other advantages of the present invention will be explained in more detail with the following description and drawings.

10: Debugging system

110: Debugging device

112: Raspberry Pi

114: JTAG additional board

120: Solid state hard disk device

121: Flash controller

122: auxiliary register

123: JTAG interface

124: UART interface

125: processing unit

126: memory

127: Device interface

128:Flash memory module

129: host interface

130: personal computer

132: Device interface

140: JTAG connection device

150: UART recording device

160: power supply

210: processing unit

222:AHB/ASB

224:APB

230: memory controller

232: SRAM

234:DRAM

236: flash memory

260: GPIO interface

270:USB interface

280: Wi-Fi module

290:Bluetooth module

S510~S595: method steps

710: 20 pin connector

730:10 pin connector

S910~S970: method steps

FIG. 1 is a block diagram of a debugging system according to an embodiment of the invention.

FIG. 2 is a system architecture diagram of a Raspberry Pi according to an embodiment of the present invention.

FIG. 3 is a schematic diagram of an auxiliary register set of an Argonaut Reduced Instruction Set Computer Core (ARC) according to an embodiment of the present invention.

FIG. 4 is a schematic diagram of bit allocation of an Argonaut RISC Machine (ARM) auxiliary control register and a secondary auxiliary control register according to an embodiment of the present invention.

FIG. 5 is a flowchart of a method for debugging a solid-state hard disk device implemented by a debugging application program according to an embodiment of the present invention.

FIG. 6 is a schematic diagram of pins of a General-Purpose Input/Output (GPIO) interface of a Raspberry Pi according to an embodiment of the present invention.

FIG. 7 is a schematic diagram of converting JTAG 20 pins to 10 pins in a Joint Test Action Group (JTAG) connection device according to an embodiment of the present invention.

FIG. 8 is a pin diagram of the GPIO interface of the Raspberry Pi according to an embodiment of the present invention.

FIG. 9 is a flow chart of a method for debugging a solid-state hard disk device implemented by a function in a runtime library according to an embodiment of the present invention.

The following description is a preferred implementation mode of the invention, and its purpose is to describe the basic spirit of the invention, but not to limit the invention. For the actual content of the invention, reference must be made to the scope of the claims that follow.

It must be understood that words such as "comprising" and "including" used in this specification are used to indicate the existence of specific technical features, values, method steps, operations, components and/or components, but do not exclude the possibility of adding More technical characteristics, numerical values, method steps, operation processes, components, components, or any combination of the above.

Words such as "first", "second", and "third" used in the claims are used to modify the elements in the claims, and are not used to indicate that there is a priority order, a pre-relationship, or an element An element preceding another element, or a chronological order in performing method steps, is only used to distinguish elements with the same name.

It must be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element, intervening elements may be present. In contrast, when an element is described as being "directly connected" or "directly coupled" to another element, there are no intervening elements present. Other words used to describe the relationship between elements may be interpreted in a similar fashion, eg, "between" versus "directly between," or "adjacent" versus "directly adjacent," and so forth.

Refer to the block diagram of the debugging system shown in Figure 1. The debugging system 10 includes a debugging device 110, a solid-state hard disk device 120, a personal computer 130, a joint test working group (Joint Test Action Group, JTAG) connecting device 140 , Universal Asynchronous Receiver/Transmitter (UART) recording device 150 and power supply 160 . The solid-state hard disk device 120 is installed on the personal computer 130 . The debug device 110 obtains power from the power supply 160 and supplies power to the personal computer 130 , the JTAG connection device 140 and the UART recording device 150 . The personal computer 130 supplies power to the solid state disk device 120 .

The solid state disk device 120 is a device to be debugged, and at least includes a flash memory controller 121 and a flash memory module 128 . The flash memory module 128 provides a large amount of storage space, usually hundreds of gigabytes (Gigabytes), or even several terabytes (Terabytes), for storing a large amount of user data, such as high-resolution Pictures, videos, etc. The flash memory controller 121 includes a host interface 129 for connecting to a personal computer 130 to obtain power. The host interface 129 can be universal serial bus (Universal Serial Bus, USB), advanced technology attachment (advanced technology attachment, ATA), serial advanced technology attachment (serial advanced technology attachment, SATA), fast peripheral component interconnect express, PCI-E), universal flash storage (Universal Flash Storage UFS), embedded multimedia card (Embedded Multi-Media Card, eMMC) and other communication protocols communicate with the device interface 132 in the personal computer 130 . The flash memory controller 121 also includes a processing unit 125, which is connected to each other through a bus structure and a host interface 129, an auxiliary register (auxiliary register, AUX) 122, a JTAG interface 123, a UART interface 124, a memory 126, and a device interface 127 to transmit and receive Commands, control signals, messages, data, etc. The processing unit 125 can be implemented in a variety of ways, such as using general-purpose hardware (for example, a single processor, a multi-processor with parallel processing capabilities, a graphics processing unit, or other processors with computing capabilities), and executing firmware (firmware ) during the instruction process to access the auxiliary register 122 and the memory 126 for reading and storing variables, data tables, data, messages, etc. used in the execution process. For example, the processing unit 125 may be an Argonaut Reduced Instruction Set Computer (Argonaut Reduced Instruction Set Computer, RISC Core, referred to as ARC), an Argonaut Reduced Instruction Set Computer Machine (Argonaut RISC Machine, Abbreviated as ARM) and so on. The contents stored in the auxiliary register 122 and the memory 126 are important references for debugging. In some embodiments, the memory 126 can be a static random access memory (Static Random Access Memory, SRAM). In other embodiments, the memory 126 may include static random access memory and dynamic random access memory (Dynamic Random Access Memory, DRAM). The device interface 127 can use the double data rate (Double Data Rate DDR) communication protocol to communicate with each other, for example, open NAND flash (Open NAND Flash Interface ONFI), double data rate switch (DDR Toggle) or other communication protocols and flash memory modules Group 128 communicates for reading, writing or erasing data. The solid state hard disk device 120 is connected to the JTAG connection device 140 through the JTAG interface, and is connected to the UART recording device 150 through the UART interface 124 .

Auxiliary registers 122 may conform to ARC, ARM or other specifications. For example, Figure 3 shows a summary of the auxiliary register set taken from pages 45-46 of ARCompact ^™ Instruction Set Architecture: Programmer's Reference, published April 2008. Part A of Figure 4 shows the bit allocation taken from pages 4-41 of Cortex ^TM -R5 and Cortex-R5F revision: r1p1, Technical Reference Manual published in 2010-2011. Part B of Figure 4 shows the bit assignment of the secondary auxiliary control registers extracted from pages 4-45 of Cortex ^TM -R5 and Cortex-R5F revision: r1p1, Technical Reference Manual published in 2010-2011.

The embodiment of the present invention uses the debugging device 110, the JTAG connection device 140 and the UART recording device 150 to replace the commercially available in-circuit emulator (ICE), which is used to avoid using ICE to debug the solid-state hard disk device 120 Technical issues arising from the hardware and software in the In addition, the cost of the debugging device 110 , the JTAG connection device 140 and the UART recording device 150 is also lower than that of using ICE for debugging.

The debug device 110 is the core of the entire debug system 10 , including a raspberry Pi 112 and a JTAG add-on board 114 . The Raspberry Pi 112 is a single-chip computer based on the Linux operating system. The debugging application program is executed on the Raspberry Pi 112 , and the firmware to be debugged is executed on the solid state hard disk device 120 . The Raspberry Pi 112 feeds the power supply 160 into the personal computer 130 through the General-Purpose Input/Output (GPIO) interface to start the personal computer 130 when executing the debugging application program, so that the solid-state hard disk device 120 is also started, Next, it is judged whether the personal computer 130 starts up successfully according to the signal of the driving power LED (Light-Emitting Diode, LED). Because the JTAG interface can be driven by general IO signals, the Raspberry Pi 112 simulates the behavior of JTAG through the built-in GPIO interface when executing the debugging application program, and is used to obtain the required information from the solid-state hard disk device 120, and the access speed Can be higher than 4Mbps. The JTAG communication protocol can refer to the IEEE Standard Test Access Port and Boundary-Scan Architecture approved on June 14, 2001. The Raspberry Pi 112 forces the solid-state hard disk device 120 to enter the read-only memory (Read-Only Memory, ROM) mode through the built-in GPIO interface and the JTAG connection device 140 when executing the debugging application program. When the solid-state hard disk device 120 enters the ROM mode, the processing unit 125 loads and executes program codes from the ROM (not shown in FIG. 1 ) for performing system startup operations, such as various hardware tests. The Raspberry Pi 112 collects UART data, signals and messages from the solid-state hard disk device 120 through the built-in USB interface and the UART recording device 150 when executing the debugging application program. The engineer can operate the Raspberry Pi 112 to debug the hardware of the SSD device 120 and/or the firmware executed in the SSD device 120 . For example, the Raspberry Pi 112 can be equipped with a Wi-Fi or Bluetooth module, and the engineer can control the entire debugging device 110 by establishing a remote connection with the Wi-Fi or Bluetooth module in the Raspberry Pi 112 .

Refer to the system architecture of the Raspberry Pi 112 in FIG. 2 . The processing unit 210 can be an ARM architecture processor, and when executing the instructions of the debugging application program, it can complete the functions described below. Tool developers can use Python to write debug applications. The Raspberry Pi 112 contains different types of buses that can be used in combination: Advanced High-performance Bus/Advanced System Bus (AHB/ASB) 222; and Advanced Peripheral Bus (Advanced Peripheral Bus) , APB) 224. The AHB/ASB 222 and the APB 224 are connected by a bridge 220 . The AHB/ASB 222 is used to meet the high-speed bandwidth requirements between the processing unit 210 and the SRAM 232 , DRAM 234 or flash memory 236 through the memory controller 230 . The APB 224 is suitable for peripheral devices with low power consumption, such as GPIO interface 260 , USB interface 270 , Wi-Fi module 280 , Bluetooth module 290 and so on. The processing unit 210 can simulate JTAG behavior through the GPIO interface 260 , and receive UART data, signals and messages through the USB interface 270 . The processing unit 210 can receive a debugging request from a remote end via the Wi-Fi module 280 or the Bluetooth module 290 , and load and execute a debugging application program to respond to the debugging request.

An embodiment of the present invention proposes a debugging method for a solid-state hard disk device, which is implemented when the processing unit 210 loads and executes the program code of the debugging application. Referring to Figure 5, the details are as follows:

Step S510: Simulate the JTAG command through the GPIO interface 260 to read the identification code (identifier, ID) of the processing unit 125 of the flash controller 121 in the solid state disk device 120, such as ARC ID, ARM ID, etc. For example, the identification code of the processing unit 125 can be read from the specified address of the auxiliary register 122 in the solid state hard disk device 120 . In some embodiments, the ARC ID is recorded in bits 0 to 7 of the fourth double byte "ARCVER[7:0]" in FIG. 3 .

Step S520: Determine whether the identification code is correct. When the identification code is correct, the process proceeds to step S530. Otherwise, the process proceeds to step S525. This step can be used to confirm whether the debugging device 110 is correctly connected to the solid-state hard disk device 120 . If the processing unit 210 cannot read the identification code of the processing unit 125 of the flash controller 121 from the solid state hard disk device 120 , it means that the debugging device 110 is not connected to the solid state hard disk device 120 correctly.

Step S525: The debugging application program returns an error message to the upper layer that activates the debugging application program. The upper layer can drive the display to display the error message, or store the error message in the flash memory 236 to let the engineer know that an error occurred during the debugging process.

Step S530 : Stop the operation of the processing unit 125 of the flash controller 121 in the solid state disk device 120 by simulating the JTAG command through the GPIO interface 260 . For example, modify the The value of the specified address of the auxiliary register 122 in the solid state disk device 120 is used to stop the processing unit 125 . In some embodiments, the first bit “FH” of the fifth double byte in FIG. 3 can be set to “1” to stop the processing unit 125 .

Step S540 : Simulate the JTAG command through the GPIO interface 260 to make the solid state disk device 120 leave the sleep mode. For example, the value of the specified address of the auxiliary register 122 in the solid-state hard disk device 120 can be modified to make the solid-state hard disk device 120 leave the sleep mode. In some embodiments, the 23rd bit “ZZ” of the fifth double byte in FIG. 3 can be set to “0” to allow the solid state disk device 120 to leave the sleep mode.

Step S550 : read the in-system programming (ISP code) of the solid state disk device 120 by simulating the JTAG command through the GPIO interface 260 . For example, the in-system programming code can be stored at a specified address in the flash memory module 128, and the debugging application program can issue a JTAG command to read data of a specified length from the specified address of the flash memory module 128 (that is, the in-system programming code). The in-system programming code is used to execute host commands issued from the host, such as host read, write, erase commands, etc., or perform background operations, such as garbage collection (garbage collection, GC), wear leveling (wear leveling, WL), read regeneration (read reclaim), read refresh (read refresh) and other programs. Host commands are commands regulated by standard-setting organizations, such as Universal Flash Storage (UFS), Fast Non-Volatile Memory Express (NVMe), Open-channel SSD (Open-channel Solid State Disk, SSD), etc.

Step S560: Calculate the checksum of the programming code in the system. Debugging applications can use specific algorithms to calculate checksums, such as MD5, SHA1, SHA256, SHA512, etc.

Step S570: Determine whether the checksum is correct. When the checksum is correct, the process continues to step S580. Otherwise, the process proceeds to step S525. In some embodiments, because the manufacturer of the flash memory controller 121 of the solid-state hard disk device 120 may provide different versions of the in-system programming code for different types of NAND flash memory. The flash memory 236 in the Raspberry Pi 112 may pre-store checksums corresponding to multiple versions of the in-system programming code. The debugging application can compare the checksum generated in step S560 with the checksum stored in the flash memory 236 . If the checksum generated in step S560 is consistent with one of the multiple checksums stored in the flash memory 236, it is determined that the checksum is correct (that is, the internal system executed in the flash memory controller 121 of the solid state hard disk device 120 programming code can be identified as a specific system programming code version). On the contrary, it is determined that the checksum is incorrect (that is, the in-system programming code executed in the flash memory controller 121 of the solid-state hard disk device 120 is incorrect or unrecognizable). In addition to determining whether the checksum is correct, this step can also be used to know the version of the in-system programming code executed in the flash memory controller 121 . It should be noted here that different versions of the programming code in the system have different memory configuration logics, which are used to store variables during execution, data tables, data to be written into the flash memory module 128, and read from the flash memory module 128. information etc. That is to say, the debugging application program needs to know the memory configuration logic first, and then it can dump the correct address of the memory 126 (including SRAM and DRAM) in the solid-state hard disk device 120 according to the memory configuration logic. required information.

Step S580 : Simulate the JTAG command through the GPIO interface 260 to read the data in the SRAM of the solid-state hard disk device 120 . For example, the firmware data generated during booting or normal operation can be stored in a specified address in SRAM, and the debugging application can issue multiple JTAG commands to the solid-state hard disk device 120, and each JTAG command requests data from the SRAM. Read the data of the specified length (that is, the firmware data) at the specified address. In some embodiments, the flash memory 236 in the Raspberry Pi 112 can store a file including multiple records. Each record contains start address and length information. The debugging application program can send JTAG commands to the solid-state hard disk device 120 according to each record in the file to read data of a specified length from a specified address of the SRAM.

Step S590 : In the embodiment in which the memory 126 is equipped with DRAM, simulate the JTAG command through the GPIO interface 260 to read the data in the DRAM of the solid-state hard disk device 120 . For example, firmware data generated during power-up or during normal operation can be stored in At a specified address in the DRAM, the debugging application can send multiple JTAG commands to the solid state hard disk device 120, and each JTAG command requests to read data of a specified length (that is, firmware data) from the specified address of the DRAM. In some embodiments, the flash memory 236 in the Raspberry Pi 112 can store a file including multiple records. Each record contains start address and length information. The debugging application program can send JTAG commands to the solid-state hard disk device 120 according to each record in the file to read data of a specified length from a specified address of the DRAM.

Step S595 : Simulate the JTAG command through the GPIO interface 260 to reply to the processing unit 125 of the flash controller 121 in the solid state disk device 120 . For example, the value of the specified address of the auxiliary register 122 in the solid-state hard disk device 120 can be modified to restore the processing unit 125 . In some embodiments, the first bit “FH” of the fifth double byte in FIG. 3 can be set to “0” to reply to the processing unit 125 .

The following shows the dummy code for the debugger application:

Through the debugging method of the solid state hard disk device implemented by the debugging application program as described above, it can be more flexible than the internal circuit emulator, so as to solve the problems encountered during debugging. For example, when the firmware of the solid-state hard disk device is stuck, the hardware register can be quickly accessed to obtain the status of the NAND flash memory.

Refer to Figure 1 and Figure 2. The UART recording device 150 includes a USB interface, a UART interface, a controller and a memory. The USB interface of the UART recording device 150 is connected to the USB interface of the Raspberry Pi 112 , and the UART interface of the UART recording device 150 is connected to the UART interface 124 of the solid state hard disk device 120 . The UART recording device 150 receives log information from the solid-state hard disk device 120 through its UART interface, including data, messages and/or signals, and transmits the log information to the Raspberry Pi 112 through its USB interface. The UART recording device 150 may further include a non-volatile storage unit for storing log information received from the solid state disk device 120 . Each port used in the USB interface can be connected to a designated port on the UART interface through a voltage/level shifter. The voltage/level shifter is used to adjust the input signal from the USB interface from a voltage domain to the voltage domain of the UART interface, or adjust the input signal from the UART interface from a voltage domain to the voltage domain of the USB interface.

Referring to FIG. 6 , the Raspberry Pi 112 can be connected to the JTAG add-on board 114 through 40 pins of the GPIO interface 260 . The JTAG add-on board 114 is responsible for transmitting signals between the Raspberry Pi 112 and the JTAG connection device 140 and between the Raspberry Pi 112 and the PC 130 . The JTAG add-on board 114 includes a GPIO interface and a type-C interface, the GPIO interface is connected to the Raspberry Pi 112 and the personal computer 130 , and the type-C interface is connected to the JTAG connection device 140 . Each port used in the GPIO interface can be connected to the specified port on the type-C interface through a voltage/level converter. The voltage/level converter is used to adjust the input signal from the GPIO interface from a voltage domain to a type The voltage domain of the -C interface, or adjust the input signal from the type-C interface from a voltage domain to the voltage domain of the GPIO interface.

The JTAG connection device 140 can be regarded as a JTAG adapter (JTAG adapter), which can be 20 pins to 10 pins, 20 pins to 8 pins, etc., and is responsible for transferring the JTAG commands simulated by the Raspberry Pi 112 via the JTAG additional board 114 , sending the data to the solid-state hard disk device 120 , and sending the output data of the solid-state hard disk device 120 to the Raspberry Pi 112 via the JTAG additional board 114 . The JTAG connection device 140 includes a type-C interface, a JTAG interface, a controller and a memory. The type-C interface of the JTAG connection device 140 can be connected to the type-C interface of the JTAG add-on board 114 , and the JTAG interface of the JTAG connection device 140 can be connected to the JTAG interface 123 of the solid state hard disk device 120 . It should be noted here that since the solid-state hard disk device 120 needs to be tested in a high-temperature environment in a test chamber, the JTAG connection device 140 is separated instead of integrating the JTAG connection device 140 into the JTAG additional board 114 On the other hand, the solid-state hard disk device 120 and the JTAG connection device 140 can be placed together in the test chamber for debugging. Refer to the 20-pin to 10-pin conversion in Figure 7 Examples include a 20-pin connector 710 for connecting to the JTAG add-on board 114 and a 10-pin connector 730 for connecting to the JTAG interface 123 . For example, the ninth pin of the connector 710 feeds a test clock (TCLK) signal from the JTAG add-on board 114 , and the fourth pin of the connector 730 outputs the clock signal to the JTAG interface 123 . The seventh pin of the connector 710 inputs the test mode select input (TMS) signal from the JTAG add-on board 114 , and the second pin of the connector 730 outputs the test mode select input signal to the JTAG interface 123 . The fifth pin of the connector 710 inputs the test data input (TDI) signal from the JTAG add-on board 114 , and the eighth pin of the connector 730 outputs the test data input signal to the JTAG interface 123 . The thirteenth pin of the connector 730 inputs a test data output (TDO) signal from the JTAG interface 123 , and the sixth pin of the connector 710 outputs the test data output signal to the JTAG add-on board 114 . The tenth pin of the connector 710 inputs the test reset input (TRST) signal from the JTAG add-on board 114 , and the third pin of the connector 730 outputs the test reset input signal to the JTAG interface 123 . Each of the above-mentioned pins of the connector 710 can be connected to a designated pin of the connector 730 via a voltage/level converter, and the voltage/level converter is used to adjust the input signal of the type-C interface from a voltage domain to the voltage domain of the JTAG interface, or adjust the input signal of the JTAG interface from a voltage domain to the voltage domain of the type-C interface.

Three power relays connected to the power supply can be provided on the JTAG add-on board 114 . Referring to the example pin-out diagram of the GPIO interface 260 of FIG. Power supply 160 to personal computer 130 . The pin GPIO17 is connected to the signal line for driving the LED in the personal computer 130 to detect whether the personal computer 130 is started correctly. The pin GPIO 16 is connected to a specific pin of the solid-state hard disk device 120 for driving the solid-state hard disk device 120 into the ROM mode. The pin GPIO22 is connected to a specific pin of the SATA interface of the solid-state hard disk device 120 for driving the solid-state hard disk device 120 to enter or leave the sleep mode. It should be noted here that the hibernation mode entered through the SATA interface will cut off the power supply of most components (including the processing unit 125 ) in the solid-state hard disk device 120 to save power. In other words, when entering the hibernation mode through the SATA interface, the processing unit 125 in the solid-state hard disk device 120 will not perform any operations. The sleep mode that the debug application leaves when issuing JTAG commands as described above is different from the sleep mode entered through the SATA interface. The pin positions GPIO11, GPIO5, GPIO6, GPIO13, GPIO19 and GPIO26 are used to allow the processing unit 210 in the Raspberry Pi 112 to execute Simulate JTAG behavior when debugging application programs, send JTAG commands to the solid-state hard disk device 120 through these pins, and obtain in-system programming codes, firmware data, etc. from the solid-state hard disk device 120 . For example, the pin GPIO5 can be used to transmit the JTAG TDI signal to the solid-state hard disk device 120 , and the pin GPIO6 can be used to receive the JTAG TDO signal from the solid-state hard disk device 120 . See IEEE Standard Test Access Port and Boundary-Scan Architecture, June 14, 2001, for emulation details of JTAG behavior.

Refer to Figure 2. The Raspberry Pi 112 is a low-cost personal computer, so there is no implementation of low-latency peripheral port (LLPP) technology, which uses a dedicated path to access the GPIO interface. When the upper-level debugging application program wants to send a JTAG command through the GPIO interface 260 to access the contents of the auxiliary register 122 or memory 126 in the solid-state hard disk device 120, the lower-level GPIO driver program can sequentially pass through the AHB/ASB 222 And the APB 224 sends hardware instructions and parameters to the GPIO interface 260 for writing (or called setting) the register corresponding to the specific pin in the GPIO interface 260 to complete the simulation of the JTAG command. However, some hardware instructions may be delayed in reaching the APB 224 due to hardware limitations. When two hardware instructions for writing the same register in the GPIO interface 260 arrive at the APB controller in a very short time interval, the APB controller may misjudge it as a wrong hardware instruction and discard one of them without executing it. , so that some of the programming codes and firmware data in the system cannot be read back from the solid state hard disk device 120 .

In order to solve the above problems, the embodiment of the present invention modifies the function in the runtime library (runtime library), this function is used to drive the GPIO interface 260 to complete the operation, so that the debugging application can call this function to complete the above Described function, for example sends JTAG command to read the identification code of the processing unit 125 of the flash controller 121 in the solid-state hard disk device 120, stops the processing unit 125 of the flash controller 121 in the solid-state hard disk device 120, Make the solid-state hard disk device 120 leave the sleep mode, read the in-system programming code stored in the flash memory module 128 of the solid-state hard disk device 120 , read the data in the SRAM and DRAM of the solid-state hard disk device 120 . The runtime library is a set of built-in functions used by the compiler to implement a programming language to provide a special computer program library supported by the programming language when it is executed. Referring to Figure 9, the details are as follows:

Step S910: Receive a request to drive the GPIO interface from the debugging application program, including parameters required to complete a specific JTAG command. For example, corresponding to step S510 of FIG. 5 , referring to FIG. 3 , the parameters in the request include information on reading bits 0 to 7 of the fourth double byte in the auxiliary register 122 . Corresponding to step S530 of FIG. 5 , referring to FIG. 3 , the parameter in the request includes information to set the first bit of the fifth double byte in the auxiliary register 122 to “1”. Corresponding to step S540 of FIG. 5 , referring to FIG. 3 , the parameter in the request includes information to set the 23rd bit of the fifth double byte in the auxiliary register 122 to "0". Corresponding to step S550 in FIG. 5 , the parameters in the request include information about reading data of a specified length from a specified address of the flash memory module 128 . Corresponding to step S580 in FIG. 5 , the parameters in the request include information about reading data of a specified length from a specified address of the SRAM. Corresponding to step S590 in FIG. 5 , the parameters in the request include information about reading data of a specified length from a specified address of the DRAM.

Step S930 : Send a hardware command to the GPIO interface 260 according to the parameters carried in the request to set the register corresponding to the GPIO pin of TDI for simulating a specific JTAG command.

Step S950 : Send a hardware command to the GPIO interface 260 to read the value of the register corresponding to the GPIO pin of TDI. Due to the operation of this step, in accordance with the two requests generated Between the hardware instructions for setting the register corresponding to the GPIO pin of TDI, insert a hardware instruction for reading the register value corresponding to the GPIO pin of TDI, which can prevent the APB controller from converting the two registers in a very short time. The hardware commands that set the registers corresponding to the GPIO pins of the TDI that arrive successively in the intervals are misjudged as wrong hardware commands. It should be noted here that this step can also be performed between steps S910 and S930, and the present invention is not limited thereto.

Step S970: Reply a message of completion of driving to the debugging application program.

The processing unit 210 of the Raspberry Pi 112 can periodically execute another function in the library for periodically driving the GPIO interface 260 for reading the value of the register corresponding to the GPIO pin of TDO. The read value is the execution result of the simulated JTAG command sent by the GPIO pin corresponding to TDI before, which is generated and returned by the solid-state hard disk device 120, and may include, for example, information about the success or failure of the setting of the auxiliary register 122, from the flash memory In-system programming code read by the module 128, firmware data read from SRAM or DRAM, etc.

All or part of the steps in the method of the present invention can be implemented by computer instructions, such as specific hardware drivers, firmware programs or software programs. In addition, it can also be implemented in other types of programs. Those skilled in the art can write the methods of the embodiments of the present invention into computer instructions, and the description is omitted for the sake of brevity. The computer instructions implemented according to the method of the embodiment of the present invention can be stored in a suitable computer-readable medium, such as DVD, CD-ROM, USB disk, hard disk, and can also be placed through a network (for example, the Internet, or other suitable means of access to the web server.

Although the elements described above are included in FIG. 1 and FIG. 2 , it is not excluded to use more other additional elements to achieve better technical effects without violating the spirit of the invention. In addition, although the flow charts in FIG. 5 and FIG. 9 are executed in a specified order, those skilled in the art can modify the order of these steps while achieving the same effect without violating the spirit of the invention. Therefore, The invention is not limited to using only the sequence described above. In addition, those skilled in the art can also integrate several steps into one step, or in addition to these steps, perform more steps sequentially or in parallel, and the present invention does not So limited.

Although the present invention is described using the above examples, it should be noted that these descriptions are not intended to limit the present invention. On the contrary, the invention covers modifications and similar arrangements obvious to those skilled in the art. Therefore, the claims of the application must be interpreted in the broadest manner to include all obvious modifications and similar arrangements.

S510~S595: method steps

Claims (14)

A debugging method for a solid-state hard disk device, implemented by a processing unit of a raspberry pie when loading and executing a debugging application program, the method includes: simulating a first joint test working group command through a general-purpose input and output interface to the described A solid-state hard disk device, used to stop the operation of the processing unit of the flash controller in the solid-state hard disk device; simulate a second joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, Used to let the solid state hard disk device leave the dormancy mode; and simulate a third joint test working group command to the solid state hard disk device through the general input and output interface, for the static state hard disk device from the solid state hard disk device Data of a specified length is read from a specified address of the random access memory. The debugging method of the solid-state hard disk device according to claim 1, wherein the first joint test work group command is used to use the fifth double byte of the auxiliary register in the solid-state hard disk device The 1st bit is set to "1", and the second JTWG command is used to set the 23rd bit of the fifth double byte of the auxiliary register in the SSD device element is set to "0". The debugging method of a solid-state hard disk device as described in claim 1, comprising: simulating a fourth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, for retrieving from the solid-state hard disk Data of a specified length is read from a specified address of the DRAM in the device. The debugging method of a solid-state hard disk device according to claim 1, comprising: simulating a fifth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, for reading the solid-state hard disk The flash control in the disc device the identification code of the processing unit of the device; determine whether the identification code is correct; and when the identification code is correct, complete the first joint test work group command, the second joint test work group command and The simulation operation of the third joint test workgroup command. The debugging method of the solid-state hard disk device according to claim 4, wherein the fifth joint test work group command is used to read the fourth double bit of the auxiliary register in the solid-state hard disk device The value of bits 0 to 7 of the group. The debugging method of a solid-state hard disk device as described in claim 1, comprising: simulating a sixth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, for retrieving from the solid-state hard disk The flash memory module in the device reads the in-system programming code; calculates a first checksum of the in-system programming code; and completes the third joint test workgroup command when the first checksum is correct simulation operation. The debugging method of a solid-state hard disk device as described in claim 6, comprising: providing a second checksum of a plurality of in-system programming code versions; when the first checksum matches a plurality of the second checksums When one of the verification sums is selected, the memory configuration logic of the corresponding in-system programming code version is obtained; and the simulation operation of the command of the third joint test working group is completed according to the memory configuration logic. A computer program product, comprising a debugging program code for a solid-state hard disk device, wherein, when the processing unit of the Raspberry Pi executes the debugging program code, any of the requirements 1 to 7 is implemented A debugging method for a solid-state hard disk device. A device for debugging a solid-state hard disk device, which is set in a raspberry pie and includes: a general-purpose input-output interface; and a processing unit, coupled to the general-purpose input-output interface, when loading and executing a debugging application program, through The general-purpose input and output interface simulates the first joint test working group command to the solid-state hard disk device for stopping the operation of the processing unit of the flash controller in the solid-state hard disk device; through the general-purpose input and output The interface simulates the command of the second joint test working group to the solid-state hard disk device, which is used to let the solid-state hard disk device leave the sleep mode; The solid-state hard disk device is used for reading data of a specified length from a specified address of a static random access memory in the solid-state hard disk device. The device for debugging a solid-state hard disk device as described in claim 9, wherein the Raspberry Pi is a single-chip computer based on a Linux operating system. The device for debugging a solid-state hard disk device as described in claim 9, wherein, the processing unit simulates a fourth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, for from The specified address of the dynamic random access memory in the solid-state hard disk device reads data of a specified length. The device for debugging a solid-state hard disk device as described in claim 9, wherein the processing unit simulates the fifth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface for reading Get the identification code of the processing unit of the flash controller in the solid-state hard disk device; judge whether the identification code is correct; and when the identification code is correct, complete the first joint test work group group command, the second A joint test workgroup command and a simulated operation of the third joint test workgroup command. The device for debugging a solid-state hard disk device as described in claim 9, wherein the processing unit simulates a sixth joint test working group command to the solid-state hard disk device through the general-purpose input and output interface, for from The flash memory module in the solid-state hard disk device reads the in-system programming code; calculates a first checksum of the in-system programming code; and completes the third combination when the first checksum is correct Test mock operation of workgroup commands. The device for debugging a solid-state hard disk device as described in claim 13, comprising: a flash memory, coupled to the processing unit, for storing a second checksum of a plurality of in-system programming code versions; wherein, the processing When the unit detects that the first checksum matches one of the plurality of second checksums, acquiring the memory configuration logic of the corresponding in-system programming code version; and according to the memory configuration logic completing the simulation operation of the command of the third joint test working group.

Images