Program Debugging:Hardware Testing

Hardware Testing

Hardware construction will be covered in more detail in Chapter 10. For the moment, we will assume that suitable hardware has been constructed for MOT1 and we are ready to test it. When the program has been fully debugged in a simulator, it can be downloaded to the chip. In some cases, the chip must be programmed before fitting, specifically 16F84A-based circuits. For most current PIC chips, however, it is preferable to program it in-circuit via the six-pin in-circuit serial programming (ICSP) connection (see Chapter 7). In-circuit debugging, as described in Chapter 7, can also be used in the final stages of testing. This allows the program to be exercised in conjunction with the final hardware, using the debugging tools in MPLAB. The state of the registers in response to real inputs can then be monitored for fault- finding purposes.

The target hardware layout and connections should be carefully checked and tested before inserting the chip. The populated circuit board should be inspected for correct assembly; wrong component orientation, solder bridges between tracks and dry joints are common faults. The connections can be buzzed out with a continuity tester and checked against the circuit diagram.

Before fitting the microcontroller chip, it is a good idea to apply power and check the rest of the circuit. Make sure the components connected to the chip outputs can be safely powered up with an open circuit input. For example, in the MOT1 circuit, the field effect transistor (FET) gate input should not be allowed to float, so there is a pull-down resistor fitted. The supply current should not be excessive, and components should be checked for overheating. The voltages at the chip power supply pins (VDD and VSS) of the chip should also be checked, as incorrect connection of the supply is likely to damage most integrated circuits.

If all is well, switch off the power and fit the chip using a suitable tool. Antistatic precautions should be observed, but PIC chips have not been found to be particularly sensitive in practice.

Make sure it is the right way round! Pin 1 should be marked on the board. Switch on and check that the chip is not overheating or drawing excessive current. If left to overheat for more than a few seconds, the chip will probably be destroyed.

Connect an oscilloscope to the output. On power-up, there should be no output from MOT1. When the ‘Run’ button is pressed, the default output waveform with a 50% MSR should be observed, running at a frequency of about 30 Hz. The speed ‘Up’ and ‘Down’ buttons should be operated to ensure that the speed control stops at the minimum and maximum value, and does not roll over from zero to full speed in one step. Note that the program algorithm does not give an MSR of 100% or 0%, but stops one step short of the maximum and minimum. Since there are 255 steps altogether, the step size is less than 1%.

The circuit should also be tested for fail-safe operation, that is, no unplanned or potentially dangerous output is caused by an incorrect input operating sequence. In this case, operating both the ‘Up’ and ‘Down’ buttons together would be an erroneous input combination, which should result in no change in speed, because the increment and decrement operations cancel out.

Other examples of potential problems that would need to be considered are input switch bounce, variation in component performance (check specifications), dynamic operation of motor, minimum MSR required to make the motor run, and so on. Complex applications are likely to have more potentially incorrect input conditions and component-related problems, but the test schedule should ideally anticipate all possible fault modes (not easy!). If the circuit is being produced on a commercial basis, a formal test schedule would be needed, and the performance certificated as being correct to the product specification.

A basic test schedule for the MOT1 program running in a PIC 16F84A has already been outlined for the simulator test in Table 9.2, and this can be adapted for hardware testing. Additional documentation should be prepared according to circumstances (education, commercial, research) to provide the application user or product customer with the relevant information on using the system.

1. Explain briefly the difference between syntax and logical program errors, and how they are detected. (4)

2. How are the following used in program debugging: single stepping, breakpoint, pin stimulus, watch window? (4)

3. An instruction in the program memory listing appears as follows:

0005 1A05 start btfsc 0x5,0x4

Explain the meaning of each of the six elements in the line, such that its correct effect can be predicted when debugging. (6)

4. State two advantages of interactive debugging using Proteus VSM. (2)

5. State two checks to be carried out before powering up a new prototype microcontroller board. (4)

1. (a) In MPLAB, open a source file edit window, enter or download the source code for MOT1 and assemble it using the Quickbuild option. Note any error messages generated. If the program assembles correctly first time, put some deliberate errors in the source code and inspect the error messages.

(b) In MPLAB, create a project MOT1, assign MOT1.ASM to the project, reassemble and test the program using scheduled inputs as described in Section 9.2.5.

2. (a) Design an application for the LPC demo board with 16F690 to control the brightness of

an LED using PWM. When the input button is pressed, the LED should increase in brightness up to a maximum and then reduce back to the minimum, so that it can be stopped at any point by releasing the button. Demonstrate correct operation in MPLAB using an asynchronous stimulus.

(b) If Proteus VSM for 16 series PIC is available, download the simulation of the LPC board to test the dimmer program interactively. Modify it so that the LED brightness is controlled by the pot.

Leave a comment

Your email address will not be published. Required fields are marked *