What I can do if I want to test the microcontroller?
Electronic – Is it feasible to test microprocessor/microcontroller
test
Related Solutions
A network analyzer is ideal to test your first two circuits. The network analyzer applies a swept-frequency RF stimulus to one port of your circuit and measures the response at the same or a different port. A scalar network analyzer only measures the response magnitude and a vector network analyzer measures both magnitude and phase.
The key to obtaining accurate measurements from a network analyzer is calibration. Essentially this means testing known standard devices to determine the performance of the network analyzer, then using this knowledge to correct the measurements you do later on your device under test (DUT). More and more complex types of network analyzer allow testing more standard devices to obtain more and more accurate final measurements. Your network analyzer will come with detailed instructions on how to do the different calibrations that it supports.
So for a butterworth filter, you calibrate your network analyzer, then connect your DUT, measure the response, and check whether it matches the ideal response of a butterworth filter. If you also have specs on return loss, you could check those at the same time.
For a power amplifier, you would measure the response and see if the gain is what is required.
If you want to test your PA for harmonic distortion you will rather have a synthesizer and a spectrum analyzer. You apply an input at different frequencies and power levels using the synthesizer, and use the spectrum analyzer to measure the power in the output fundamental and harmonics.
For an RF detector, you would apply a stimulus using a synthesizer and measure the output using a multimeter.
For the comparator, you will probably need to set up something more complex -- your set up will probably involve an osilloscope. What you test will depend on what are your critical specs and how your final system will work.
The short form answer : first delete the non-standard library ieee.std_logic_arith.all;
It and its std_logic_[un]signed cousins are a mess of slightly ambiguous functions that obscure what your code means and can fail unexpectedly like this example. Does conv_std_logic_vector generate a signed or unsigned representation? Does that depend which libraries you are using? Does conv_integer convert TO an integer, or FROM an integer?
Second, decide what your std_logic_vector quantities represent : signed or unsigned numbers?
You can declare them as signed or unsigned instead (from ieee.numeric_std library). If you MUST keep them as std_logic_vector (WHY?) then you can cast between types via signed(), unsigned(), std_logic_vector().
Then you can replace
A <= conv_std_logic_vector(va, A'length);
vr := conv_integer(R);
with
A <= to_unsigned(va, A'length); -- or to_signed
vr := to_integer(R);
Best Answer
Generally in the embedded systems I design, I first try to add as much circuitry as needed to test out the overall system, in addition to the microcontroller itself, without adding extra cost (I might add an diagnostic LED for basic output at a cost of a few cents.) Usually this means using whatever leftover analog channels I have available to poke around the system and check that everything is okay, such as different power rails, etc.
Then I write a special manufacturing test firmware which is first loaded into the microcontroller after the board has been stuffed with parts, but before it is put into its final case. Obviously, if the programmer can't load the test firmware into the micro and run it, then you have a problem. But since most microcontrollers use only a couple of pins for programming, in addition to reset, power and ground, even if there is something else wrong on the board usually the micro can be fired up.
If the micro starts up, then one can run some simple tests, such as various RAM tests and a CRC across the code to make sure the RAM is okay and the program is flashed correctly. Although it would be possible to run a test of various instructions, I usually do not bother to do that.
I usually blink the LED once on starting up, and then perhaps twice after completing a series of basic tests. If the flashes are spaced a second apart, this gives a rough check that the timer circuitry is working. If there is a failure, I blink the LED in a specific pattern -- i.e. long flash, followed by 'n' short flashes indicating an error code.
I then try to check as many of the peripheral ports as possible. How you do this is of course dependent on the specific micro and your particular circuitry. You can usually test the I2C, SPI and other busses by simply accessing various peripherals on the board. An external UART can be tested by hooking it up to a PC with a terminal program. Testing the UART is usually a good test of the oscillator frequency, since the UART clock is usually tied to the system clock.
You can even write a program on the PC that interfaces to the micro via the UART to control the testing program, and log results.
I try to have a separate voltage reference in the circuit, that can be used to test against the other power rails. I like the 4.096 voltage references, since using a 12-bit ADC, one bit = 1mV. It can then be used to check other power rails. For voltages over 4.096, such as +5, you will need a voltage divider. If the device is battery driven, you will want to sink the voltage divider with an output port to avoid a constant battery drain.