Debugging method and device for computer-readable storage medium and solid state disk device

Abstract

The present application relates to a computer readable storage medium, a debugging method and device of a solid state disk device, the method is executed by a processing unit in a Raspberry Pi, comprising: simulating a first joint test working group command to the solid state disk device through a general input / output interface, for stopping the running of the processing unit of the flash memory controller in the solid state disk device; simulating a second joint test working group command to the solid state disk device through the general input / output interface, for letting the solid state disk device leave the hibernation mode; and simulating a third joint test working group command to the solid state disk device through the general input / output interface, for reading data of a specified length from a specified address of the static random access memory in the solid state disk device. Through the debugging method as described above in combination with the general input / output interface in the Raspberry Pi, the flexibility of the internal circuit simulator can be improved to solve the problems encountered during debugging.

Description

TECHNICAL FIELD

[0001] The present application relates to a storage device, in particular, the present application relates to a computer readable storage medium, a debugging method and device for a solid state disk device. BACKGROUND

[0002] Currently, the firmware status of a solid state disk (SSD) device during runtime is collected using a commercially available in-circuit emulator (ICE), which encounters the following problems: the in-circuit emulator cannot be controlled to meet all application environments, for example, when the in-circuit emulator stops, some fixed operations are performed, such as stopping the central processing unit in the solid state disk product, so that the host cannot continue to access the data in the solid state disk product. The current in-circuit emulator is very slow in responding when the address needs to be changed to read the hardware register, for example, when the engineer wants to access the hardware register to know the status of the NAND flash memory when the firmware is stuck. In addition, the in-circuit emulator is very expensive, and the debugging cost needs to be further reduced. Therefore, the present application proposes a computer readable storage medium, a debugging method and device for a solid state disk device, which is used to solve the above-mentioned problems. SUMMARY

[0003] Therefore, how to alleviate or eliminate the above-mentioned deficiencies in the related art is a problem to be solved.

[0004] The present application relates to a debugging method for a solid state disk, executed by a processing unit of a Raspberry Pi, comprising: simulating a first joint test action group command to a solid state disk device through a general input / output interface, for stopping the running of a processing unit of a flash memory controller in the solid state disk device; simulating a second joint test action group command to the solid state disk device through the general input / output interface, for making the solid state disk device leave a hibernation mode; and simulating a third joint test action group command to the solid state disk device through the general input / output interface, for reading data of a specified length from a specified address of a static random access memory in the solid state disk device.

[0005] The present application also relates to a computer readable storage medium, comprising a debugging program code for a solid state disk device. When the processing unit of the Raspberry Pi executes the debugging program code, the above-mentioned debugging method for the solid state disk is implemented.

[0006] The present application also relates to a debugging device for a solid state disk device, comprising: a general input / output interface; and a processing unit. The processing unit is coupled to the general input / output interface, and when the debugging program code is loaded and executed, the above-mentioned debugging method for the solid state disk is implemented.

[0007] One of the advantages of the above-mentioned embodiments is that the debugging method of matching the general-purpose input / output interface in the Raspberry Pi can be more flexible than the internal circuit simulator to solve problems encountered during debugging.

[0008] Other advantages of the present application will be explained in more detail in conjunction with the following description and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0009] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and serve to explain the principles of the application, and do not limit the application.

[0010] Figure 1 A block diagram of a debugging system according to an embodiment of the present application.

[0011] Figure 2 A system architecture diagram of a Raspberry Pi according to an embodiment of the present application.

[0012] Figure 3 A schematic diagram of an Argonaut Reduced Instruction Set Computer Core (ARC) auxiliary register set according to an embodiment of the present application.

[0013] Figure 4 A bit allocation schematic diagram of an Argonaut Reduced Instruction Set Computer Machine (ARM) auxiliary control register and a secondary auxiliary control register according to an embodiment of the present application.

[0014] Figure 5 A flowchart of a method of debugging a solid state drive device by a debugging application according to an embodiment of the present application.

[0015] Figure 6 A pin schematic diagram of a General-Purpose Input / Output (GPIO) interface of a Raspberry Pi according to an embodiment of the present application.

[0016] Figure 7 A schematic diagram of a Joint Test Action Group (JTAG) 20-pin to 10-pin conversion in a JTAG connection device according to an embodiment of the present application.

[0017] Figure 8 A pin diagram of a GPIO interface of a Raspberry Pi according to an embodiment of the present application.

[0018] Figure 9A flowchart of a method for debugging a solid state disk device according to an embodiment of the present application.

[0019] Legend of reference signs

[0020] 10 debugging system

[0021] 110 debugging device

[0022] 112 Raspberry Pi

[0023] 114 JTAG add-on board

[0024] 120 solid state disk device

[0025] 121 flash memory controller

[0026] 122 auxiliary register

[0027] 123 JTAG interface

[0028] 124 UART interface

[0029] 125 processing unit

[0030] 126 memory

[0031] 127 device interface

[0032] 128 flash memory module

[0033] 129 host interface

[0034] 130 personal computer

[0035] 132 device interface

[0036] 140 JTAG connection device

[0037] 150 UART recording device

[0038] 160 power supply

[0039] 210 processing unit

[0040] 222 AHB / ASB

[0041] 224 APB

[0042] 230 memory controller

[0043] 232 SRAM

[0044] 234 DRAM

[0045] 236 flash memory

[0046] 260 GPIO interface

[0047] 270 USB interface

[0048] 280 Wi-Fi module

[0049] 290 Bluetooth module

[0050] 710 20-pin connector

[0051] 730 10-pin connector DETAILED DESCRIPTION

[0052] Embodiments of the present application will be described below with reference to the accompanying drawings. In these drawings, the same reference numbers indicate the same or similar components or method steps.

[0053] It must be appreciated that the terms such as "comprise", "include", and the like used in the present specification are intended to indicate that there are the specific technical features, numerical values, method steps, operation processes, components, and / or combinations thereof, but do not exclude the possibility of adding more technical features, numerical values, method steps, operation processes, components, combinations, or any combinations thereof.

[0054] The terms such as "first", "second", "third", and the like used in the present application are intended to modify the components in the claims, and are not intended to indicate priority order, precedence, or one component preceding another component, or time order of performing method steps, but are only used to distinguish components having the same name.

[0055] It must be appreciated that when a component is described as "connected" or "coupled" to another component, it can be directly connected or coupled to the other component, and there can be an intermediate component. Conversely, when a component is described as "directly connected" or "directly coupled" to another component, there is no intermediate component. Other words used to describe the relationship between components can be interpreted in a similar manner, such as "between" corresponding to "directly between", or "adjacent" corresponding to "directly adjacent", and the like.

[0056] Reference Figure 1A debug system block diagram is shown. The debug system 10 includes a debug device 110, a solid state drive device 120, a personal computer 130, a Joint Test Action Group (JTAG) connection device 140, a Universal Asynchronous Receiver / Transmitter (UART) recording device 150, and a power supply 160. The solid state drive device 120 is provided on the personal computer 130. The debug device 110 acquires 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 drive device 120.

[0057] The SSD device 120 is a device to be debugged, and includes at least a flash controller 121 and a flash module 128. The flash module 128 provides a large amount of storage space, typically hundreds of Gigabytes, or even several Terabytes, for storing a large amount of user data, such as high-resolution pictures, videos, etc. The flash controller 121 includes a host interface 129 for connecting to a personal computer 130 for power. The host interface 129 can communicate with a device interface 132 in the personal computer 130 using a communication protocol such as Universal Serial Bus (USB), advanced technology attachment (ATA), serial advanced technology attachment (SATA), peripheral component interconnect express (PCI-E), Universal Flash Storage (UFS), Embedded Multi-Media Card (eMMC), etc. The flash controller 121 also includes a processing unit 125 connected to each other through a bus architecture and the host interface 121, an auxiliary register (AUX) 122, a JTAG interface 123, a UART interface 124, a memory 126, and a device interface 127 for transmitting and receiving commands, control signals, information, data, etc. The processing unit 125 can be implemented in various ways, such as using general-purpose hardware (e.g., a single processor, multiple processors with parallel processing capabilities, a graphics processor, or other processors with computing capabilities), and accesses the auxiliary register 122 and the memory 126 during execution of firmware instructions for reading and storing variables, data tables, data, information, etc. used during execution. For example, the processing unit 125 can be an Argonaut Reduced Instruction Set Computer (RISC) Core (ARC), an Argonaut RISC Machine (ARM), etc. The contents stored in the auxiliary register 122 and the memory 126 are important reference bases during debugging. In some embodiments, the memory 126 can be a Static Random Access Memory (SRAM).In other embodiments, the memory 126 can include static random access memory and dynamic random access memory (DRAM). The device interfaces 127 can communicate with each other using a Double Data Rate (DDR) communication protocol, such as the Open NAND Flash Interface (ONFI), DDR Toggle, or other communication protocol, and with the flash memory module 128 for reading, writing, or erasing data. The solid state drive device 120 is connected to the JTAG connection device 140 through the JTAG interface and to the UART recording device 150 through the UART interface 124.

[0058] The auxiliary registers 122 can be compliant with the ARC, ARM, or other specification. For example, Figure 3 The auxiliary register set is summarized in the excerpt from pages 45-46 of the ARCompact Instruction Set Architecture: Programmer’s Reference, published in April 2008. TM The auxiliary register set is summarized in the excerpt from pages 45-46 of the ARCompact Instruction Set Architecture: Programmer’s Reference, published in April 2008. Figure 4 Part A of the excerpt from pages 4-41 of the Cortex-R4 and Cortex-R4F revision: r1p0, Technical Reference Manual, published in 2010-2011 shows the bit allocation. TM Part A of the excerpt from pages 4-41 of the Cortex-R4 and Cortex-R4F revision: r1p0, Technical Reference Manual, published in 2010-2011 shows the bit allocation. Figure 4 Part B of the excerpt from pages 4-45 of the Cortex-R4 and Cortex-R4F revision: r1p1, Technical Reference Manual shows the bit allocation for the secondary auxiliary control registers. TM Part B of the excerpt from pages 4-45 of the Cortex-R4 and Cortex-R4F revision: r1p1, Technical Reference Manual shows the bit allocation for the secondary auxiliary control registers.

[0059] Embodiments of the present invention use the debug device 110, the JTAG connection device 140, and the UART recording device 150 to replace commercially available in-circuit emulators (ICE) for avoiding technical problems caused by using ICE to debug hardware and software in the solid state drive device 120. In addition, the cost of the debug device 110, the JTAG connection device 140, and the UART recording device 150 is also lower than the cost of using ICE for debugging.

[0060] The debugging device 110 is the core of the entire debugging system 10, comprising 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 runs on the Raspberry Pi 112, and the firmware to be debugged runs on the solid-state drive 120. When the Raspberry Pi 112 executes the debugging application, it supplies power 160 to the personal computer 130 via the General-Purpose Input / Output (GPIO) interface to start the personal computer 130, causing the solid-state drive 120 to start as well. Then, it determines whether the personal computer 130 has successfully started based on the signal from the power-driving LED. Because the JTAG interface can be driven by general I / O signals, the Raspberry Pi 112 simulates JTAG behavior through its built-in GPIO interface when executing the debugging application to obtain the necessary information from the solid-state drive 120, with access speeds exceeding 4 Mbps. The JTAG communication protocol can be found in the IEEE Standard Test Access Port and Boundary-Scan Architecture, approved on June 14, 2001. When executing a debug application, the Raspberry Pi 112 forces the solid-state drive 120 into read-only memory (ROM) mode via its built-in GPIO interface and JTAG connection device 140. When the solid-state drive 120 enters ROM mode, the processing unit 125 reads data from the ROM (not shown). Figure 1 The Raspberry Pi 112 loads and executes program code to perform system boot operations, such as various hardware tests. When executing debugging applications, the Raspberry Pi 112 collects UART data, signals, and information from the solid-state drive 120 via its built-in USB interface and UART recording device 150. Engineers can operate the Raspberry Pi 112 to debug the hardware of the solid-state drive 120 and / or the firmware running on the solid-state drive 120. For example, the Raspberry Pi 112 can be equipped with a Wi-Fi or Bluetooth module, allowing engineers to remotely control the entire debugging device 110 by establishing a connection with the Wi-Fi or Bluetooth module in the Raspberry Pi 112.

[0061] refer to Figure 2Figure 2 illustrates a system architecture of the Raspberry Pi 112. The processing unit 210 can be an ARM architecture processor, and performs functions as described below when executing instructions of the debug application. The tool developer can use Python to write the debug application. The Raspberry Pi 112 includes different types of buses that can be used in combination: Advanced High-performance Bus / Advanced System Bus (AHB / ASB) 222; and 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 requirement of the processing unit 210 between the memory controller 230 and the SRAM 232, the DRAM 234, or the flash memory 236. The APB 224 is suitable for low-power peripheral devices, such as the GPIO interface 260, the USB interface 270, the Wi-Fi module 280, the Bluetooth module 290, and the like. The processing unit 210 can emulate the behavior of JTAG through the GPIO interface 260, and receive UART data, signals, and information, and the like through the USB interface 270. The processing unit 210 can receive a debug request from a remote device via the Wi-Fi module 280 or the Bluetooth module 290, and load and execute the program code of the debug application to respond to the debug request.

[0062] The embodiment of the present disclosure proposes a debug method for a solid state disk device, which is implemented when the processing unit 210 loads and executes the program code of the debug application. Referring to Figure 5 , the details are as follows:

[0063] Step S510: Emulate JTAG commands through the GPIO interface 260 to read the identifier (ID) of the processing unit 125 of the flash memory controller 121 in the solid state disk device 120, such as ARC ID, ARM ID, and the like. For example, the identifier of the processing unit 125 can be read from a specified address of the auxiliary register 122 in the solid state disk device 120. In some embodiments, the ARC ID is recorded in the 0th to 7th bits of the fourth double byte "ARCVER[7:0]" in the auxiliary register 122. Figure 3

[0064] ​Step S520: Determine whether the identifier is correct. When the identifier is correct, the flow continues with the processing of step S530. Otherwise, the flow continues with the processing of step S525. This step can be used to confirm whether the debug device 110 is properly connected to the solid state drive device 120. If the processing unit 210 fails to read the identifier of the processing unit 125 of the flash controller 121 from the solid state drive device 120, it means that the debug device 110 is not properly connected to the solid state drive device 120.

[0065] Step S525: The debug application replies error information to the upper layer that initiates the debug application. The upper layer can then drive the display to display the error information, or store the error information in the flash memory 236 for letting the engineer know that an error occurs during the debugging.

[0066] Step S530: Simulate a JTAG command through the GPIO interface 260 to stop the operation of the processing unit 125 of the flash controller 121 in the solid state drive device 120. For example, the value of a specified address of the auxiliary register 122 in the solid state drive device 120 can be modified to stop the processing unit 125. In some embodiments, the 1st bit "FH" of the 5th double byte in the auxiliary register 122 in the solid state drive device 120 can be set to "1" to stop the processing unit 125. Figure 3

[0067] Step S540: Simulate a JTAG command through the GPIO interface 260 to let the solid state drive device 120 exit the sleep mode. For example, the value of a specified address of the auxiliary register 122 in the solid state drive device 120 can be modified to let the solid state drive device 120 exit the sleep mode. In some embodiments, the 23rd bit "ZZ" of the 5th double byte in the auxiliary register 122 in the solid state drive device 120 can be set to "0" to let the solid state drive device 120 exit the sleep mode. Figure 3

[0068] ​​Step S550: emulate JTAG commands through the GPIO interface 260 to read in-system programming (ISP) code of the solid state disk device 120. For example, the ISP code can be stored at a specified address in the flash memory module 128, and the debug application can issue JTAG commands to read a specified length of data (i.e., the ISP code) from the specified address in the flash memory module 128. The ISP code includes procedures for executing host commands issued from the host, such as host read, write, erase commands, etc., or performing background operations, such as garbage collection (GC), wear leveling (WL), read reclaim, read refresh, etc. The host commands are commands specified by standard setting organizations, such as Universal Flash Storage (UFS), Non-Volatile Memory Express (NVMe), Open-channel Solid State Disk (SSD), etc.

[0069] Step S560: calculate a checksum of the ISP code. The debug application can use a specific algorithm to calculate the checksum, such as MD5, SHA1, SHA256, SHA512, etc.

[0070] Step S570: Determine whether the checksum is correct. When the identifier is correct, the flow proceeds with the processing of step S580. Otherwise, the flow proceeds with the processing of step S525. In some embodiments, different versions of the in-system programming code can be provided by the manufacturer of the flash controller 121 of the SSD device 120 for different types of NAND flash memory. The flash memory 236 in the Raspberry Pi 112 can pre-store checksums corresponding to multiple versions of the in-system programming code. The debug application can compare the checksum generated in step S560 with the checksums stored in the flash memory 236. If the checksum generated in step S560 matches one of the checksums stored in the flash memory 236, the checksum is determined to be correct (i.e., the in-system programming code executed in the flash controller 121 of the SSD device 120 can be identified as a particular version of the in-system programming code). Otherwise, the checksum is determined to be incorrect (i.e., the in-system programming code executed in the flash controller 121 of the SSD device 120 is incorrect or cannot be identified). This step can be used to determine whether the checksum is correct, and also to know the version of the in-system programming code executed in the flash controller 121. It is noted that different versions of the in-system programming code have different memory configuration logic for storing variables, data tables, data to be written to the flash memory module 128, data read from the flash memory module 128, etc. That is, the debug application needs to know the memory configuration logic first, and then can dump the required data from the correct addresses of the memory 126 (including SRAM, DRAM) in the SSD device 120 according to the memory configuration logic.

[0071] Step S580: Simulate JTAG commands through the GPIO interface 260 to read data in the SRAM of the SSD device 120. For example, firmware data generated during boot-up or during normal operation can be stored in a specified address in the SRAM, and the debug application can issue JTAG commands to the SSD device 120, each of which requests reading a specified length of data (i.e., firmware data) from a specified address in the SRAM. In some embodiments, the flash memory 236 in the Raspberry Pi 112 can store a file including multiple records. Each record includes information of a start address and a length. The debug application can issue JTAG commands to the SSD device 120 according to each record in the file to read a specified length of data from a specified address in the SRAM.

[0072] Step S590: In the embodiment with DRAM equipped in the memory 126, JTAG commands are emulated by the GPIO interface 260 to read data in the DRAM of the solid state disk device 120. For example, firmware data generated during boot-up or during normal operation can be stored in a specified address in the DRAM, and the debug application can issue JTAG commands to the solid state disk device 120, each of which requests reading a specified length of data (i.e. firmware data) from a specified address in the DRAM. In some embodiments, the flash memory 236 in the Raspberry Pi 112 can store a file containing multiple records. Each record contains information of a start address and a length. The debug application can issue JTAG commands to the solid state disk device 120 according to each record in the file to read a specified length of data from a specified address in the DRAM.

[0073] Step S595: JTAG commands are emulated by 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 a specified address of the auxiliary register 122 in the solid state disk device 120 can be modified to reply to the processing unit 125. In some embodiments, the first bit "FH" of the fifth double byte in the Figure 3 is set to "0" to reply to the processing unit 125.

[0074] The following shows the virtual code of the debug application:

[0075]

[0076]

[0077] The debug method of the solid state disk device implemented by the debug application as described above is more flexible than the internal circuit emulator to solve problems encountered during debugging. For example, when the firmware of the solid state disk device is stuck, the hardware registers can be quickly accessed to obtain the status of the NAND flash memory, etc.

[0078] Reference Figure 1 and Figure 2The 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 connects to the USB interface of the Raspberry Pi 112, and the UART interface of the UART recording device 150 connects to the UART interface 124 of the solid state disk device 120. The UART recording device 150 receives log information, including data, information, and / or signals, etc. from the solid state disk device 120 via its UART interface, and transmits the log information to the Raspberry Pi 112 via its USB interface. The UART recording device 150 can also include a non-volatile storage unit for storing the 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 via a voltage / level shifter for adjusting input signals from the USB interface from one voltage domain to the voltage domain of the UART interface, or adjusting input signals from the UART interface from one voltage domain to the voltage domain of the USB interface.

[0079] Referring to Figure 6 The Raspberry Pi 112 can connect to the JTAG add-on board 114 via the 40 pins of the GPIO interface 260. The JTAG add-on board 114 is responsible for transferring signals between the Raspberry Pi 112 and the JTAG connection device 140, and between the Raspberry Pi 112 and the personal computer 130. The JTAG add-on board 114 includes a GPIO interface and a type-C interface, the GPIO interface connects the Raspberry Pi 112 and the personal computer 130, and the type-C interface connects the JTAG connection device 140. Each port used in the GPIO interface can be connected to a designated port on the type-C interface via a voltage / level shifter for adjusting input signals from the GPIO interface from one voltage domain to the voltage domain of the type-C interface, or adjusting input signals from the type-C interface from one voltage domain to the voltage domain of the GPIO interface.

[0080] The JTAG connection device 140 can be considered as a JTAG adaptor, which can be a 20-pin to 10-pin, 20-pin to 8-pin, etc., responsible for transferring the JTAG commands and data from the Raspberry Pi 112 to the solid state drive device 120 via the JTAG add-on board 114, and transferring the data outputted from the solid state drive device 120 to the Raspberry Pi 112 via the JTAG add-on 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 is connected to the JTAG interface 123 of the solid state drive device 120. It is noted here that since the solid state drive device 120 needs to be tested in a test chamber in a high temperature environment, the JTAG connection device 140 is separated out, instead of being integrated into the JTAG add-on board 114, so that the solid state drive device 120 and the JTAG connection device 140 can be placed together in the test chamber for debugging operation. Referring to Figure 7The 20-pin to 10-pin example for the Type-C connector 710 includes a 20-pin connector 710 for connecting the JTAG add-on board 114 and a 10-pin connector 730 for connecting the JTAG interface 123. For example, the 9th pin of the connector 710 feeds a test clock (TCLK) signal from the JTAG add-on board 114, and the 4th pin of the connector 730 outputs the clock signal to the JTAG interface 123. The 7th pin of the connector 710 inputs a test mode select input (TMS) signal from the JTAG add-on board 114, and the 2nd pin of the connector 730 outputs the test mode select input signal to the JTAG interface 123. The 5th pin of the connector 710 inputs a test data input (TDI) signal from the JTAG add-on board 114, and the 8th pin of the connector 730 outputs the test data input signal to the JTAG interface 123. The 13th pin of the connector 730 inputs a test data output (TDO) signal from the JTAG interface 123, and the 6th pin of the connector 710 outputs the test data output signal to the JTAG add-on board 114. The 10th pin of the connector 710 inputs a test reset input (TRST) signal from the JTAG add-on board 114, and the 3rd 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 for adjusting an input signal of the Type-C interface from one voltage domain to a voltage domain of the JTAG interface or adjusting an input signal of the JTAG interface from one voltage domain to a voltage domain of the Type-C interface.

[0081] Three power relays for connecting power can be provided on the JTAG add-on board 114. Referring to FIG. 1, the JTAG add-on board 114 includes a first power relay 116, a second power relay 118, and a third power relay 120. The first power relay 116 is connected to the 1st pin of the connector 710 and the 1st pin of the connector 730. The second power relay 118 is connected to the 2nd pin of the connector 710 and the 2nd pin of the connector 730. The third power relay 120 is connected to the 3rd pin of the connector 710 and the 3rd pin of the connector 730. Figure 8GPIO interface 260, pins GPIO 12, GPIO 18 and GPIO 23 are used to control three power relays provided on the JTAG add-on board 114 to drive the relays to feed the power supply 160 to the personal computer 130. Pin GPIO 17 is connected to a signal line in the personal computer 130 to drive an LED for detecting whether the personal computer 130 is properly started. Pin GPIO 16 is connected to a specific pin of the solid state drive device 120 for driving the solid state drive device 120 into a ROM mode. Pin GPIO 22 is connected to a specific pin of the SATA interface of the solid state drive device 120 for driving the solid state drive device 120 into or out of a sleep mode. It is noted here that the sleep mode entered through the SATA interface cuts off the power supply to most of the elements in the solid state drive device 120, including the processing unit 125, to save power. In other words, when the sleep mode is entered through the SATA interface, the processing unit 125 in the solid state drive device 120 does not perform any operation. The sleep mode exited by the debug application when issuing the JTAG commands as described above is different from the sleep mode entered through the SATA interface. Pins GPIO 11, GPIO 5, GPIO 6, GPIO 13, GPIO 19 and GPIO 26 are used to connect the JTAG interface 123 in the solid state drive device 120 through the JTAG add-on board 114 and the JTAG connection device 140 for the processing unit 210 in the Raspberry Pi 112 to simulate JTAG behavior when executing the debug application, to send JTAG commands to the solid state drive device 120 through these pins, and to obtain system programming code, firmware data, etc. from the solid state drive device 120. For example, pin GPIO 5 can be used to transmit a JTAG TDI signal to the solid state drive device 120, and pin GPIO 6 can be used to receive a JTAG TDO signal from the solid state drive device 120. Details of the simulation of JTAG behavior can be found in IEEE Standard Test Access Port and Boundary-Scan Architecture, approved June 14, 2001.

[0082] Reference Figure 2Raspberry Pi 112 is a low-cost personal computer, and therefore does not have the technology to implement a low latency peripheral port (LLPP) that uses a dedicated path to access the GPIO interface. When an upper-layer debugging application desires to issue a JTAG command through the GPIO interface 260 to access the contents of the peripheral register 122 or the memory 126 in the solid state disk device 120, the lower-layer GPIO driver can sequentially issue hardware instructions and parameters to the GPIO interface 260 through the AHB / ASB 222 and the APB 224 for writing (or setting) the registers in the GPIO interface 260 corresponding to the specific pins to complete the simulation of the JTAG command. However, due to hardware limitations, some hardware instructions may be delayed from reaching the APB 224. When two hardware instructions for writing the same register in the GPIO interface 260 reach the APB controller in a very short time interval, the APB controller may misjudge the wrong hardware instruction and discard one of them, causing part of the in-system programming code, firmware data, etc. to be unable to be read back from the solid state disk device 120.

[0083] To solve the above-mentioned problems, the embodiments of the present application modify the functions in the runtime library for driving the GPIO interface 260 to complete the operation, so that the debugging application can call the functions to complete the functions mentioned above, such as issuing a JTAG command to read the identifier of the processing unit 125 of the flash controller 121 in the solid state disk device 120, stopping the processing unit 125 of the flash controller 121 in the solid state disk device 120, letting the solid state disk device 120 exit the sleep mode, reading the in-system programming code stored in the flash module 128 of the solid state disk device 120, reading the data in the SRAM, DRAM of the solid state disk device 120, etc. The runtime library is a special computer program library used by the compiler to implement the built-in function set of the programming language to provide support for the execution of the programming language. For details, please refer to Figure 9 , which are described in detail as follows:

[0084] Step S910: Receive a request for driving the GPIO interface from the debugging application, including the parameters required to complete a specific JTAG command. For example, corresponding to step S510 of Figure 5 , please refer to Figure 3 , the parameters in the request include information for reading the 0th to 7th bits of the fourth double byte in the auxiliary register 122. Corresponding to step S530 of Figure 5 , please refer to Figure 3 , the parameters in the request include information for setting the 1st bit of the fifth double byte in the auxiliary register 122 to "1".Figure 5 Step S540, refer to Figure 3 The parameters in the request include information to set the 23rd bit of the fifth double byte in auxiliary register 122 to "0". Corresponding to Figure 5 In step S550, the parameters in the request contain information about reading a specified length of data from a specified address in the flash memory module 128. Corresponding to... Figure 5 In step S580, the parameters in the request contain information about reading a specified length of data from a specified address in the SRAM. Corresponding to... Figure 5 In step S590, the parameters in the request contain information about reading a specified length of data from a specified address in the DRAM.

[0085] Step S930: Issue hardware instructions to GPIO interface 260 according to the parameters carried in the request to set the register of the GPIO pin corresponding to TDI, which is used to simulate a specific JTAG command.

[0086] Step S950: A hardware instruction is issued to the GPIO interface 260 to read the value of the register corresponding to the GPIO pin of TDI. This step inserts a hardware instruction to read the register value of the GPIO pin corresponding to TDI between the hardware instructions that set the register of the GPIO pin corresponding to TDI generated based on two requests. This prevents the APB controller from misinterpreting two hardware instructions that set the register of the GPIO pin corresponding to TDI and arrive sequentially within a very short time interval as erroneous hardware instructions. It should be noted that this step can also be executed between steps S910 and S930; the invention is not limited thereto.

[0087] Step S970: Reply with driver completion information to the debugging application.

[0088] The Raspberry Pi 112's processing unit 210 can periodically execute another function from the library to periodically drive the GPIO interface 260 to read the values ​​of the registers corresponding to the GPIO pins of TDO. The read values ​​are the execution results of simulated JTAG commands previously issued via the GPIO pins corresponding to TDI, generated and replied by the solid-state drive device 120, and may include, for example, information on the success or failure of setting the auxiliary register 122, in-system programming code read from the flash memory module 128, firmware data read from SRAM or DRAM, etc.

[0089] All or part of the steps in the method of the present application can be implemented by a computer program, such as program code in a specific programming language, etc. In addition, it can also be implemented in other types of programs as shown above. The skilled in the art can write the method of the embodiments of the present application into program code, which will not be described in detail for the sake of simplicity. The computer program implemented according to the method of the embodiments of the present application can be stored in a suitable computer-readable storage medium, such as DVD, CD-ROM, U disk, hard disk, etc., and can also be placed in a network server which can be accessed through a network (such as the Internet, or other suitable medium).

[0090] Although Figure 1 and Figure 2 include the components described above, it does not exclude the use of more other additional components to achieve better technical effects without violating the spirit of the application. In addition, although the flowcharts of Figure 5 and Figure 9 adopt a specified order for execution, the skilled in the art can modify the order between these steps without violating the spirit of the application, as long as the same effect is achieved, so the present application is not limited to only using the order as described above. In addition, the skilled in the art can also integrate several steps into one step, or perform more steps in sequence or in parallel in addition to these steps, and the present application should not be limited therefore.

[0091] The above description is only the preferred embodiments of the present application, but it is not intended to limit the scope of the present application. Any person skilled in the art can make further improvements and changes on the basis of the present application without departing from the spirit and scope of the present application, therefore the protection scope of the present application should be determined by the scope defined in the claims of the present application.

Claims

1. A debugging method for a solid-state drive device, implemented by a processing unit in a Raspberry Pi during the loading and execution of a debugging application, characterized in that, The debugging method of the solid state disk device comprises: emulating a first Joint Test Action Group (JTAG) command to the solid state disk device through a general input / output interface, for stopping running of a processing unit of a flash controller in the solid state disk device; emulating a second JTAG command to the solid state disk device through the general input / output interface, for letting the solid state disk device leave a hibernate mode; and emulating a third JTAG command to the solid state disk device through the general input / output interface, for reading data of a specified length from a specified address of a static random access memory in the solid state disk device.

2. The method of Claim 1, wherein, The first JTAG command is used for setting a first bit of a fifth double byte of an auxiliary register in the solid state disk device to "1", and the second JTAG command is used for setting a 23rd bit of the fifth double byte of the auxiliary register in the solid state disk device to "0".

3. The method of Claim 1, wherein, comprises: emulating a fourth JTAG command to the solid state disk device through the general input / output interface, for reading data of a specified length from a specified address of a dynamic random access memory in the solid state disk device.

4. The method of claim 3, wherein the method further comprises: comprises: emulating a fifth JTAG command to the solid state disk device through the general input / output interface, for reading an identifier of the processing unit of the flash controller in the solid state disk device; judging whether the identifier is correct; and when the identifier is correct, completing the emulation operations of the first JTAG command, the second JTAG command and the third JTAG command.

5. The method of claim 4, wherein the method further comprises: The fifth JTAG command is used for reading values of bits 0 to 7 of a fourth double byte of an auxiliary register in the solid state disk device.

6. The method of claim 1, wherein the method further comprises: comprises: emulating a sixth JTAG command to the solid state disk device through the general input / output interface, for reading a system-in-program code from a flash module in the solid state disk device; calculating a first check sum of the system-in-program code; and when the first check sum is correct, completing the emulation operation of the third JTAG command.

7. The debugging method of a solid state drive device according to claim 6, wherein comprises: providing second check sums of a plurality of system-in-program code versions; when the first check sum is consistent with one of a plurality of the second check sums, obtaining a memory configuration logic of a corresponding system-in-program code version; and according to the memory configuration logic, completing the emulation operation of the third JTAG command. The debugging program code is executed by a processing unit of a Raspberry Pi to implement the debugging method of the solid state disk device according to any one of claims 1 to 7.

8. A computer-readable storage medium for storing a debugging program code of a solid state disk device, the computer-readable storage medium comprising: comprises:

9. A device for debugging a solid-state drive device, disposed in a Raspberry Pi, characterized in that, a general input / output interface; and ​ ​ The processing unit simulates, through the general input / output interface, a first Joint Test Action Group command to the solid state disk device for stopping running of a processing unit of a flash controller in the solid state disk device when loading and executing the debugging application; simulates, through the general input / output interface, a second Joint Test Action Group command to the solid state disk device for letting the solid state disk device leave a hibernation mode; and simulates, through the general input / output interface, a third Joint Test Action Group command to the solid state disk device for reading data of a specified length from a specified address of a static random access memory in the solid state disk device.

10. The apparatus for debugging a solid state disk device of claim 9, wherein, The Raspberry Pi is a single-chip computer based on a Linux operating system.

11. The apparatus for debugging a solid state disk device of claim 9, wherein, The processing unit simulates, through the general input / output interface, a fourth Joint Test Action Group command to the solid state disk device for reading data of a specified length from a specified address of a dynamic random access memory in the solid state disk device.

12. The apparatus for debugging a solid state disk device of claim 9, wherein, The processing unit simulates, through the general input / output interface, a fifth Joint Test Action Group command to the solid state disk device for reading an identifier of the processing unit of the flash controller in the solid state disk device; judges whether the identifier is correct; and when the identifier is correct, completes the simulation operations of the first Joint Test Action Group command, the second Joint Test Action Group command and the third Joint Test Action Group command.

13. The apparatus for debugging a solid state disk device of claim 9, wherein, The processing unit simulates, through the general input / output interface, a sixth Joint Test Action Group command to the solid state disk device for reading a system-in-program code from a flash module in the solid state disk device; calculates a first check sum of the system-in-program code; and when the first check sum is correct, completes the simulation operation of the third Joint Test Action Group command.

14. The apparatus for debugging a solid state disk device of claim 13, wherein, It comprises: a flash memory coupled to the processing unit for storing second check sums of a plurality of system-in-program code versions; wherein the processing unit, when detecting that the first check sum is consistent with one of the plurality of second check sums, acquires memory configuration logic of a corresponding system-in-program code version; and completes the simulation operation of the third Joint Test Action Group command according to the memory configuration logic.

Images