Hardware Sanity Tests for the Firmware Developer

So what do you do if youre all alone and you suspect the target hardware has a problem? Realistically, if the target is a complex hardware design, you probably wont be able to do much, but here are a few high-level tests that identify some common problems. This section assumes you can read a schematic and handle a multimeter, oscilloscope, and maybe a logic analyzer. Dont expect too much, though. Even if you do actually find something, chances are that you will need to wait for the hardware person to verify your findings. But, hey, its still fun, and, in the meantime, you get to know the hardware a bit better, which always helps.

Verify Power Supply Voltage

The first step is to make sure that the power supply is plugged in. Im not kidding! Use a meter to verify that power supply voltage is what its supposed to be. Next , try an oscilloscope to make sure that the voltage is stable and not noisy or oscillating. A meter alone is not going to detect dirty power.

Verify a Valid Clock

Use an oscilloscope to verify that the clock input to the processor is toggling and that the frequency is about what you would expect. Normally, as long as the clock is toggling the system will run, but an incorrect clock frequency or duty cycle can sometimes cause trouble, so dont just assume that because it is toggling it is OK.

Check the Boot Chip Select and Read

With a scope probe on the boot device chip select, push the reset button and verify that, at least momentarily, the line toggles to the active state. Repeat this process for the read line of the same device.

Get Out the Magnifying Glass

If youve looked at hardware recently, youll understand why you need a magnifying glass. Those pins are awfully close together! Look at the pins on the CPU and boot device. Check for raised pins, solder globs across pins, or cold solder joints (which look much duller than other good joints). If you do find what appears to be a bad connection, report it to the lab person that takes care of solder rework. Unless you have experience with the equipment used to rework these tiny solder joints, you are better off leaving the solder joints alone. If you misuse these tools, you could easily damage the device (or worse , damage the printed circuit board).

Be Aware of Electrostatic Discharge

If you are handling the target hardware in any way, take electrostatic discharge (ESD) precautions . Wear a wrist or ankle strap and check with the designer on other precautionary steps. ESD will not necessarily kill a device; it may just make it flaky. Theres nothing worse than flaky in embedded systems.

Simple Loop at the Reset Vector

Start with a very basic loop at the reset vector and verify that the chip-select to the boot flash device is constantly toggling. This step can be as simple as one line of assembly language(see Listing 2.10).

Listing 2.10: Confirming the Boot Address

 coldstart:     jmp coldstart 

 

Without external test equipment to observe the chip select toggle when running, the test in Listing 2.10 may not prove much. Depending on the CPU and how it deals with an unprogrammed boot device, the CPU might still be perfectly happy to execute NOPS or whatever garbage pattern is in the flash device. So seeing the flash chip select line toggling does not guarantee that the CPU is executing the test program. On the other hand, if the chip select line is not toggling, you can be sure that something has failed. If you can connect a logic analyzer to the device, the logic analyzer can shed a bit more light on the state of things.

A Simple LED Is Priceless at This Point!

Previously I mentioned the usefulness of an oscilloscope or logic analyzer. If neither an oscilloscope nor a logic analyzer is available, then hopefully you thought ahead and had the design include an accessible LED. This LED could be used to monitor state based on some type of blink rate or on/off state. An LED is not a perfect tool because until you get going, you dont really know if the LED is on or is blinking so fast that it appears to be on. On top of that, if the LED is on, is it on because you turned it on or would it be on even without the flash device plugged into the socket? Once you do get to a point where you know that access to the LED is working, you can use the LED as a convenient replacement for the oscilloscope by turning on the LED at the end of some test and then sitting in a busy loop (leaving the LED on). This way the LED can be used to indicate that whatever you tried to do worked.

Build on this. Create three small assemblly language routines: LED_on , LED_bslow , and LED_bfast . The blink rate between the slow and fast routines should be extreme so that it is easy to tell which routine you are accessing. These three routines can then be used to indicate in-progress, pass, and fail status of additional tests. Also, consider the possibilities if you had more than one LED. If you had four LEDs, you could track 16 unique states while trying to bootup .

RAM and a No-Stack-Required Serial Out

The next set of steps depends on what you have on your hardware. These tests are designed to demonstrate the minimum functionality necessary to support compiled C programs. The primary issue is to determine whether the run-time stack is reliable. If your processor has any internal RAM, you should use that internal RAM if possible, since internal RAM does not involve the external address or data bus. Test external SRAM with a loop that fills all the RAM space with 0x55 , then reads it back, then writes it with 0xAA , and then reads it back in an endless loop. A scope can be used to trigger on the read line and write line as two different tests; make sure the data appears to be always 0x55 or 0xaa .

If your system does not have any SRAM, the next routine to work on would be interfacing to the serial port. Start by writing a simple loop that just pumps a character out the serial port, ignoring status for now. Even if you are overrunning the transmit buffer, you should still see an occasional character appear on the RS-232 interface. If not, connect the scope to the TX line of the serial connection and see if there is any activity at all. If you get no activity, troubleshooting can be tricky. You may have the write to the device working but have the UART blocked because some parameter is not configured properly (baud rate, for example). Also, if the device is connected to a terminal, be aware of the possible need for a null modem connector.

If your hardware only has DRAM, you are left with the difficult task of initializing DRAM on a target that is still unproven. This isnt easy and probably requires discussion with the hardware designer. The details of initializing DRAM are beyond the scope of this text because it is very dependent on the device. Having LED and/or serial port access at this point is very useful for determining the state of the DRAM initialization.

Get to C-Level

At this point you have verified execution out of the boot device, tested some memory, blinked an LED, and sent a few characters out the serial port. Believe it or not, this progress is good on new hardware. Its now time to transition to C-level. Because you have working RAM, it should be easy to transition to C. Create a simple C function that does not use any global data, only stack. The function uses a for loop to insert a delay between changing the state of the LED. If you assume the LED is accessible at address 0xff8000 , bit 0, and setting bit 0 turns on the LED, the C function should look something like the function shown in Listing 2.11.

Listing 2.11: Blinking a LED.

 #define LED_ADDRESS 0xff8000 #define LED_ON      0x0001 #define LED_OFF     0x0000 void First_C_Function(void) {     volatile int loopcnt;     while(1)      {         *(unsigned short *)LED_ADDRESS = LED_ON;         for(loopcnt=0;loopcnt < 500000; loopcnt++);         *(unsigned short *)LED_ADDRESS = LED_OFF;         for(loopcnt=0;loopcnt < 500000; loopcnt++);     } } 

 

Now, in assembly language, initialize the stack pointer register to a location in memory that is divisible by 16. Allow for a few hundred bytes of space to grow into. Make sure you know which way your stack grows and branch to the address of the C function. Hopefully your LED is blinking.

Next, repeat the same test, but this time make the loopcnt variable static. If this works, then you know you have properly established the BSS space in the linker memory map. (By making the loopcnt variable a static variable, you are telling the compiler not to put the variable on the local stack; hence, the variable is mapped to the space that is allocated for use by the .bss section.)

Tip 

Avoid Modification of Initialized Data in C By the time you get the serial port working, your test program might have about 100 lines of assembly code and a handful of C functions. Things start to move faster now, but, to keep things simple, you need to make one easy sacrifice. Dont write any code for a while that assumes that initialized data is writable. Initialized variables are one of those things that a programmer on a workstation can always take for granted. Initialized data in an embedded system implies that the data in its initialized state exists somewhere in memory when the target is powered up. This point implies that initialized data must be in non-volatile memory. Now, if the data is to be writable in C, then it cant be in non-volatile memory once you begin executing C-level code because non-volatile memory is not writable. The solution to this dilemma is that the initialized data section of memory is located in non-volatile storage and must be copied to volatile space at startup (prior to C-level) so that the data is initialized but writable. This step isnt very hard, but, from one toolset (compiler/linker) to another, the process is slightly different. The easier thing to do at this point is just avoid the problem, so dont assume that your initialized data is writable.