Apparatus and system for solid state drive device debugging

Abstract

The present invention relates to a device and a system for debugging a solid state disk device, the device comprising: a joint test action group add-on board; and a Raspberry Pi. The Raspberry Pi comprises a general purpose input output interface coupled to the joint test action group add-on board; and a processing unit coupled to the general purpose input output interface. The processing unit is configured to emulate a plurality of joint test action group commands to the solid state disk device through the general purpose input output interface to dump data generated by the solid state disk device during runtime of the solid state disk device. Using the device as described above can reduce the cost required to debug the solid state disk device.

Description

Technical Field

[0001] This invention relates to storage devices, and in particular, to an apparatus and system for commissioning solid-state drive devices. Background Technology

[0002] Currently, using commercially available in-circuit emulators (ICEs) to collect firmware status data for solid-state disks (SSDs) encounters the following problems: ICEs cannot be controlled to meet all application environments. For example, when an ICE stops, it performs certain fixed operations, such as stopping the CPU in the SSD, causing the host to be unable to access data on the SSD. Current ICEs are slow to respond when address changes are needed to read hardware registers, for example, when engineers want to access hardware registers to know the NAND flash status while the firmware is stuck. Furthermore, ICEs are very expensive, and debugging costs need to be further reduced. Therefore, this invention proposes an apparatus and system for debugging solid-state disk devices to solve the problems described above. Summary of the Invention

[0003] In view of this, how to alleviate or eliminate the deficiencies in the aforementioned related areas is a problem that needs to be solved.

[0004] This invention relates to an apparatus for commissioning a solid-state drive (SSD) device, comprising: a Joint Test Workgroup add-in board; and a Raspberry Pi. The Raspberry Pi includes a General Purpose Input / Output (GPIO) interface coupled to the Joint Test Workgroup add-in board; and a processing unit coupled to the GPIO interface. The processing unit is used to simulate multiple Joint Test Workgroup commands to the SSD device via the GPIO interface to dump data generated during SSD device operation.

[0005] The present invention also relates to a system for debugging a solid-state drive device, comprising the apparatus for debugging a solid-state drive device as described above.

[0006] One advantage of the above embodiments is that using the device described above can reduce the cost required for debugging solid-state drive devices.

[0007] Other advantages of the present invention will be explained in more detail below in conjunction with the accompanying drawings. Attached Figure Description

[0008] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0009] Figure 1 This is a block diagram of a debugging system according to an embodiment of the present invention.

[0010] Figure 2 This is a system architecture diagram of a Raspberry Pi according to an embodiment of the present invention.

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

[0012] Figure 4 This is a schematic diagram of the bit allocation of the secondary control register and the secondary control register of the Argonaut Reduced Instruction Set Computing Machine (Argonaut RISC Machine, ARM) according to an embodiment of the present invention.

[0013] Figure 5 This is a flowchart of a method for debugging a solid-state drive device implemented by a debugging application according to an embodiment of the present invention.

[0014] Figure 6 This is a pin diagram of the General-Purpose Input / Output (GPIO) interface of a Raspberry Pi according to an embodiment of the present invention.

[0015] Figure 7 This is a schematic diagram of a JTAG 20-pin to 10-pin converter in a Joint Test Action Group (JTAG) connection device according to an embodiment of the present invention.

[0016] Figure 8 This is a pin diagram of the GPIO interface of a Raspberry Pi according to an embodiment of the present invention.

[0017] Figure 9 This is a flowchart illustrating a method for debugging a solid-state drive device using functions from a runtime library, according to an embodiment of the present invention.

[0018] Explanation of reference numerals in the attached figures

[0019] 10. Debugging System

[0020] 110 Debugging Device

[0021] 112 Raspberry Pi

[0022] 114 JTAG Add-on Board

[0023] 120 Solid State Drive Device

[0024] 121 Flash Controller

[0025] 122 Auxiliary Register

[0026] 123 JTAG Interface

[0027] 124 UART interface

[0028] 125 processing units

[0029] 126 Memory

[0030] 127 Device Interface

[0031] 128 Flash Module

[0032] 129 Host Interface

[0033] 130 personal computers

[0034] 132 Device Interface

[0035] 140 JTAG Connector

[0036] 150 UART recording device

[0037] 160 power supply

[0038] 210 Processing Unit

[0039] 222 AHB / ASB

[0040] 224 APB

[0041] 230 Memory Controller

[0042] 232 SRAM

[0043] 234 DRAM

[0044] 236 flash memory

[0045] 260 GPIO interface

[0046] 270 USB interface

[0047] 280 Wi-Fi module

[0048] 290 Bluetooth module

[0049] 710 20-pin connector

[0050] 730 10-pin connector Detailed Implementation

[0051] The embodiments of the present invention will be described below with reference to the accompanying drawings. In these drawings, the same reference numerals denote the same or similar components or method flows.

[0052] It must be understood that the use of terms such as "comprising" or "including" in this specification is intended to indicate the presence of specific technical features, values, method steps, work processes, components and / or components, but does not preclude the addition of more technical features, values, method steps, work processes, components, or any combination thereof.

[0053] In this invention, terms such as "first," "second," and "third" are used to modify components in the claims and are not used to indicate a priority order, a precedence relationship, or that one component precedes another, or the chronological order of the execution of method steps. They are only used to distinguish components with the same name.

[0054] It's important to understand that when a component is described as "connected" or "coupled" to another component, it can be a direct connection or coupling to other components, and there may be intermediate components. Conversely, when a component is described as "directly connected" or "directly coupled" to another component, there are no intermediate components. Other terms used to describe relationships between components can be interpreted similarly, such as "between" versus "directly between," or "adjacent" versus "directly adjacent," and so on.

[0055] refer to Figure 1 The diagram shows a block diagram of the debugging system. The debugging system 10 includes a debugging device 110, a solid-state drive (SSD) 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 SSD device 120 is mounted on the personal computer 130. The debugging device 110 draws 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 SSD device 120.

[0056] Solid-state drive device 120 is a device to be debugged, comprising at least a flash controller 121 and a flash module 128. The flash module 128 provides a large storage space, typically hundreds of gigabytes or even several terabytes, for storing large amounts of user data, such as high-resolution images and videos. The flash controller 121 includes a host interface 129 for connecting to a personal computer 130 to obtain power. The host interface 129 can communicate with the device interface 132 in the personal computer 130 via communication protocols 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), and Embedded Multi-Media Card (eMMC). The flash memory controller 121 also includes a processing unit 125, which is interconnected via a bus architecture and host interface 121, auxiliary register (AUX) 122, JTAG interface 123, UART interface 124, memory 126, and device interface 127 to transmit and receive 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, a multiprocessor with parallel processing capabilities, a graphics processor, or other processors with computing power), and accesses the auxiliary register 122 and memory 126 during firmware instruction execution to read and store 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, abbreviated as ARC) or an Argonaut RISC Machine (abbreviated as ARM). The contents stored in the auxiliary register 122 and memory 126 are important references during debugging. In some embodiments, memory 126 may be static random access memory (SRAM).In other embodiments, memory 126 may include static random access memory and dynamic random access memory (DRAM). Device interfaces 127 can communicate with each other using double data rate (DDR) communication protocols, such as Open NAND Flash Interface (ONFI), DDR Toggle, or other communication protocols, and communicate with flash memory module 128 for reading, writing, or erasing data. Solid-state drive device 120 is connected to JTAG connection device 140 via JTAG interface and to UART recording device 150 via UART interface 124.

[0057] Auxiliary register 122 may conform to ARC, ARM, or other specifications. For example, Figure 3 Displaying ARCompact released in April 2008 TM A summary of the auxiliary register set excerpted from pages 45-46 of Instruction Set Architecture: Programmer's Reference. Figure 4 Part A shows the Cortex products published from 2010 to 2011. TM The bit allocation is excerpted from pages 4-41 of the Technical Reference Manual for R5 and Cortex-R5F revision:r1p1. Figure 4 Part B shows the Cortex products published from 2010 to 2011. TM The bit allocation of the secondary auxiliary control register is excerpted from pages 4-45 of the Technical Reference Manual for R5 and Cortex-R5F revision:r1p1.

[0058] This invention uses a debugging device 110, a JTAG connection device 140, and a UART recording device 150 to replace a commercially available in-circuit emulator (ICE), thereby avoiding the technical problems that arise from using ICE to debug the hardware and software in the solid-state drive device 120. Furthermore, the cost of the debugging device 110, JTAG connection device 140, and UART recording device 150 is lower than the cost of using ICE for debugging.

[0059] 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.

[0060] refer to Figure 2The system architecture of the Raspberry Pi 112 is described below. The processing unit 210 can be an ARM architecture processor and performs the functions described below when executing instructions for debugging applications. Tool developers can use Python to write debugging applications. 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. AHB / ASB 222 and APB 224 are connected by a bridge 220. AHB / ASB 222 is used to meet the high-speed bandwidth requirements between the processing unit 210 and SRAM 232, DRAM 234, or flash memory 236 via memory controller 230. APB 224 is suitable for low-power peripheral devices such as GPIO interface 260, USB interface 270, Wi-Fi module 280, Bluetooth module 290, etc. The processing unit 210 can simulate JTAG behavior through the GPIO interface 260 and receive UART data, signals, and information through the USB interface 270. The processing unit 210 can receive debugging requests from a remote end via the Wi-Fi module 280 or the Bluetooth module 290, and load and execute the debugging application in response to the debugging request.

[0061] This invention provides a debugging method for a solid-state drive (SSD) device, implemented when the processing unit 210 loads and executes the program code of a debugging application. (See reference) Figure 5 The details are as follows:

[0062] Step S510: Simulate a JTAG command via GPIO interface 260 to read the identifier (ID) of the processing unit 125 of the flash controller 121 in the solid-state drive device 120, such as ARC ID, ARM ID, etc. For example, the identifier of the processing unit 125 can be read from a specified address in the auxiliary register 122 in the solid-state drive device 120. In some embodiments, the ARC ID is recorded in... Figure 3 The fourth double byte in the sequence is “ARCVER[7:0]”, bits 0 through 7.

[0063] Step S520: Determine if the identifier is correct. If the identifier is correct, the process continues to step S530. Otherwise, the process continues to step S525. This step is used to confirm whether the debugging device 110 is correctly connected to the solid-state drive device 120. If the processing unit 210 cannot read the identifier of the processing unit 125 of the flash memory controller 121 from the solid-state drive device 120, it means that the debugging device 110 is not correctly connected to the solid-state drive device 120.

[0064] Step S525: The debugging application replies with error information to the upper layer that launched the debugging application. The upper layer can then drive the display to show the error information, or store the error information in flash memory 236 to inform the engineer that an error occurred during debugging.

[0065] Step S530: Simulate a JTAG command via 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 in the auxiliary register 122 in the solid-state drive device 120 can be modified to stop the processing unit 125. In some embodiments, the value of the auxiliary register 122 in the solid-state drive device 120 can be modified to stop the processing unit 125. Figure 3 The first bit "FH" of the fifth double byte is set to "1" to stop processing unit 125.

[0066] Step S540: Simulate a JTAG command via GPIO interface 260 to cause the solid-state drive device 120 to exit sleep mode. For example, the value of a specified address in auxiliary register 122 in the solid-state drive device 120 can be modified to cause the solid-state drive device 120 to exit sleep mode. In some embodiments, the value of the auxiliary register 122 in the solid-state drive device 120 can be modified to exit sleep mode. Figure 3 The 23rd bit "ZZ" of the fifth double byte is set to "0" to allow the solid-state drive device 120 to exit hibernation mode.

[0067] Step S550: Simulate JTAG commands via GPIO interface 260 to read the in-system programming (ISP) code of the solid-state drive device 120. For example, the ISP code can be stored at a specified address in the flash memory module 128. The debugging 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 contains host commands issued by the host, such as host read, write, and erase commands, or background operations, such as garbage collection (GC), wear leveling (WL), read reclaim, and read refresh. The host commands are commands specified by standards organizations, such as Universal Flash Storage (UFS), Non-Volatile Memory Express (NVMe), and Open-channel Solid State Disk (SSD).

[0068] Step S560: Calculate the checksum of the system's programming code. Specific algorithms can be used to calculate the checksum when debugging applications, such as MD5, SHA1, SHA256, SHA512, etc.

[0069] Step S570: Determine if the checksum is correct. If the identifier is correct, the process continues to step S580. Otherwise, the process continues to step S525. In some embodiments, the manufacturer of the flash controller 121 of the solid-state drive device 120 may provide different versions of 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 in-system programming code versions. The debugging application can compare the checksum generated in step S560 with the checksum stored in flash memory 236. If the checksum generated in step S560 matches one of the multiple checksums stored in flash memory 236, the checksum is determined to be correct (that is, the in-system programming code executed in the flash controller 121 of the solid-state drive device 120 can be identified as a specific in-system programming code version). Otherwise, the checksum is determined to be incorrect (that is, the in-system programming code executed in the flash controller 121 of the solid-state drive device 120 is incorrect or cannot be identified). This step, besides determining the correctness of the checksum, also reveals the version of the in-system programming code executed in the flash memory controller 121. It's important to note that different versions of the in-system programming code have different memory configuration logic used to store variables, data tables, data to be written to the flash memory module 128, and data read from the flash memory module 128. In other words, debugging the application requires knowing the memory configuration logic before it can correctly dump the necessary data from the correct addresses of the memory 126 (including SRAM and DRAM) in the solid-state drive device 120.

[0070] Step S580: Simulate JTAG commands via GPIO interface 260 to read data from the SRAM of solid-state drive device 120. For example, firmware data generated during power-on or normal operation can be stored at a specified address in the SRAM. The debugging application can issue multiple JTAG commands to the solid-state drive device 120, each JTAG command requesting to read a specified length of data (i.e., firmware data) from the specified address in the SRAM. In some embodiments, the flash memory 236 in the Raspberry Pi 112 can store a file containing multiple records. Each record contains information about its start address and length. The debugging application can issue JTAG commands to the solid-state drive device 120 based on each record in the file to read a specified length of data from the specified address in the SRAM.

[0071] Step S590: In embodiments where memory 126 includes DRAM, a JTAG command is simulated via GPIO interface 260 to read data from the DRAM of solid-state drive device 120. For example, firmware data generated during power-on or normal operation may be stored at a specified address in the DRAM. The debugging application may issue multiple JTAG commands to solid-state drive device 120, each JTAG command requesting to read a specified length of data (i.e., firmware data) from the specified address in the DRAM. In some embodiments, flash memory 236 in Raspberry Pi 112 may store a file containing multiple records. Each record contains information about its start address and length. The debugging application may issue a JTAG command to solid-state drive device 120 based on each record to read a specified length of data from the specified address in the DRAM.

[0072] Step S595: Simulate a JTAG command via GPIO interface 260 to respond to the processing unit 125 of the flash controller 121 in the solid-state drive device 120. For example, the value of a specified address in the auxiliary register 122 in the solid-state drive device 120 can be modified to respond to the processing unit 125. In some embodiments, the value of the auxiliary register 122 in the solid-state drive device 120 can be modified to respond to the processing unit 125. Figure 3 The first bit "FH" of the fifth double byte in the response is set to "0" to reply to processing unit 125.

[0073] The following shows the dummy code for debugging the application:

[0074]

[0075]

[0076] The debugging method for solid-state drives (SSDs) implemented by the debugging application as described above offers greater flexibility than internal circuit emulators in resolving debugging issues. For example, it allows for rapid access to hardware registers to obtain the status of the NAND flash memory when the SSD firmware is stuck.

[0077] refer to Figure 1 and Figure 2The UART recording device 150 includes a USB interface, a UART interface, a controller, and 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 drive device 120. The UART recording device 150 receives log information, including data, information, and / or signals, from the solid-state drive 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 may also include a non-volatile memory unit for storing the log information received from the solid-state drive 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, which adjusts the input signal from the USB interface from one voltage domain to the voltage domain of the UART interface, or vice versa.

[0078] refer to Figure 6 The Raspberry Pi 112 can be connected to a JTAG add-in board 114 via 40 pins of the GPIO interface 260. The JTAG add-in 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 personal computer 130. The JTAG add-in board 114 includes a GPIO interface and a Type-C interface. The GPIO interface connects the Raspberry Pi 112 and the personal computer 130, while 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. The voltage / level shifter is used to adjust the input signal from the GPIO interface from one voltage domain to the Type-C interface voltage domain, or vice versa.

[0079] JTAG connector 140 can be considered a JTAG adapter, such as a 20-pin to 10-pin or 20-pin to 8-pin adapter, responsible for transmitting JTAG commands and data simulated by the Raspberry Pi 112 via the JTAG add-on board 114 to the solid-state drive 120, and transmitting data output from the solid-state drive 120 to the Raspberry Pi 112 via the JTAG add-on board 114. JTAG connector 140 includes a Type-C interface, a JTAG interface, a controller, and memory. The Type-C interface of JTAG connector 140 can connect to the Type-C interface of the JTAG add-on board 114, and the JTAG interface of JTAG connector 140 can connect to the JTAG interface 123 of the solid-state drive 120. It is important to note here that, since the solid-state drive device 120 needs to be tested in a high-temperature environment in the test chamber, separating the JTAG connector 140, rather than integrating it onto the JTAG add-on board 114, allows the solid-state drive device 120 and the JTAG connector 140 to be placed together in the test chamber for debugging. (Reference) Figure 7An example of a 20-pin to 10-pin adapter includes a 20-pin connector 710 for connecting to a JTAG add-in board 114 and a 10-pin connector 730 for connecting to a JTAG interface 123. For example, pin 9 of connector 710 receives a test clock (TCLK) signal from the JTAG add-in board 114, while pin 4 of connector 730 outputs a clock signal to the JTAG interface 123. Pin 710 receives a test mode select input (TMS) signal from the JTAG add-in board 114, while pin 2 of connector 730 outputs a TMS signal to the JTAG interface 123. Pin 5 of connector 710 receives a test data input (TDI) signal from the JTAG add-in board 114, while pin 8 of connector 730 outputs a TDI signal to the JTAG interface 123. Pin 13 of connector 730 receives a test data output (TDO) signal from JTAG interface 123, while pin 6 of connector 710 outputs a test data output signal to JTAG add-in board 114. Pin 10 of connector 710 receives a test reset input (TRST) signal from JTAG add-in board 114, while pin 3 of connector 730 outputs a test reset input signal to JTAG interface 123. Each of the aforementioned pins of connector 710 can be connected to a designated pin of connector 730 via a voltage / level converter used to adjust the input signal of the Type-C interface from one voltage domain to the voltage domain of the JTAG interface, or vice versa.

[0080] The JTAG add-in board 114 can be configured to connect three power relays. (See reference) Figure 8The example pin-out diagram of GPIO interface 260 shows pins GPIO12, GPIO18, and GPIO23 used to control three power relays on JTAG add-in board 114 to feed power from power supply 160 to personal computer 130. Pin GPIO17 is connected to the signal line driving LEDs in personal computer 130 to detect whether personal computer 130 has started correctly. Pin GPIO16 is connected to a specific pin of solid-state drive device 120 to drive solid-state drive device 120 into ROM mode. Pin GPIO22 is connected to a specific pin of the SATA interface of solid-state drive device 120 to drive solid-state drive device 120 into or out of sleep mode. It is important to note that entering sleep mode via SATA interface cuts off power to most components in solid-state drive device 120 (including processing unit 125) to save power. In other words, when entering sleep mode via SATA interface, processing unit 125 in solid-state drive device 120 does not perform any operations. The sleep mode exited by the debugging application when issuing a JTAG command, as described above, is different from the sleep mode entered via the SATA interface. Pins GPIO11, GPIO5, GPIO6, GPIO13, GPIO19, and GPIO26 are connected to the JTAG interface 123 in the solid-state drive device 120 via the JTAG add-on board 114 and JTAG connection device 140. These pins allow the processing unit 210 in the Raspberry Pi 112 to simulate JTAG behavior when executing the debugging application, sending JTAG commands to the solid-state drive device 120 and retrieving system-in-system programming code, firmware data, etc., from the solid-state drive device 120. For example, pin GPIO5 can be used to transmit the JTAG TDI signal to the solid-state drive device 120, and pin GPIO6 can be used to receive the JTAG TDO signal from the solid-state drive device 120. For details on the simulation of JTAG behavior, refer to the IEEE Standard Test Access Port and Boundary-Scan Architecture, approved June 14, 2001.

[0081] refer to Figure 2The Raspberry Pi 112 is a low-cost personal computer and therefore does not implement low-latency peripheral port (LLPP) technology. It uses a dedicated path to access the GPIO interface. When an upper-layer debugging application wants to send a JTAG command through the GPIO interface 260 to access the contents of peripheral register 122 or memory 126 in the solid-state drive device 120, the lower-layer GPIO driver can sequentially send hardware instructions and parameters to the GPIO interface 260 through AHB / ASB 222 and APB 224 to write (or set) the registers corresponding to specific pins in the GPIO interface 260 to simulate the JTAG command. However, due to hardware limitations, some hardware instructions may arrive at the APB 224 with a delay. When two hardware instructions for writing to the same register in the GPIO interface 260 arrive at the APB controller within a very short time interval, the APB controller may misinterpret them as incorrect hardware instructions and discard one of them, causing some in-system programming code, firmware data, etc., to be unable to be read back from the solid-state drive device 120.

[0082] To address the aforementioned problems, this embodiment of the invention modifies a function in the runtime library. This function drives the GPIO interface 260 to perform operations, allowing the debugging application to call this function to accomplish the functions described above. For example, it can issue a JTAG command to read the identifier of the processing unit 125 of the flash controller 121 in the solid-state drive device 120, stop the processing unit 125 of the flash controller 121 in the solid-state drive device 120, allow the solid-state drive device 120 to exit hibernation mode, read the system-in-system programming code stored in the flash memory module 128 of the solid-state drive device 120, and read data from the SRAM and DRAM of the solid-state drive device 120. A runtime library is a special computer program function library used by a compiler to implement a collection of built-in functions of a programming language, providing runtime support for that programming language. (Reference) Figure 9 The details are as follows:

[0083] Step S910: Receive a request from the debug application to drive the GPIO interface, containing the parameters required to complete a specific JTAG command. For example, corresponding to... Figure 5 Step S510, refer to Figure 3 The parameters in the request include information for reading bits 0 through 7 of the fourth double byte in auxiliary register 122. Corresponding to Figure 5 Step S530, refer to Figure 3 The parameters in the request include information to set the first bit of the fifth double byte in auxiliary register 122 to "1". Corresponding to 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.

[0084] 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.

[0085] 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.

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

[0087] 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.

[0088] All or part of the steps in the method described in this invention can be implemented by a computer program, such as program code in a specific programming language. Furthermore, it can also be implemented in other types of programs as shown above. Those skilled in the art can write the methods of the embodiments of this invention into program code, which will not be described further for the sake of brevity. The computer program implementing the method according to the embodiments of this invention can be stored on a suitable computer-readable storage medium, such as a DVD, CD-ROM, USB flash drive, or hard disk, or placed on a network server accessible via a network (e.g., the Internet, or other suitable media).

[0089] Although Figure 1 and Figure 2 It includes the components described above, but does not preclude the use of other additional components to achieve better technical results without violating the spirit of the invention. Furthermore, although... Figure 5 and Figure 9 The flowchart describes the steps in a specified order. However, those skilled in the art can modify the order of these steps to achieve the same effect without violating the spirit of the invention. Therefore, this invention is not limited to using only the order described above. Furthermore, those skilled in the art can integrate several steps into one step, or perform more steps sequentially or in parallel, in addition to these steps, and this invention should not be limited thereto.

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

Claims

1. A device for debugging a solid-state drive (SSD) device, characterized in that, include: A joint test workgroup add-in board is coupled to the solid-state drive device; as well as Raspberry Pi, includes: The first general-purpose input / output interface is coupled to the joint test workgroup add-on board; as well as The processing unit, coupled to the first general-purpose input / output interface, is used to simulate multiple joint test workgroup commands to the solid-state drive device through the first general-purpose input / output interface, so as to dump data generated by the solid-state drive device during operation. The processing unit is configured to: simulate a first joint test group command via the first general-purpose input / output interface and transmit it to the solid-state drive device to stop the operation of the processing unit of the flash memory controller in the solid-state drive device; simulate a second joint test group command via the first general-purpose input / output interface and transmit it to the solid-state drive device to cause the solid-state drive device to exit hibernation mode; and simulate a third joint test group command via the first general-purpose input / output interface and transmit it to the solid-state drive device to read data of a specified length from a specified address in the static random access memory of the solid-state drive device.

2. The apparatus for debugging a solid-state drive device as described in claim 1, characterized in that, The Raspberry Pi is a single-chip computer based on the Linux operating system.

3. The apparatus for debugging a solid-state drive device as described in claim 1, characterized in that, The joint test workgroup add-on board includes: A second general-purpose input / output interface is coupled to the first general-purpose input / output interface; and A first Type-C interface is coupled to a second Type-C interface in the Joint Test Workgroup connector, such that the Joint Test Workgroup command is sent to the solid-state drive device through the Joint Test Workgroup connector.

4. The apparatus for debugging a solid-state drive device as described in claim 3, characterized in that, The joint test workgroup add-on board includes: A relay, connected to a power source, is provided for the Raspberry Pi to control the relay via the second general-purpose input / output interface to feed the power source to the personal computer and the solid-state drive device, wherein the personal computer is connected to the solid-state drive device.

5. The apparatus for debugging a solid-state drive device as described in claim 1, characterized in that, The Raspberry Pi includes: A wireless communication module, coupled to the processing unit, is used to receive debugging requests from a remote location. The processing unit loads and executes a debugging application in response to the debugging request, for dumping data generated during the operation of the solid-state drive (SSD).

6. The apparatus for debugging a solid-state drive device as described in claim 1, characterized in that, The processing unit is used to simulate a fourth joint test group command to the solid-state drive device through the first general-purpose input / output interface, and to read data of a specified length from a specified address of the dynamic random access memory in the solid-state drive device.

7. A system for debugging solid-state drive devices, characterized in that, include: The debugging device includes: Joint Test Working Group add-on boards include: First general-purpose input / output interface; and The first Type-C interface; and Raspberry Pi, including: A second general-purpose input / output interface is coupled to the first general-purpose input / output interface; and The processing unit, coupled to the second general-purpose input / output interface, is used to simulate multiple joint test workgroup commands through the second general-purpose input / output interface and transmit them to the solid-state drive device via the joint test workgroup add-on board, so as to dump data generated by the solid-state drive device during operation from the solid-state drive device through the second general-purpose input / output interface, and Joint test workgroup connector, including: A first joint test workgroup interface is coupled to a second joint test workgroup interface in the solid-state drive device; and The second Type-C interface is coupled to the first Type-C interface in the joint test workgroup add-on board. The joint test group command is received from the first pin of the second type-C interface and transmitted to the solid-state drive device via the second pin of the first joint test group interface. The data generated during the operation of the solid-state drive device is received from the third pin of the first joint test group interface and transmitted to the joint test group add-on board via the fourth pin of the first joint test group interface.

8. The system for debugging a solid-state drive device as described in claim 7, characterized in that, include: A general-purpose asynchronous transceiver recording device, comprising: A first general-purpose asynchronous transceiver interface is coupled to a second general-purpose asynchronous transceiver interface in the solid-state drive device; as well as The first Universal Serial Bus (USB) interface is coupled to the second USB interface in the Raspberry Pi. Used to transmit log information received from the solid-state drive device to the Raspberry Pi.

9. The system for debugging a solid-state drive device as described in claim 7, characterized in that, The Raspberry Pi includes: A wireless communication module, coupled to the processing unit, is used to receive debugging requests from a remote location. The processing unit loads and executes a debugging application in response to the debugging request, for dumping data generated during the operation of the solid-state drive (SSD).

10. The system for debugging a solid-state drive device as described in claim 7, characterized in that, The processing unit simulates a first joint test group command and sends it to the solid-state drive (SSD) via the second general-purpose input / output interface (GPIO) to stop the operation of the processing unit of the flash memory controller in the SSD; simulates a second joint test group command and sends it to the SSD via the second GPIO to cause the SSD to exit hibernation mode; and simulates a third joint test group command and sends it to the SSD via the second GPIO to read data of a specified length from a specified address in the static random access memory (SRAM) of the SSD.

11. The system for debugging a solid-state drive device as described in claim 10, characterized in that, The processing unit simulates a fourth joint test group command to the solid-state drive device through the second general-purpose input / output interface, for reading data of a specified length from a specified address in the dynamic random access memory of the solid-state drive device.

Images