Master device, slave device, and data transfer system

Abstract

The slave device continuously transmits a plurality of debug blocks to the host device at intervals determined from clock periods between the data blocks when the plurality of data blocks are transmitted and clock periods determined by a data structure of the debug blocks.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a host device, a slave device, and a data transfer system formed by these devices. BACKGROUND

[0002] In recent years, as a storage medium (slave device), an SD card (registered trademark), a high-density flash memory (registered trademark), and the like are becoming widespread. The slave device forms a data transfer system by being connected to a host device such as a personal computer, a camera, and the like, and performs transmission and reception of data within the data transfer system.

[0003] Patent Literature 1 discloses a technology in which a user can use a slave device as a bootable medium.

[0004] Further, as the access speed between the host device and the slave device increases, if the frequency of a clock signal becomes high, the host device needs to perform adjustment of the punching timing of data transmitted by the slave device. In particular, in a case where the host device is connected to an SD card, which is a slave device that is pluggable, by UHS-I (Ultra High Speed-1), which is a standard of a high-speed bus, the punching timing varies depending on the surrounding environment such as temperature and the individual differences of the host device and the SD card, and the combinations of the host device and the SD card are infinite. Therefore, if the punching timing is not adjusted every time the combination of the SD card and the host device is started, it can not be possible to correctly acquire data. In addition, the adjustment of the punching timing is also referred to as "tuning".

[0005] Patent Literature 2 discloses a technology related to tuning between a slave device and a host device.

[0006] PRIOR ART DOCUMENTS

[0007] PATENT LITERATURE

[0008] Patent Literature 1: Japanese Patent Application Publication No. 2015-62131

[0009] Patent Literature 2: Japanese Patent Application Publication No. 2016-46781 SUMMARY

[0010] Based on the technology described in Patent Literature 1, in order for the host device to correctly receive boot data from the SD card as a bootable medium using UHS-I, it is necessary to perform tuning before the boot data is received.

[0011] On the other hand, in the technology described in Patent Literature 2, the host device issues a prescribed tuning command in order to perform tuning, and receives a tuning block containing fixed data from the SD card.

[0012] However, in the boot data acquisition based on the technology described in Patent Document 1, the host device needs to drive the signal lines used for sending and receiving commands to a low level from the start of boot indication to the end of boot data transmission. Therefore, the method of issuing debug commands to acquire debug blocks as described in Patent Document 2 cannot be used.

[0013] This disclosure provides a data transmission system capable of driving signal lines used for sending and receiving commands to a low level and acquiring debug blocks.

[0014] The data transmission system disclosed herein is a data transmission system having a slave device and a master device connected to the slave device via at least a power line, a clock line, a command line, and a data line.

[0015] After connecting to the slave device, the master device supplies power to the slave device via the power line. The master device provides a first clock with a first frequency and a first voltage value to the slave device via the clock line. The master device drives the command line, which is currently high, to a low level. The master device then stops providing the first clock. With the data line driven low, the master device provides a second clock with a second frequency and a second voltage value to the slave device via the clock line.

[0016] The slave device drives the data line to a high level for a first predetermined period after the second clock is provided, and sends a plurality of debug blocks from the slave device to the master device through the data line for at least a third predetermined period during a second predetermined period.

[0017] The host device uses the debug block received via the data line to adjust the punching timing.

[0018] The host device receives boot data from the slave device via the data line and uses the received boot data to start the device.

[0019] According to this disclosure, a data transmission system is provided that can drive signal lines used for sending and receiving commands to a low level and acquire debug blocks. Attached Figure Description

[0020] Figure 1 This is a block diagram illustrating the structure of a data transmission system in which a master device is connected to a slave device.

[0021] Figure 2 This is a schematic diagram showing the timing after the power supply in the master device and slave device is turned on.

[0022] Figure 3 This is a schematic diagram of the timing sequence in the master and slave devices.

[0023] Figure 4 This is a diagram illustrating the debug block.

[0024] Figure 5 This is a schematic diagram illustrating the timing of debug block transmission and reception when using existing technology.

[0025] Figure 6 This is a schematic diagram illustrating the timing of the debug block's transmission and reception in this embodiment.

[0026] Figure 7 This is a schematic diagram illustrating the timing of transmission and reception of another debugging block in this embodiment.

[0027] Figure 8 This is a schematic diagram showing the timing after another power source in the master device and slave device is started. Detailed Implementation

[0028] Hereinafter, embodiments will be described in detail with appropriate reference to the accompanying drawings. Some unnecessary details may be omitted. For example, detailed descriptions of known items and repetitive descriptions of substantially the same structures may be omitted. This is to avoid unnecessary redundancy in the following description and to facilitate understanding by those skilled in the art.

[0029] Furthermore, the inventors have provided the accompanying drawings and the following description in order to enable those skilled in the art to fully understand this disclosure, but these are not intended to limit the subject matter of the claims.

[0030] [1. Structure of a data transmission system]

[0031] Figure 1 This is a block diagram illustrating the structure of a data transmission system in which a slave device 120 is connected to a host device 100. For example... Figure 1 As shown, the host device 100 includes at least a power supply 101 and an SoC 102. Furthermore, the SoC 102 includes at least a regulator 103, an electrical switch SW104 for selecting one of two power inputs, a host device I / F 105, and a controller 106. Additionally, the regulator 103 can also be configured externally to the SoC 102.

[0032] The master device 100 is mechanically connected to the slave device 120. In addition, the master device 100 is electrically connected to the slave device 120 via the VDD line 110, which serves as a 3.3V power supply line.

[0033] Slave device 120 includes at least SoC 121 and back-end module 126. Back-end module 126 refers to a recording medium such as flash memory or a device such as a wireless communication module. Furthermore, SoC 121 includes at least regulator 122, SW 123, slave device I / F 124, and controller 125. Additionally, regulator 122 can also be configured externally to SoC 121. In this embodiment, an SD card is used as an example of slave device 120. However, slave device 120 is not limited to SD card. High-density flash memory (registered trademark) and Memory Stick (registered trademark) are also examples of slave device 120.

[0034] The master device I / F105 and the slave device I / F124 communicate via a line including CLK (clock) line 111, CMD (command) line 112, and DAT (data) line 113. Additionally, the DAT line 113 includes four signal lines: DAT0 line 113a, DAT1 line 113b, DAT2 line 113c, and DAT3 line 113d.

[0035] [2. Operation of the data transmission system]

[0036] The following uses Figures 1 to 3 The debugging block and boot data transmission actions executed when the slave device 120 is connected to the host device 100 are explained.

[0037] Furthermore, in this description, a signal being at a low level refers to a signal with a voltage of 0V or near that level. A signal being at a high level refers to a signal with a voltage higher than that of a low level and that can be identified as such. Additionally, the voltage value representing a high level can be determined depending on the application of the data transmission system. In this embodiment, a high voltage signal of 3.3V and a low voltage signal of 1.8V are used as examples of voltage values ​​representing a high level.

[0038] Figure 2 This is a schematic diagram of the timing after the power is turned on in the host device 100 and the slave device 120.

[0039] Figure 3 This is a schematic diagram of the timing in the master device 100 and the slave device 120.

[0040] The master device 100 initiates the startup process of the slave device 120 at time t1 when the slave device 120 is connected (S300, S350). At time t2, the master device 100 supplies 3.3V power from the power supply 101. This 3.3V power is supplied to the slave device 120 via the SoC 102, regulator 103, SW 104, and VDD line 110. Further, at time t2, the master device 100 pulls up the DAT line 113 to 3.3V.Figure 2 The data is recorded as 3.3V pull-up (S302).

[0041] After the voltage applied to the VDD line 110 reaches 2.7V at timing t3, the host device 100 sends a first clock to the CLK line 111 (S304). The frequency of the first clock is 400KHz or less (first frequency). The voltage value of the first clock is 3.3V (first voltage value).

[0042] After the host device 100 sends out the first clock for a predetermined number of clock cycles (74 clock cycles or more for example), it drives the CMD line 112 to a high level at time t4 (S306), and further drives the CMD line 112 to a low level at time t5 after time t4 (S308).

[0043] The host device 100 stops sending the first clock to the CLK line 111 at time t6 following time t5 (S310). This is for sending the second clock to the CLK line 111 in subsequent processing.

[0044] If the slave device 120 does not detect that the CMD line 112 is driven to a low level (no in S352), it will remain in standby until the master device 100 receives the next instruction (S354).

[0045] When the slave device 120 detects that the CMD line 112 is driven to a low level (yes in S352), it drives the DAT line 113 to a low level after a predetermined period (S356).

[0046] During the period when the host device 100 does not provide a clock to the CLK line 111 and the CMD line 112 and DAT line 113 are at a low level ( Figure 2 During the shadow period, the system switches its transmission mode to a high-speed transmission mode (S312), which is faster than the previous mode. When the host device is the same as the SD card that serves as the slave device, an example of a high-speed transmission mode is the SDR104 mode as defined by the UHS-I standard. In SDR104 mode, the bus width for data transmission is expanded from 1 bit to 4 bits. Furthermore, in SDR104 mode, the voltage values ​​for the clock and data signals used for data transmission are 1.8V. To set the voltage values ​​of the clock and data signals to 1.8V, the controller 106 controls SW104 to change the power supply to the host device I / F105 from the 3.3V power supply directly supplied from the power supply 101 to a 1.8V power supply supplied via the regulator 103.

[0047] In addition, in SDR104 mode, the clock frequency used for data transmission is up to 208MHz.

[0048] Slave device 120 also operates during periods when no clock is supplied to CLK line 111 and CMD line 112 and DAT line 113 are low. Figure 2 During the shadow period, the transmission mode is switched to a high-speed transmission mode (SDR104 mode in this embodiment) which is faster than the previous mode (S358). At this time, the controller 125 controls SW123 so that the power supply to the slave device I / F124 is changed from the 3.3V power supply directly supplied from VDD line 110 to the 1.8V power supply supplied via the regulator 122.

[0049] The host device 100 sends a second clock to the CLK line 111 at time t7, which is 5ms after a specified period from time t6 (for example). The frequency of the second clock is 208MHz or less (second frequency). The voltage value of the second clock is 1.8V (second voltage value).

[0050] exist Figure 2 In this context, the period from time t2 to t7 is referred to as the boot initialization mode.

[0051] Slave device 120 drives DAT line 113 to a high level (1.8V) within a specified period (for example, 1ms) from time t7 at time t8. Figure 2 The voltage is recorded as 1.8V driven by the slave device (S360).

[0052] At time t9, within a specified period (100ms for example) starting from time t7, slave device 120 repeatedly sends a debug block (S362) to master device 100 via DAT line 113 a specified number of times (40 times for example).

[0053] The host device 100 receives the debug block and performs debugging (S316). Specifically, the host device 100 reads the received debug block and confirms whether the predefined debug block can be correctly obtained. Since the case of incorrect data reception means that the punching timing (sampling point) of the data relative to the reference point of each clock is not properly set, the sampling point is appropriately offset, and debugging is performed using the debug block received next time.

[0054] After sending a predetermined number of debug blocks, slave device 120 sends boot data (S364).

[0055] The host device 100 receives boot data (S318). If debugging is performed correctly in the host device 100, the boot data can be received correctly.

[0056] If the host device 100 finishes receiving boot data (Yes in S318), then at time t10, the CMD line 112 is driven high (1.8V) (S322). Thus, the debugging block and the transmission and reception of boot data end (S324). The host device 100 then initializes the backend module 126 and starts up the host device 100, etc., using the boot data. After startup, data reading and writing based on data blocks are performed between the host device 100 and the slave device 120.

[0057] If the host device 100 cannot receive the boot data correctly (no in S318), the host device 100 attempts initialization in normal mode (S320).

[0058] When the slave device 120 confirms that the CMD line 112 is driven to a high level (S366), it ends the transmission and reception of boot data (S370).

[0059] Otherwise (no in S366), the slave device 120 does not perform any special action (S368).

[0060] exist Figure 2 In this context, the period from time t7 to t10 is referred to as boot mode.

[0061] [3. Details of sending and receiving debug blocks]

[0062] [3.1. Sending and receiving debug blocks based on existing technology]

[0063] The following uses Figure 4 as well as Figure 5 This document describes the sending and receiving of debug blocks without using commands, based on existing technologies (hereinafter referred to as debug block transmission).

[0064] Figure 4 This is a diagram illustrating the detailed structure of the debug block.

[0065] like Figure 4As shown, the debug block uses four signal lines (DAT0 line 113a, DAT1 line 113b, DAT2 line 113c, and DAT3 line 113d) (collectively referred to as DAT lines 113) to send data from the slave device 120 to the master device 100. The debug block, targeting DAT0 lines 113a to DAT3 lines 113d respectively, includes a 1-bit start bit, a 128-bit tuning pattern, a 16-bit CRC (Cyclic Redundancy Check), and a 1-bit end bit, totaling 146 bits. Figure 4 The start bit and end bit are recorded as S and E respectively, but their values ​​are "0" and "1" respectively.

[0066] During the period before and after the slave device 120 sends the debug block, the slave device 120 drives the DAT line 113 to a high level. Therefore, during this period, a "1" is detected on all DAT lines in the master device 100.

[0067] After all the signal lines of DAT line 113 are "1" for a certain period of time, the host device 100 determines that it has received a debug block when it detects a "0" in all DAT lines using the start bit. Furthermore, after counting for 146 clock cycles, which is equivalent to the length of the debug block, the host device 100 determines that it has stopped receiving the debug block when it detects a "1" in all DAT lines using the end bit.

[0068] In addition, the 128-bit debugging style in this embodiment is as follows, arranged from top left to bottom right in ascending order of bit number (in hexadecimal representation).

[0069]

[0070] In addition, the above debugging style is just one example; other styles can also be used.

[0071] Figure 5 It means in Figure 2 A detailed timing diagram is provided when the debug block is sent multiple times after timer t7. As previously explained, within a specified time (1ms) after the master device 100 sends the second clock signal starting from timer t7, at timer t8, the slave device 120 drives the DAT line high. Within a specified time (100ms) from t7, at timer t9, the slave device 120 sends the first debug block (…). Figure 5 It is recorded as a debug block [1]). In addition, in Figure 5 For convenience, the clock numbers assigned to each clock after timer t9 are used to explain the timing.

[0072] The slave device 120 sends the next debug block [2] after a minimum predetermined clock period N1 (8 clocks in this embodiment) from the next clock cycle (clock number 146) after the transmission of the end bit of the debug block [1]. The aforementioned N1 is defined as the interval between the previous data block and the next data block when the slave device 120 continuously sends data blocks after startup, and is called the inter-block clock number.

[0073] After repeating the above operation a predetermined number of times (40 times in this embodiment), the slave device 120 continues to send guidance data.

[0074] At this time, the expected action in the host device 100 is to detect the start bit (i.e., "0") on all four signal lines of the DAT line 113 at clock number 0, thus detecting the received debug block [1], and to detect the end bit (i.e., "1") at clock number 145, thus detecting the end of the reception of debug block [1]. Furthermore, it correctly detects the start bit and end bit of the debug blocks repeatedly sent by the self-operated device 120 thereafter, identifying the reception of a total of 40 debug blocks.

[0075] However, at time t9 immediately after the data transmission system in this embodiment is started, the appropriate sampling point is not determined because the debugging is not yet complete. Furthermore, since there may be a delay in data transmission per DAT line, for example, the data of all DAT lines may not be detected as "0" at clock number 0. In this case, the host device 100 cannot correctly identify the debugging block [1] sent by the slave device 120 as a debugging block.

[0076] Similarly, if the host device 100 cannot correctly identify the debug block after the debug block [2], it will receive the boot data in a state where debugging cannot be performed, and will not achieve the original purpose of correctly obtaining the boot data.

[0077] Furthermore, even if the reception of debug block [1] is detected correctly by chance, the result of reading the debug pattern within debug block [1] may not be consistent with the debug pattern specified in advance and stored in the host device 100. This indicates that the sampling point when reading debug block [1] is inappropriate, and it is necessary to adjust the sampling point using debug blocks received later.

[0078] However, even if the sampling points are adjusted, it may not be possible to correctly detect the start bit of subsequent debug blocks. Furthermore, the end bit cannot be detected correctly in this case.

[0079] As a result, the host device 100 cannot correctly receive the 40 debug blocks, misidentifying a portion of the boot data of the 40 consecutive debug blocks as debug blocks, and thus cannot correctly receive the boot data itself.

[0080] [3.2. Debug block transfer in this disclosure]

[0081] The following uses Figure 4 , Figure 6 as well as Figure 7 The present disclosure describes the transmission of debug blocks.

[0082] exist Figure 4 In the debugging mode, all DAT lines for bits 7 and 8 are consecutive "0". Therefore, even if there is some data delay, the consecutive "00"s in bits 7 and 8 are punched regardless of the sampling point, so that the start bit can be detected at the latest when bit 8 is received.

[0083] Figure 6 It is a timing diagram of the host device when the start bit of the debug block [1] is detected at timing number 8.

[0084] The host device 100 detects the start bit by using consecutive "0"s in bit numbers 7 and 8 at the latest timing up to clock number 8. At this time, the host device 100 receives the debug block with a maximum delay of 8 clock cycles compared to the actual timing sent by the slave device 120 [1]. Thus, when the host device 100 receives the start bit, the maximum number of clock cycles relative to the actual timing delay is defined as the maximum receive delay clock cycle, denoted as N2. The maximum receive delay clock cycle N2 depends on the debugging style and is 8 in this embodiment.

[0085] The host device 100 counts the clock count in the receiving of the debug block [1] starting from the start bit of receiving, and the receiving of the debug block [1] ends at the timing of clock number 153.

[0086] The host device 100 expects an interval of at least N1 clock cycles between the end of receiving the previous block and the start of receiving the next block. To satisfy this requirement, the slave device 120 should allow an interval of at least 16 clock cycles (in this embodiment, 16 clock cycles) between the end of sending the previous debug block and the start of sending the next debug block.

[0087] When the master device 100 receives the debug block 8 clock cycles later than the actual start bit, clock number 153 corresponds to the end bit. At this time, the slave device 120 drives all DAT lines high, so the master device 100 can correctly detect the data of clock number 153 as the end bit ("1").

[0088] Figure 7 It is a timing diagram of the host device when the timing block [1] is detected at clock number 0.

[0089] In this case, the host device 100 is able to detect the true start bit of the debug block [1] sent by the slave device 120. Therefore, the end of the debug block [1] can also be detected at clock number 145.

[0090] Furthermore, under the above circumstances, the probability that the debugging pattern sent by the self-generated device 120 is consistent with the pattern previously maintained in the host device 100 increases, and the possibility of judging that the sampling point is appropriate is higher.

[0091] In addition, the slave device 120 sends the next debug block [2] after an interval of more than 16 clock cycles from the end of the debug block [1]. However, from the perspective of the master device 100, the next debug block is received after more than 8 clock cycles from the end bit of the debug block [1], so no problem occurs.

[0092] In addition, such as Figure 6 As shown, when the host device 100 receives a debug block with a true start bit delay of 8 clock cycles, the received debug pattern is inconsistent with the one previously maintained by the host device 100. In this case, the host device 100 determines that the sampling point is inappropriate and performs debugging based on the corrected sampling point until the next debug block reception.

[0093] Furthermore, the timing-related values ​​(time, clock count, etc.) in this embodiment are just one example; other values ​​are also possible. Additionally, the maximum receive delay clock count N2 depends on the data structure of the debugging style used.

[0094] Furthermore, in this embodiment, the description assumes that the DAT line is driven high at time t8 and a (second) clock is continuously provided thereafter. However, the host device 100 needs to read the debug block and retain the received debug block until the determination of whether the end is an appropriate sampling point. However, if the host device 100 does not perform any control, there is a concern that it might receive the next debug pattern and overwrite the previously received debug block. In this case, the host device 100 temporarily stops providing the clock after a number of clock cycles shorter than the clock number defined by N1 has elapsed since the end bit was received, thereby suppressing the transmission of the next debug block from the slave device 120 (this also applies to...). Figure 6 , Figure 7 (any of the following situations).

[0095] Furthermore, in this embodiment, the high-speed bus used is set to SDR104 mode, but this also applies to other modes. Additionally, depending on the high-speed bus mode, there are modes that do not require debugging (such as DDR50 mode). In this case, the slave device 120 sends debug blocks multiple times, but the master device 100 can discard the received debug blocks and not perform debugging. Alternatively, when a bus mode that does not require debugging is set, the slave device 120 can send only boot data without sending debug blocks.

[0096] Furthermore, in this embodiment, the number of debug blocks sent by the slave device 120 is set to 40, but it can also be other fixed values. Alternatively, the master device 100 can record the number of debug blocks sent in a predetermined non-volatile memory area within the slave device 120, and the slave device 120 can send the aforementioned number of debug blocks upon the next startup.

[0097] Alternatively, before the master device 100 finishes receiving 40 debug blocks, the debugging process can end, for example, by driving the CMD line 112 high to abort the transmission of subsequent debug blocks to the slave device 120. In this case, the master device 100 can then drive the CMD line 112 low again to indicate the transmission of boot data to the slave device 120.

[0098] Furthermore, this disclosure is as follows Figure 8 As shown, this also applies when, for example, the host device 100 issues an initialization instruction command to the slave device 120 between time t4 and t5, thereby instructing the transmission of the debug block and boot data.

[0099] [4. Summary]

[0100] As described above, embodiments have been illustrated as examples of the technology disclosed in this application. The technology in this disclosure is not limited to this and can also be applied to embodiments with modifications, substitutions, additions, omissions, etc.

[0101] The host device and slave device of this disclosure are interconnected at least via a power line, a clock line, a command line, and a data line. Furthermore, the data transmission system of this disclosure includes the interconnected host device and slave device. After being connected to the slave device, the host device provides power to the slave device via the power line, provides a first clock with a first frequency and a first voltage value to the slave device via the clock line, drives the command line (which is currently high) to a low level to stop the provision of the first clock, and provides a second clock with a second frequency and a second voltage value to the slave device via the clock line while the data line is driven low. If, during a first predetermined period after the provision of the second clock, the data line is driven high, multiple debug blocks are sent from the slave device via the data line at intervals at least a third predetermined period for a second predetermined period to adjust the punch timing. Boot data is received from the slave device via the data line, and the received boot data is used for startup. This allows the signal lines used for sending and receiving commands to be driven low and debug blocks to be acquired.

[0102] Furthermore, in the host device, slave device, and data transmission system of this disclosure, the third predetermined period is determined by the clock period between data blocks during the continuous transmission of data blocks after the slave device is started, and the clock period determined by the data structure of the block pattern included in the debug block. Therefore, the host device 100 can reliably capture the start bit of the debug block to receive a predetermined number of debug blocks. Thus, the host device 100 can correctly receive the data of the subsequent predetermined number of debug blocks as boot data.

[0103] Furthermore, in the host device, slave device, and data transmission system of this disclosure, the block pattern includes at least a continuous bit string of "00" or "11". The start bit of the debug block is determined by detecting the bit string of "0" or bit string of "1". Therefore, the host device 100 can reliably capture the start bit of the debug block to receive a predetermined number of debug blocks. Thus, the host device 100 can correctly receive the data of the predetermined number of debug blocks as boot data.

[0104] Industrial availability

[0105] This disclosure can be applied to slave devices and corresponding host devices, such as SD cards, and data transmission systems having said host devices and slave devices.

[0106] -Symbol Explanation-

[0107] 100 Main Units

[0108] 101 Power Supply

[0109] 102 SoC

[0110] 103 Regulator

[0111] 104 SW

[0112] 105 Main Unit I / F

[0113] 106 Controller

[0114] 110 VDD line

[0115] 111 CLK line

[0116] 112 CMD line

[0117] 113 DAT line

[0118] 113a DAT0 line

[0119] 113b DAT1 line

[0120] 113c DAT2 line

[0121] 113d DAT3 line

[0122] 120 Slave Device

[0123] 121 SoC

[0124] 122 Regulator

[0125] 123 SW

[0126] 124 Slave Device I / F

[0127] 125 Controller

[0128] 126 Backend module.

Claims

1. A host device connected to a slave device through at least a power line, a clock line, a command line, and a data line, providing power to the slave device through the power line after being connected to the slave device, providing a first clock having a first frequency and a first voltage value to the slave device through the clock line, driving the command line at a high level to a low level, stopping the provision of the first clock, providing a second clock having a second frequency and a second voltage value to the slave device through the clock line in a state where the data line is driven to a low level, performing debugging that adjusts a punch timing using a plurality of debugging blocks transmitted through the data line at intervals of at least a third prescribed period from the slave device within a second prescribed period in a case where the data line is driven to a high level within a first prescribed period after the provision of the second clock, receiving boot data from the slave device through the data line, and performing booting using the received boot data, the third prescribed period being determined by a clock period between data blocks at a time of continuous transmission of data blocks after booting of the slave device and a clock period determined by a data structure of a block pattern included in the debugging blocks.

2. The host device according to claim 1, wherein the block pattern includes at least a continuous bit string "00" or "11", and a start bit of the debugging block is determined by detecting a bit string "0" or a bit string "1".

3. A slave device connected to a host device through at least a power line, a clock line, a command line, and a data line, receiving power from the host device through the power line after being connected to the host device, receiving a first clock having a first frequency and a first voltage value from the host device through the clock line, the command line being driven to a low level from a high level, the provision of the first clock being stopped, receiving a second clock having a second frequency and a second voltage value from the host device through the clock line in a state where the data line is driven to a low level, transmitting a plurality of debugging blocks to the host device through the data line at intervals of at least a third prescribed period within a second prescribed period in a case where the data line is driven to a high level within a first prescribed period after the provision of the second clock, the third prescribed period being determined by a clock period between data blocks at a time of continuous transmission of data blocks after booting of the slave device and a clock period determined by a data structure of a block pattern included in the debugging blocks.

4. The slave device according to claim 3, wherein the block pattern includes at least a continuous bit string "00" or "11".

5. A data transfer system having a slave device and a host device connected to the slave device through at least a power line, a clock line, a command line, and a data line, the host device providing power to the slave device through the power line after being connected to the slave device, the host device providing a first clock having a first frequency and a first voltage value to the slave device through the clock line, the command line being driven to a low level from a high level, the provision of the first clock being stopped, a second clock having a second frequency and a second voltage value being provided to the slave device through the clock line in a state where the data line is driven to a low level, debugging that adjusts a punch timing being performed using a plurality of debugging blocks transmitted through the data line at intervals of at least a third prescribed period from the slave device within a second prescribed period in a case where the data line is driven to a high level within a first prescribed period after the provision of the second clock, boot data being received from the slave device through the data line, and booting being performed using the received boot data, the third prescribed period being determined by a clock period between data blocks at a time of continuous transmission of data blocks after booting of the slave device and a clock period determined by a data structure of a block pattern included in the debugging blocks. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ the host device drives the command line at a high level to a low level, the host device stops the supply of the first clock, the host device supplies a second clock having a second frequency and a second voltage value to the slave device through the clock line in a state where the data line is driven to a low level, the slave device drives the data line to a high level for a first prescribed period after the supply of the second clock, and transmits a plurality of debug blocks from the slave device to the host device through the data line for a second prescribed period with an interval of at least a third prescribed period, the host device performs debugging of adjusting punch timing using the plurality of debug blocks received through the data line, the host device receives boot data from the slave device through the data line and performs booting using the received boot data, the third prescribed period is determined by a clock period between data blocks at the time of continuous transmission of data blocks after the booting of the slave device and a clock period determined by a data structure of a block pattern included in the debug block.

6. The data transfer system according to claim 5, wherein the block pattern includes at least a continuous bit string "00" or "11", the host device judges a start bit of the debug block by detecting a bit string "0" or a bit string "1".

Images