Getting New C16x Boards Going |
Your new board arrives, fully assembled, with the microcontroller soldered down directly to the board. How do you get it running?
If you have designed your system using the guidelines set out in our "Insider's Guide To Planning C166 Family Designs" then there is a good chance that the system will run straightaway. However experience has shown that it is better to take things one step at a time.
An oscilloscope is really an essential piece of kit when first testing new designs. However a proper in-circuit emulator is perhaps the greatest aid, as it allows you to effectively “sit” inside the CPU and look out across the bus - any bus errors are then obvious and a great deal of time can be saved. However, if you are lucky enough to have an AX166B in-circuit emulator ready and waiting, do not plug it into the hardware straight away and switch on - 166 bond-out chips are delicate and expensive and a major board fault could destroy the emulation device. It is a very good idea to run through the basic checks listed below before jumping in with the emulator! Engineers equipped with the AX166 non-bondout emulators can be a bit more cavalier, as these systems are rather more able to take short-circuits, Vcc on Vss pins etc.. After all, the emulation chips are just off-the-shelf parts!
It is definitely a good idea to check that the bus lines are not shorted to Vcc or Vss before powering up the board. It is also worth running a scope probe around the CPU pins to make sure that there is 5v on all the Vcc pins and 0v on all the Vss and that there are no voltages above 5v on any pin. The analog reference and ground should also be checked as it seems to be quite common for these to be omitted or connected up incorrectly. These latter two points can spell instant damage to the emulation chip in a bondout-type emulator. However, should everything look OK, now would be a good time to plug the ICE into the hardware.
For those without proper equipment, the bootstrap loader mechanism can be very useful for diagnosing hardware faults and Hitex can provide a free bootstrap-loadable diagnostics tool on request. Most initial problems are due to one or more of the reasons examined in the next few sections...
166: EBC0 or EBC1 not at correct voltage level for bus mode required. A CPU that comes out of RESET expecting an 8-bit multiplexed bus mode is not going to be much use if it reads 00 on the EBC0 & 1 pins. Also make sure that the /BUSACT pin is grounded if your design is external bus.
167: Make sure that the pull-down resistors on port 0 are correctly installed, as any mistakes here will almost certainly prevent the CPU running properly. If you have done your pull-down resistor calculations properly then, with the 167 held with the /RESIN pin low, there should be around 5v on any bus line that does not have a pull-down resistor and less than 1v on lines that have.
If your system has the EPROM socketed, then it is probably worth blowing a
simple program into the EPROMs before fitting them to the board. The program
need only wave the port 2.0 pin up and down so that something can be seen on
the ‘scope. Make sure that the while(1) { ; } loop that contains the pin
toggling code has a few NOPs in it, as if the loop is too small the 
CPU will simply jump within
the instruction pipeline and the bus will appear to be dead. In the event of
problems this inactivity could be misleading. If you are using the standard
STARTUP.A66 or CSTART.A66 C compiler start-up files, one waitstate will have
been programmed. With the 167 it is a good idea to enable the CLKOUT pin so
that the real CPU frequency can be measured, in case the PLL is not working
correctly.
When the FLASH EPROMs are soldered down you will have to use the bootstrap loader to initially get a program into the board. If at all possible, you should blow a test program into the EPROMs before they are soldered down as trying to program FLASH in-situ via the bootstrap loader on a brand new board, with a possibly unfamiliar CPU, is not easy. Overall it is best to build the first prototypes with socketed EPROMs and processor if at all possible!
Powering up the board for the first time is always a slightly anxious moment. If your board is being powered off a bench power supply, turn the current limit down to say 250mA and wind it up slowly.....apart from the obvious steps of making sure that the current consumption is not excessive and that there is no smoke, some basic steps will have to be taken to confirm that the CPU can run.
If you are lucky, putting a ‘scope onto P2.0 (or whatever your program in EPROM does) should reveal a square wave of around 2MHz. Should you be fortunate to get this, you are not quite home and dry because it is still possible for the program to run if you have the CPU running multiplexed in a non-multiplexed design. If you do not see anything then check the items in the next section. If your EPROMs are empty you ought to check them as well but, ultimately, you will have to use the bootstrap loader to program them.
Is the /RESIN pin high after powering-on? If your reset circuit is working correctly, it should be. If it is not, check the circuit! With the /RESIN pin high, the XTAL1/2 pins should show a clock signal of the frequency expected. With the 167, the amplitude should be around 4v peak to peak if the RESIN pin is high. If it is low, the clock should have an amplitude of around 4.5v peak-to-peak. Changing the state of the /RESIN pin should change the clock amplitude by a selectable amount.
The ALE pin will be running, regardless of bus mode. Its frequency will give some idea of what the CPU is doing. If it is running with a high time of 50ns and a low time of 950ns, then the program is probably not being read correctly at all from the EPROM and the CPU is still running with its default 15 wait states. You may also see the CPU reset every 6.5ms (at 20MHz) with the RESETOUT going high and low as the on-chip watchdog trips out. This will also cause the /CS0 to go high briefly. If your program successfully got through the initialisation code, the ALE will be running with a low time of around 150ns. It will thus have executed the EINIT instruction and so the /RESOUT pin will have gone high.
167: If nothing is happening on the ALE and the /RESIN is high, then check that there are no spurious pull-down resistors on P0 as these are the emulation modes and the chip will be in ONCE mode. Also check that the lower P0 lines are showing signs of activity.
Next, put the ‘scope onto the /CS0 pin (P6.0) and check that it is high when the /RESIN pin is high and goes low when /RESIN is forced low. Make sure that the /CS0 makes it to the EPROM’s /CS pin! Also check that the /RD pin is active after reset and that it is getting to the /OE on the EPROM.
If nothing unusual has been found, it is time to enlist the help of the CPU itself: if your board has provision for using bootstrap mode, then make the link or whatever the mechanism is and power -cycle the board to put the 166 into bootrap mode. If you have not provided for this, put an 8k2 pull down resistor on P0.4 (ALE for the 166) and cause a reset. If you have no RS232 driver on serial port0, you will have to add one, perhaps by putting a MAX232 on a piece of Veroboard and attaching the input lines to the S0TX and S0RX on the 166. On the connection to the PC COM port, pins 7 and 8 on the D-type connector will need to be connected together, as will 1, 4 and 6, so that the PC’s UART will not hang up.
Using the Hitex bootstrap utility, you should be able to get the CPU to report
back the contents of the SYSCON (and BUSCON0 with the 167). From the returned
value you should be able to deduce the bus mode, number of address and chip
select lines, and whether the /WRH/WRL low mode is being used. All this information
should be compared with the design specification for the board. If the bus mode
or the WRH/WRL mode are wrong, this could be the problem.
13.2 Single Chip Designs
With no external bus there is very little that can go wrong, other than the
EBC and BUSACT pins being in the wrong state for single-chip operation. You
are advised to program the FLASH CPU before committing it to the board. If not,
the bootstrap loader will have to be used to get the program in. Ask for the
Hitex bootstrap utilities to this. The only thing to be aware of is that the
FLASH EPROM itself can be damaged if you apply the 12v Vpp programming voltage
before the 5v Vcc.
Testing The System
If you have managed to get a simple port-pin toggling program going, you will have to now make sure that the /WR line(s) and chip select(s) are working by writing data into any external RAM devices or IO devices.
If you have an AX166, the View-User-SYSCON
window will show you whether the /WRCFG pull-down resistor is present or not
and will allow you to individually enable the chip selects, without using software,
so that the RAM can be enabled, for example, or the registers in an off-chip
peripheral examined. Testing these basic aspects of a new system is very time
consuming and any errors missed at this stage can have major knock-on effects
later in the project.
Even if you have not budgeted for a proper emulator for the project, we strongly recommend that you at least rent one for as long as it takes to prove that the basic hardware is working properly before the board is passed over to the software department!
To summarize, using an emulator to do the initial hardware debug is very easy as it allows you to effectively sit inside the CPU and look out through its pins. Errors such as stuck address lines, incorrect bus modes and open circuit IO pins become obvious as their side-effects can be seen directly in the instruction and memory windows. More subtle problems such as inadequate grounding or poor clock circuit design may only come to light once the processor is used to run real software...the ICEconnect method is very good for this.