Micro Projects Home Page

Home

 Microprocessor Basics

Micro Basics

Site Projects

Site Projects

Construction Techniques

Construction

Programming concepts

Software

Projects

Projects

8085 page

8085 page

Fault Finding

Fault Finding

Data Sheets

Data Sheets

EEprom Programmer

Programmer

Video Information

VIDEO info

Peripheral Circuitry

Peripheral circuitry

Central Heating and Z280's

Z280 and  Central Heating  Controllers

Concluding Ideas

Concluding ideas

Links

Links

 Fault Finding

One could arguable say that the second most difficult thing in the constructing of a microprocessor based project is the hardware building and the software writing, with the actual �making it work� being the most difficult part! In order to help all those who embark on such a project, this page should offer some ideas which will lead to  successful conclusion if a logical approach is taken to the task.

HARDWARE OR SOFTWARE?

Fluke 76.5

A very good question! Thus  to identify the culprit in a newly constructed system one has to break the problem down into smaller more manageable chunks. In order to do this I would suggest that if the project seems effectively dead , even though the software might be tried and tested (like anyone following one of the site projects with the working software I have provided) it will be necessary to temporarily program a few steps into a spare EEPROM (or EPROM) to use for diagnostic purposes. One of the most useful routines is to create a simple Jump loop. In the case of  8 bit processors like the Z80, 8085, 8080 etc. and all that start their addressing at location 0000h, simply enter the absolute Jump values at locations 0000h, 0001h and 0002h, which will send the processor back to 0000h in a perpetual loop. Don�t insert any other instructions such as stack location, interrupt vectors etc. In the case of processors such as the 6809, 6800, 6502 etc. you will have to set the pointers at the top of the memory space to the beginning of the programme ROM space, and enter the loop as in the earlier case, but this time to loop back to the beginning of the ROM. In the case of a 6809 project I�ve been working on when I wrote this page, this had a 74LS138 decoder splitting the 64K address space up into 8 equal portions, thus my 8K 2764 EPROM was addressed from E000h to FFFFh. Thus in EPROM locations 1FFEh (6809 address FFFEh) there was the pointer E0h, in the EPROM location 1FFFh (6809 address FFFFh) there was the second half of the pointer 00h, with the actual JUMP instruction programmed into the EPROM at locations 0000h, 0001h and 0002h, which to the 6809 are locations E000h, E001h, and E002h. Thus in this example, the code would actually be:

6809 loc�n

EPROM

   

FFFEh

1FFEh

E0h

Program start pointer 1

FFFFh

1FFFh

00h

Program start pointer 2

       

E000h

0000h

7Eh

Jump to immediate loc�n

E001h

0001h

E0h

E0

E002h

0002h

00h

00

In the example above we see a simple diagnostic program for the 6809�s diagnostic EPROM. Note that you must have the two pointers at the top of the address space pointing to the actual program start.

USING THE DIAGNOSTIC EPROM

In the simple example below of a loop for processors including the Z80, 8085 and 8080, there is no need for pointers because the program starts at 0000h. Note that in both this, and the 6809 examples, it is not necessary to even allocate stack space in the RAM.

0000h

C3h

Jump to immediate loc�n

0001h

00h

00

0002h

00h

00

The easiest way to check if the core of a microprocessor based system is working, is to temporarily remove any other program EPROM and substitute it with the diagnostic one detailed above. Using nothing more than a good LOGIC PROBE it will be possible to see whether things are working OK. Simply connect up the power to the system and the probe, give the system a hard RESET and check for activity on the decoder lines. (The same applies if no separate decoder is being used) If all is well, there should only be activity on the EPROM enable line(s). If there is activity on any other decoded enable lines, be they for the RAM, another memory device or even an I/O enable, then something is wrong! If however, after a hard reset there is literally NO clocking activity seen by the probe (assuming that the power is actually on!) then have a look for activity on the adress lines. If there is still nothing to be seen on any of these, then have a look with the probe at the system clock lines for sign of life. Assuming that there is a clock feeding the micro, then check that the RESET line is actually in the right state and it isn�t holding the processor in the reset condition.

Of course, once you are sure that the processor is running, the ROM can be re-programmed to access each other I/O and memory address. At this point, still only address ONE device at a time (apart from the ROM), so that the �scope or logic probe can be used to check and easily identify that particular decoded route.

One last word of warning from one who speaks from bitter experience. When searching for problems using either �scope and meter probes take care! Whilst recently checking out my programmer for a mystery hiccup, (that was actually an EPROM fault) I happened to let a meter probe slip between pins 1 and 2 of the EPROM under test. Nanoseconds later the damage was done. The +21V programming voltage from Pin 1 zapped onto address bus A12 and took out a Z80, a TIL311 display and a RAM - not to mention the EPROM itself. Must be more careful next time...mutter mutter...

Picture

WHAT TEST EQUIPMENT DO I NEED THEN?

Whilst it would be all too easy to make a list of all the things one needs to debug a microprocessor based project, I know perfectly well that there are few experimenters who can afford such luxuries as a 100MHz dual band scope as an example. Obviously the more pieces of test gear one has, (with the knowledge on how to use it!) the more likely, or sooner, one is to identify any problem. The following list was thus drawn up for anyone unsure as to the best way forwards.

THE OSCILLOSCOPE

Whilst any scope is better than none, I have yet to see a modern cheap �scope the would not perform well with basic microprocessor project use. However, if the choice and the money is there, I would definitely opt for a double beam variant, before paying more for a wider bandwidth. Whilst some might be tempted to make their own - been there, done that - I would really not advise the effort. Whilst it IS possible to produce a working usable piece of test gear, it is unlikely to have a wide enough bandwidth to be seriously useful for microprocessor work. I�ve built FOUR �scopes in my time before buying my current model, all of which suffered from this problem. However, I do still have the second venture (in one of my lofts), which was loosely based on a Mullard Students Oscilloscope with er.. VALVES (tubes - to you US folks). With a bandwidth of about 15KHz it was not that useful at diagnosing problems unless they clocked at a relatively low frequency.

THE MULTIMETER

Whilst an oscilloscope can perform many of the multimeter�s functions, the meter will give more accurate voltage measurements when setting up and checking +5V power supplies for instance. Also useful for checking the  power consumption of projects and when set to the Ohms range, is invaluable for continuity checks when debugging / checking wiring. Can be useful when used in conjunction with a logic probe in a �scopeless� environment to test for �floating� (bad) logic levels. I have both analogue and digital types, even though the digital has an analogue scale. However, as cheap digital types are available for almost nothing these days, there is little excuse not to make this purchase a priority.

D32

This trusty old Telequipment D32 (purchased second-hand) is really coming to the end of it�s useful life. It has gone wrong on a number of occasions but still just about works..........

THE LOGIC PROBE

On occasions more useful than a scope, but something that can be easily constructed, or purchased at a reasonable price. A definite MUST for anyone contemplating making micro based projects who is not a �scope owner. A good probe will make an easy task of spotting very fast or infrequently occurring pulses, which a scope would need to be carefully set up for - assuming that there was a pulse to see in the first place! Perfect for probing those I/O decoders to see if a solitary pulse enables a device during a program.

MISCELLANEOUS ITEMS

Here is a collection of items that I find invaluable, and fit into the �test gear� category:

POWER SUPPLY  Rather obvious I know! +5V at up to 1 amp should be the minimum purchase. 2 amps will be useful if a lot of outboard gear is to be used, likewise a supply with a fixed +12V and maybe -12V too. A dual output +5V / plus variable might be worth considering.

LOGIC PULSER   Not really that useful though some say it is. I have one but rarely use it.

LOGIC CLIPS    These are clips that fit over the IC and bring all the pins up to the top to aid attaching test leads. Very useful though expensive if one buys all the popular permutations. A minimum should really be a 14 pin and a 24 pin. Both of which can be fitted to most devices in a micro based situation (albeit with the wrong number of pins). The �active� type of logic clip with leds in the top to show signal state is of limited use and a rather expensive luxury.

SCOPE PROBES    Buy a spare at least as there is nothing worse than having one fail in the middle of a project. For low frequency work there is little to choose between the different price bands. You need at least one switchable x10 / x1 probe as you will otherwise be  unable to use your �scopes maximim sensitivity.

To the right we have matching HP logic probe and logic pulser, as well as a selection of logic clips, plus a logic LED clip that rarely sees the light of day.

pulser clips and probe

One must not forget that some of these items are as important as test gear and are worth their weight in gold.

books..........
more books.........

http://www.hampshire-shops.co.uk