JP2002007162A - Debug method for printed mounted board and printed mounted board - Google Patents

Abstract

PROBLEM TO BE SOLVED: To search for the cause of any failure related with start by inspecting respective parts on a printed mounted board even when the program of a product itself is not started. SOLUTION: When a board 10 to be inspected is not started in the start process of a program to be used for a product, the process is switched to a debug program having the start process for giving start the highest priority as much as possible so that the cause of the failure of hardware related with the start can be estimated. That is, the debug method of board 10 to be inspected for operating the setting of control devices arranged in the board 10 to be inspected from a terminal 1 through a serial communication port 3 comprises a step for operating initialization necessary for the control of the control devices using the serial communication port 3 after a power is supplied to the board 10 to be inspected and a step for operating the setting of the control devices from the terminal 1 through the serial communication port 3 after the initialization is operated, and the control devices are started.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for debugging a printed circuit board, and more particularly to a debugging method and a debugging method effective in pursuing a cause when the printed circuit board does not operate as expected in a mass production process of the printed circuit board. The present invention relates to a printed circuit board on which measures have been taken.

[0002]

2. Description of the Related Art If a product does not operate normally or does not start up due to an assembly failure or a component failure during mass production of a printed circuit board, the product used for the mounting board does not start up. A method has been used in which an in-circuit tester, which is an inspection jig for individual inspection, is used, or an electric oscilloscope is used to actually check the presence or absence of an abnormality in a basic electric signal with an oscilloscope. In addition, when the cause is not known even by using these methods, a debugging method using an inspection jig called an in-circuit emulator (hereinafter abbreviated as ICE) has been used conventionally.

[0003] The ICE is a microcomputer system development device for controlling software while monitoring the operation of the CPU so as to reliably debug software and hardware in a short period of time. By connecting this ICE to the printed circuit board, which is the board to be inspected, the CPU of the board to be inspected can be controlled to be in an activated state by an arbitrary activation process different from the activation program of the product. Therefore, by using this ICE, it is possible to pursue the cause, which is hardware debugging, even when the startup program of the board to be inspected does not start.

As a prior art in a debugging system, Japanese Patent Laid-Open Publication No. Hei 4-332501 discloses that debug software and application software are transferred to a readable / writable memory (RAM) called a shadow memory to debug the application software. The technology is disclosed. Further, Japanese Patent Application Laid-Open No. 11-65884 discloses a technique in which debug software written in a flash ROM is started, and application software stored in the flash ROM is debugged by a communication terminal device. Further, JP-A-9-34864 discloses that
The terminal (port) of the single chip microcomputer itself does not use the rare communication dedicated port, and the ACL terminal and TE
A dedicated external connection terminal called ST terminal is provided on the board,
By controlling externally with a dedicated terminal device,
A technique for debugging application software stored in a built-in ROM of a single-chip microcomputer has been disclosed.

[0005]

However, the above-described method using an oscilloscope is not necessarily suitable for debugging in a mass production process because judgment must be made by carefully looking at each electric signal. In addition, the aforementioned I
When using CE, if there are several types of CPUs, the ICE itself must be prepared for each CPU.
Since this ICE is very expensive, it is not appropriate to prepare it exclusively as an inspection jig for a mass production process of a product because the cost increases. In the case where ICE is used, it is necessary that terminals for connection to the ICE be provided on the printed circuit board. In the prototype stage, it is possible to mount sockets and connectors etc. dedicated to ICE connection that can be connected with wiring such as probes on the printed circuit board, but when shifting from trial production to mass production, due to cost reduction etc. In many cases, sockets and connectors are not mounted, and there has been a problem that the ICE connection itself becomes difficult.

Also, Japanese Patent Application Laid-Open Nos. 4-332501, 11-65884, and 9-348
In the technology disclosed in Japanese Patent Application Publication No. 64, it is possible to debug application software, but it is not possible to perform inspection for defective assembly or defective components of the mounting board itself. For this reason, if the product startup program itself used on the mounting board does not start up and the product does not operate normally, it is not possible to estimate the location of the defect, and it is not possible to specify the location of the defect. It was difficult.

SUMMARY OF THE INVENTION The present invention has been made to solve the above technical problems, and an object of the present invention is to inspect individual components on a mounting board at low cost in a mass production process. It is in. Another object of the present invention is to enable individual component inspection on a mounting board even when a product program itself does not start, and to pursue a cause of a defect related to the start.

[0008]

SUMMARY OF THE INVENTION In view of the foregoing, the present invention provides a method of starting up a printed circuit board that is not started up in a process of starting up a program used in a product. It is characterized in that it is configured to switch to a debug program having a process and to start it, and to be able to infer the cause of a hardware failure related to the start. That is, the present invention relates to a method for debugging a printed circuit board, which sets a control device provided on the mass-produced printed circuit board from an external terminal via a communication port, the method comprising: After turning on the power to the board, performing initialization settings necessary for controlling the control device using the communication port,
And setting the control device from the terminal via the communication port after performing the initialization setting and starting the control device.

Here, the step of performing the initialization setting is characterized by starting the debugging software stored in the memory of the printed circuit board and performing the initialization setting. This is preferable in that the increase in cost can be prevented, and the debugging of the printed circuit board can be facilitated. Further, the step of setting the control device is characterized in that, after initialization setting relating to activation is performed, a command / status group for setting the control device is sequentially transmitted and received from the terminal according to a predetermined procedure. It can be.

On the other hand, if the present invention is grasped from another viewpoint, the present invention relates to a method of debugging a printed circuit board in which a product program itself does not start, and gives priority to starting from a debug program stored in a memory. A minimum initialization is performed by the started process, and each device is set based on the debug program after starting by the start process according to the actual operation specification of the printed circuit board. In this minimum initialization, for example, a minimum group of registers required to activate the main routine of the debug program is set.

The present invention also provides a printed circuit board having a plurality of devices, wherein debugging is performed by a communication terminal connected thereto, wherein the communication port is connected to an interface with the communication terminal; An input port for recognizing switching to an application mode, a memory storing debug software including a boot process with priority given to booting, and a CPU for controlling a plurality of devices. When switching to the debug mode is recognized, the initialization setting relating to the start-up process is executed by the debug software stored in the memory.

Here, the memory stores debug software separately from the application software of the product. The debug software includes a debug program having a boot process with priority given to boot, and a plurality of devices after boot. And a program for arbitrarily initializing. The memory in which the debug software is stored is realized by, for example, a ROM or the like. Can also be configured. However, storing in the same ROM or the like is preferable in that cost can be reduced as compared with the case where another ROM or the like is provided.

[0013]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below in detail based on an embodiment shown in the accompanying drawings. First Embodiment FIG. 1 is a diagram for explaining the overall configuration of a system for inspecting a substrate to be inspected according to a first embodiment. In the figure, reference numeral 1 denotes a terminal for executing various settings of the device by operating from the outside. As the terminal 1, for example, a general-purpose personal computer or the like can be used. Reference numeral 10 denotes a substrate to be inspected, which is a printed circuit board for which operation guarantee is required in a mass production process. In the present embodiment, when connecting the terminal 1 and the substrate 10 to be inspected,
A serial communication cable 2 such as 2C, RS422, or JTAG is employed.

A CPU 12 as a central processing unit is provided on a substrate to be inspected 10 which is a printed circuit board. FIG. 1 shows one example of the CPU 12, but a plurality of CPUs may be loaded. This CPU1
2 has a serial communication port 3 connected to a serial communication cable 2 connected to the terminal 1. The use of the serial communication port 3 facilitates control from the terminal 1 composed of a general-purpose personal computer or the like, but the port used is not particularly limited, and a parallel port may be used.

The substrate 10 to be inspected is provided with a mode switch 11 for switching between a debug mode and an application mode. The CPU 12 has an input port 4 for receiving a signal from the mode changeover switch 11. Further, the inspection target substrate 10 includes
ROM 1 that stores both programs of application software that operates in a normal product state and debug software used to debug substrate under test 10
3. The main memory includes a RAM 14 that can store programs, data, and the like, and a plurality of devices 1 to n that function to operate the substrate under test 10. CPU 12, ROM 13, RAM 14, device 1
To n are connected by an address bus and a data bus, respectively.

As described above, in addition to the application software, debugging software is also burned into the ROM 13 in the present embodiment. Whether to activate the application software or the debug software incorporated in the ROM 13 is controlled by the mode switch 11. That is, the mode changeover switch 11 is
When it becomes N and the state of the input port 4 becomes, for example, Low, the CPU 12 is started by the debug software in the ROM 13. Also, the mode switch 11 is turned off.
When the state of the input port 4 is, for example, High, the CPU 12 can read the application software in the ROM 13 and operate.

Next, the flow of processing in this embodiment will be described. FIGS. 2A and 2B are flowcharts for explaining the overall processing in the first embodiment.
FIG. 2B shows a flow of processing when all necessary minimum settings are collectively performed at one time. FIG. 2B shows a case where only initial setting of the input port 4 is performed and the initial setting is reduced as much as possible. The flow of the processing is shown.

In FIG. 2A, first, after the power is turned on, the minimum necessary settings are made immediately after the start of the system of the substrate 10 to be inspected (step 101). The minimum necessary setting will be described later in detail, but is a setting that enables the substrate to be inspected 10 to be activated and allows operation from the external terminal 1. For example, settings such as setting of a width as a bus size, setting of a port, and the like cannot read even the serial communication port 3 without it. Next, whether or not the input port 4 is at the low level is determined based on a signal from the mode changeover switch 11 (step 102). If the level input to the input port 4 is Low, the debug software stored in the ROM 13 is activated, and the terminal 1 sets each device (devices 1 to n) (step 10).
3). That is, the terminal 1 freely sets each device (devices 1 to n) via the serial communication cable 2 and the communication port 3 as needed. Also, input port 4 is H
In the case of the high level, application software of a normal product stored in the ROM 13 is started, and each device (device 1 to device 1) provided on the inspection target substrate 10 is activated.
The automatic setting of n) is performed (step 104). When the settings of all the devices provided on the substrate to be inspected 10 are completed normally, a series of processes of initial setting when the substrate to be inspected 10 is started is completed.

In the processing flow shown in FIG. 2B, first, after the power is turned on, the setting for the CPU 12 to recognize the input port 4 is made immediately after the start of the system of the substrate 10 to be inspected. (Step 111). Next, whether or not the input port 4 is at the low level is determined based on a signal from the mode changeover switch 11 (step 11).
2). If the level input to the input port 4 is Low, the minimum necessary setting is performed (step 11).
3). When the necessary minimum settings are completed, the debug software stored in the ROM 13 is activated, and the terminal 1 sets each device (devices 1 to n) (step 114). That is, the terminal 1 can freely connect each device via the serial communication cable 2 and the communication port 3 as necessary.
(Devices 1 to n) are set. Input port 4 is High
If the level is the h level, the normal application software stored in the ROM 13 is started, and
Automatic setting of each device (devices 1 to n) provided on 0 is performed (step 115). When the settings of all the devices provided on the substrate to be inspected 10 are completed normally, a series of processes of initial setting when the substrate to be inspected 10 is started is completed.

As described above, according to the processing shown in FIG. 2B, the setting of the input port 4 is performed first regardless of the normal mode or the debug mode. After that, the mode is determined, and in the case of the debug mode,
Necessary minimum settings such as reading of ports and writing of data, which are essential conditions for activation, are performed. After that, the CPU 12 is sequentially set by the operation from the terminal 1 connected to the serial communication port 3, and the hardware debugging process is executed. In the case of the normal mode, application software for a product is started, various settings are made, and normal processing is executed.

Next, the minimum necessary settings shown in step 101 of FIG. 2A and step 113 of FIG. 2B will be described in detail. FIG. 3 is a table showing registers that are set at the time of startup in the present embodiment as minimum settings. As described above, the minimum required setting is an essential setting for the CPU 12 to recognize a device provided on the substrate to be inspected 10 in order to activate the substrate to be inspected 10. Therefore, at least, an input port 4 for receiving a signal from the mode changeover switch 11;
It is necessary to recognize only the serial communication port 3 that enables operation from the terminal 1. In the present embodiment, BCR1 (bus control register 1), PACRL2 (port A / IO register L
2), PBCR1 (port B control register 1),
PBCR2 (Port B control register 2), PDC
RH1 (Port D control register H1), PDCR
H2 (port D control register H2), SMR0
(Serial mode register 0), BRR0 (Bit rate register 0), SCR0 (Serial control register 0), SSR0 (Serial status register 0)
Zero registers are provided.

In the setting data of BCR1, the bus size is set, and in the setting data of PACRL2, TXD0 is set.
(Input port for receiving data of CPU), RXD0 (CP
U transmission data output port) is set. PBC
The setting data of R1 sets the use of pins 21 and 20 of the address bus, and the setting data of PBCR2 sets the use of pins 19 and 16 of the address bus. The setting data of the PDCRH1 uses the pins 31 and 24 of the data bus, and the setting data of the PDCRH2 uses the pins 23 and 16 of the data bus. Hereinafter, from SMR0 to SSR0, a part related to communication is set. In the setting data set in SMR0, communication specifications such as data length are set, and in the setting data of BRR0, when the operation clock of the CPU 12 is 28 MHz, the communication speed is set to 9600 bps. In addition, transmission / reception is permitted by the setting data of SCR0, and the status is cleared by the setting data of SSR0.

The size of the bus and the setting of the communication port which are set at the time of starting the board to be inspected 10 differ depending on the type of the board and the like. For this reason, the settings for the bus size and the communication port cannot always be used in the initial state of the CPU 12, so a necessary minimum setting stage as shown in the present embodiment is required. The above-mentioned minimum setting shown in FIG. 3 is an example, and when all the initial setting values of the CPU 12 are the same as the setting data, the above-mentioned minimum setting becomes unnecessary.

When all of the above minimum necessary settings have been completed, the board to be inspected 10, which is a printed circuit board, is
Can be controlled via the serial communication cable 2. If the startup is terminated while the minimum settings described above are being performed and the application software and debug software cannot be started, a fundamental process will be required during the process with the minimum settings. It can be assumed that there is a problem. Whether or not all necessary minimum settings have been completed normally can be determined based on whether or not communication with the terminal 1 can be performed from the serial communication port 3 of the CPU 12 via the serial communication cable 2.

When the CPU 12 is started by application software in a normal product state, since the setting after the minimum setting is set one after another at an early timing, it is determined where the problem is. It is difficult. Therefore, the debug software according to the present embodiment temporarily stops when all the necessary minimum settings have been completed by the first-stage debug program, and then stops the program.
The terminal is connected to the serial communication port 3 of the CPU 12 so as to execute the debug program at the lower stage and to set each device (devices 1 to n) one by one.

Here, an example of values sequentially set by the terminal 1 will be described. FIG. 4 is a chart showing an example of a setting file sequentially set by the terminal 1. Here, BCR is used as a register set in this embodiment.
2 (bus control register 2), WCR1 (wait control register 1), DCR (DRAM area control register), RTCSR (refresh timer control / status register), RTCNT (refresh timer counter), RTCOR (refresh time constant register), PBCR2 (Port B control register 2) and PACRH (port A control register H).

The setting data of BCR2 sets an idle cycle, and the setting data of WCR1 sets a wait (W
AIT) setting and DCR setting data set the DRAM area. The refresh setting is performed in the setting data of the RTCSR, the refresh counter is cleared in the setting data of the RTCNT, and the refresh time is set in the setting data of the RTCOR. Further, P
In the setting data of BCR2, RDWR, CASH, CAS
L and RAS are set, and W is set in the PACRH setting data.
RHH, WRHL, CASHH, CASHL, WAIT
Is set.

As described above, according to the present embodiment, the application software and the debug software are stored in the ROM 13 in advance.
Then, by burning and storing, it is possible to easily enter the application mode and the debug mode by switching the mode switch 11. Further, since the debug software stored in the ROM 13 is stored in advance, the substrate 10 to be inspected can be debugged without using a special inspection jig such as an oscilloscope or an ICE. Further, by not using the ICE, the labor required for debugging can be greatly reduced, and the cost can be greatly reduced. In the process of sequentially setting the register values shown in FIG. 4 from the terminal 1, if there is a device that does not move halfway, it can be easily inferred that there is a problem with the parts in that part, The location can be specified.

Second Embodiment In the first embodiment, an example has been described in which the application software and the debug software are stored together in the ROM 13 on the board under test 10. In the second embodiment, a system for inspecting a substrate to be inspected by storing only normal application software without incorporating debug software into the ROM will be described. Note that the same components as those in the first embodiment are denoted by the same reference numerals, and detailed description thereof is omitted here.

FIG. 5 is a diagram illustrating the overall configuration of a system for inspecting a substrate to be inspected according to the second embodiment. In the figure, reference numeral 20 denotes a substrate to be inspected, which is a printed circuit board for which operation guarantee is required in a mass production process. The substrate to be inspected 20 includes a central processing unit C
PU 22, application ROM 23 incorporating application software that operates in a normal product state on inspected substrate 20, application ROM 2
3, a ROM socket 24 to which a debugging ROM 26 to be described later can be connected, a RAM 25 as a main memory capable of storing programs and data,
Devices 1 to n required for operation of the substrate to be inspected 20
It has. Each block on the substrate to be inspected 20 is
They are connected by an address bus and a data bus.

Reference numeral 21 denotes a debugging board. The debugging board 21 includes a debugging ROM 26 in which debugging software is incorporated, an OR gate 27, and a mode switch 28. This debug ROM2
6 can be connected to the ROM socket 24 of the board under test 20 instead of the application ROM 23. The debugging ROM 26 is a ROM socket 2
Terminals other than the / CE terminal attached immediately below 4 are wired in parallel. The mode switch 28 is configured to be turned on in the debug mode and turned off in the normal application mode. When the application ROM 23 is mounted on the ROM socket 24, the mode changeover switch 28 is set to the OFF side. The contents of the debug software stored in the debug ROM 26 are the same as those of the first embodiment.
And the same except for the mode switching process.

FIG. 6 is a diagram for explaining the configuration of the inspection jig according to the second embodiment. In FIG.
Reference numeral 0 denotes a microswitch, which functions as the mode switch 28 shown in FIG. The inspection jig includes a substrate holding lid 41, a fixture upper plate 42, a pin socket 43, a conversion substrate 44, and a fixing spacer 45. The microswitch 40 is connected to the substrate 2 to be inspected.
0 ROM socket 24 for application ROM2
When 3 is mounted, the lever is raised by its height, and when it is not mounted, the lever is lowered, thereby enabling mode switching. The terminal of the debug ROM 26 provided on the debug board 21 is connected to the input terminal of the ROM socket 24 via the conversion board 44 and the pin socket 43. The distance between the fixture upper plate 42 and the debug board 21 can be kept constant by the fixing spacer 45.

First, RO for an application is set on an inspection jig.
When the substrate to be inspected 20 to which the M23 is not mounted is mounted, the lever of the microswitch 40 is lowered, and the mode changeover switch 28 is turned on to enter the debug mode. In this debug mode, the debug program is read from the debug ROM 26 provided on the debug board 21 via the conversion board 44 and the pin socket 43, and the debug processing is executed. On the other hand, when the test substrate 20 on which the application ROM 23 is mounted is mounted on the inspection jig, the micro switch 40 is changed depending on the thickness of the application ROM 23.
Is raised, and the mode changeover switch 28 is turned off to enter the application mode.

As described above, according to the inspection jig shown in FIG. 6, it is not necessary to provide a special connector or the like at the time of inspecting the mass-produced substrate 20 to be inspected. The power can be turned on and the debug program can be executed. Further, by automatically determining whether or not the application ROM 23 is mounted on the ROM socket 24, the logic signal Low / High can be automatically switched, so that the assignment of the ROM address is not duplicated. Control is also possible at the same time. Further, it is possible to eliminate the trouble of inserting and removing the ROM socket 24 between the application ROM 23 and the debug ROM 26.

FIG. 7 is a flowchart for explaining the processing in the second embodiment. First, after the power is turned on, the system of the inspection target substrate 20 is started. Here, it is determined by the mode changeover switch 28 whether or not the application ROM 23 is mounted on the board 20 to be inspected (step 201). If the application ROM 23 is not mounted on the test board 20, the debug mode is set, the debug program stored in the debug ROM 26 is started, and the minimum necessary settings are made (step 202). Thereafter, based on the debugging program stored in the debugging ROM 26, the terminal 1 sets each device (devices 1 to n) (step 203). That is, the terminal 1 freely sets each device (devices 1 to n) via the serial communication cable 2 and the communication port 3 as needed. In step 201, the application ROM 23
If it is determined that is implemented, the application software of a normal product stored in the application ROM 23 is started, and the automatic operation of each device (devices 1 to n) provided on the substrate 20 to be inspected is performed. The setting is executed (step 204). When the setting of all the devices provided on the inspection target substrate 20 ends normally, a series of processes of the initial setting at the time of starting the inspection target substrate 20 ends.

As described above, according to the second embodiment, unlike the first embodiment, there is no need to simultaneously incorporate application software and debug software into the ROM on the mounting board. By dividing the application software and the debug software in this way, R
The storage capacity of the OM (the application ROM 23) can be reduced, and there is no need to provide an extra branch on the board to be inspected 20, which is a printed circuit board.

FIG. 8 is a diagram for explaining another system configuration for inspecting a substrate to be inspected in the second embodiment. In the system shown in FIG. 8, the debugging ROM 35 is attached to the board 30 to be inspected during debugging without using the ROM socket 24 provided in the system configuration of FIG. An application ROM 32 in which application software to be installed is incorporated is mounted. In order to achieve this debugging method, in the system shown in FIG. 8, a CPU 31 as a central processing unit, a logic circuit unit 33, a program and data as main memory , And devices 1 to n required for the operation of the substrate 30 to be inspected.

In this system, the inspection target substrate 30
, An OR gate 36 and a mode changeover switch 37 are provided. Debug ROM used for debugging
As described above, the debug program 35 has a two-stage configuration of a minimum necessary setting and an initial setting according to the actual operation specifications of the board. The mode changeover switch 37 is configured to be turned on in the debug mode and turned off in the normal application mode. In this system, the mode changeover switch 37, O
By providing the R gate 36 and the logic circuit unit 33,
The presence or absence of the debug ROM 35 is determined, and the debug RO
It is possible to switch between the debug mode in which the M35 operates and the application mode in which the application ROM 32 operates. According to the system configuration as shown in FIG. 8, it is possible to switch between debug software and application software without using a relatively expensive ROM socket 24.

As described in detail above, according to the first and second embodiments, the case where the product program itself does not start up, and the case where the startup process and hardware problems such as component failure are closely related. However, it is possible to appropriately pursue the cause of the failure without using the ICE or the like. In addition, the debug program used in each embodiment is switched and used when needed separately from the product program, and has a two-stage configuration by giving top priority to starting the printed circuit board. That is, activation R
The minimum necessary settings are made by the initialization in the OM, and after the startup in the boot ROM, the communication terminal arbitrarily performs initialization such as the initial setting according to the actual operation specifications of the board. Thus, by recognizing how far and how the initialization and operation have been performed, it is possible to appropriately infer the defective portion.

[0040]

As described above, according to the present invention,
Even when the product program itself does not start, it is possible to inspect individual components on the printed circuit board, and to pursue a cause of trouble related to the start.

[Brief description of the drawings]

FIG. 1 is a diagram for describing an overall configuration of a system for inspecting a substrate to be inspected according to a first embodiment;

FIGS. 2A and 2B are flowcharts for explaining the overall processing in the first embodiment.

FIG. 3 is a table showing registers set at the time of startup according to the present embodiment as minimum settings.

FIG. 4 is a table showing an example of a setting file sequentially set by a terminal.

FIG. 5 is a diagram illustrating an overall configuration of a system for inspecting a substrate to be inspected according to a second embodiment.

FIG. 6 is a diagram for explaining a configuration of an inspection jig according to a second embodiment.

FIG. 7 is a flowchart illustrating a process according to the second embodiment.

FIG. 8 is a diagram for explaining another system configuration for inspecting a substrate to be inspected in the second embodiment.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Terminal, 2 ... Serial communication cable, 3 ... Serial communication port, 4 ... Input port, 10 ... Board to be inspected, 11 ...
Mode switch, 12 CPU, 13 ROM, 1
4 RAM, 20 board to be inspected, 21 board for debugging, 22 CPU, 23 ROM for application,
24 ROM socket, 25 RAM, 26 debugging ROM, 27 OR gate, 28 mode switch, 30 substrate to be inspected, 31 CPU, 32 application ROM, 33 logic circuit, 34 RAM,
35: Debug ROM, 36: OR gate, 37: Mode switch, 40: Micro switch, 41: Board holding lid, 42: Fixture upper plate, 43: Pin socket, 44: Conversion board, 45: Fixing spacer

Claims (6)

[Claims] 1. A method of debugging a printed circuit board, wherein setting of a control device provided on a mass-produced printed circuit board from an external terminal via a communication port is performed, the method comprising: After turning on the power to the board, performing an initialization setting required for controlling the control device using the communication port, and after performing the initialization setting and starting the control device, from the terminal through the communication port Performing the setting of the control device by using the above method. 2. The printed circuit board according to claim 1, wherein, in the step of performing the initialization setting, the initialization setting is performed by starting debug software stored in a memory of the printed circuit board. How to debug. 3. The step of setting the control device includes, after initialization setting relating to startup is performed, sequentially executing a command / status group for setting the control device from the terminal according to a predetermined procedure. The method for debugging a printed circuit board according to claim 1, wherein the debugging is performed. 4. A method for debugging a printed circuit board on which a product program itself does not start, wherein a minimum initialization is performed by a start process giving priority to starting from a debug program stored in a memory. A method for debugging a printed circuit board, wherein each device is set in accordance with an actual operation specification of the printed circuit board after being activated by the activation process based on a program. 5. A printed circuit board comprising a plurality of devices and being debugged by a communication terminal connected thereto, comprising: a communication port connected to an interface with the communication terminal; a debug mode and an application mode. An input port for recognizing switching, a memory storing debug software including a boot process that prioritizes booting, and a CPU for controlling the plurality of devices. When the switch to the debug mode is recognized, an initialization setting related to the start-up process is executed by the debug software stored in the memory. 6. The memory stores the debug software separately from application software of a product, wherein the debug software includes a debug program including the start process with priority given to start.
6. The printed circuit board according to claim 5, further comprising: a program for arbitrarily initializing the plurality of devices after being activated.