Enlightenment
Full Member level 3
- Joined
- Jul 26, 2006
- Messages
- 174
- Helped
- 29
- Reputation
- 58
- Reaction score
- 23
- Trophy points
- 1,298
- Location
- 3rd Rock From Sun
- Activity points
- 2,672
I've been an embedded design engineer (SW & HW) for over 20 years. Here are some tips and thoughts about what you should do when trying to get embedded software to work, especially with new hardware. These are some of the basics, and doesn't cover every situation.
Other experienced engineers might want to leave some tips too.
#1 - Examine the schematic very closely to ensure that you understand what is connected to which pin on the microcontroller. I usually create an excel file (setting all cells to TEXT) that lists: every pin number, matching official pin name, pins purpose relating to hardware design, i/o direction or peripheral type that is going to be used on the pin. I create new columns for each respin of the board and then highlite the cells, in a different color, that are different between the boards.
#2 - Ensure critical hardware is working correctly. Verify every voltage, then every clock, then reset and interrupts, then other misc critical things that might prevent the microcontroller starting up (varies from chip to chip). Verify reset and interrupt lines are not held in the wrong state continously, like reset always being low.
#3 - Check all test points with a logic probe, scope, logic analyzer to ensure they look reasonable in the power-up state.
#4 - Ensure that debug tools, like JTAG, connect to the microcontroller and communicate properly.
#5 - Ensure that RS232 ports works correctly and initialized early in the code so you can use it for simple debuging and reporting run-time errors. This is critically important if you don't have a scope and/or logic analyzer. I consider it mandatory to have RS232 on all my microcontroller designs, or at a minimum bring the UART TTL-level pins out to a header so I can connect it to an off-board RS232 converter chip. Though RS232 isn't cutting-edge or fancy or fast, it's hard to replace as a cheap and simple debug interface for engineering use.
#6 - Initialize all port pins on the microcontroller to match the hardware design, such as in / out / peripheral and other pins settings like pull-up / pull-down / logic type / ... Configure early in the startup code.
#7 - Most microcontrollers have the ability to read pins, even if the pins are configured as a peripheral. For a cheap and easy way to verify your pin levels, read every pin or groups of pins, and "print" their state to the RS232 port. Verify each pin looks correct, should you expect it to be low or high or toggling or don't care. This is an easy step to find hardware problems or solder bridges or misconfigured pins. If pins don't have the correct 0/1 value, then other code sure the heck won't work correctly.
#8 - Create a simple debug menu via RS232 that allows you to choose different self tests or code to exercise different capabilities. Keep the code around so you can use it later to test engineering builds of your boards, or the next respin of your board.
#9 - If you have external RAM, you MUST run extensive memory tests after you first get the board to ensure you don't have any problems, either bad design / bad chip / solder problems. I always include a quick memory test on power-up on my shipped products...for large RAM I don't test the entire RAM on power-up but instead test part of it or test addresses spread out across the chip. If the RAM has any weird problems, I want to know ASAP, so I'm not chasing problems that look like the cause is coming from something else.
#10 - If plan to ship a bunch of the hardware or use it is mission critical or 24/7, then you should create a bunch of self-tests that you can put in a loop to burn in your boards over night before shipping, possibly run a subset of them at power-up (might take too much time...something you have to consider on case-by-case), and have some method a user can run self-tests (not practical for all products).
#11 - For all projects that I work on, I prefer to have a software-controlled heart-beat LED attached to each and every microcontroller / processor, and hardware-controlled heart-beat LED attached to each and every FPGA. Why? Because I can quickly determine if a processor locked up, or the FPGA didn't load correctly, without needing any other tools than my eyes. NOTE: Don't blink the heart-beat LED with a timer output pin, because you can't tell when your CPU locks-up or crashes.
#12 - I prefer to have test points for every interrupt pin, so I can easily check them with a scope or logic analyzer.
#13 - I prefer to have a bunch of generic I/O connected to a header (including a ground on the header), so I can pulse or change states on them with software in real-time, and then examine them with a scope or logic-analyzer. When I'm working on interrupt functions, or having problems with them, I'll dedicate one pin per interrupt, then pull the pin high with software when I start the interrupt and pull it back lown before I exit the interrupt, and hooking them all up to a logic analyzer provides an accurate representation of when all my interrupt routines are running.
#14 - I prefer to have grounded test point on the board, so they can be used as connection points for scope ground clips. The larger the board, the more you should have. Why the heck should I waste a bunch of time trying to find a fricking ground? This isn't critical, but you will miss it when your board doesn't have it.
I might have forgotten some things, so I'll come back and add more later.
Other experienced engineers might want to leave some tips too.
Enlightenment
Other experienced engineers might want to leave some tips too.
#1 - Examine the schematic very closely to ensure that you understand what is connected to which pin on the microcontroller. I usually create an excel file (setting all cells to TEXT) that lists: every pin number, matching official pin name, pins purpose relating to hardware design, i/o direction or peripheral type that is going to be used on the pin. I create new columns for each respin of the board and then highlite the cells, in a different color, that are different between the boards.
#2 - Ensure critical hardware is working correctly. Verify every voltage, then every clock, then reset and interrupts, then other misc critical things that might prevent the microcontroller starting up (varies from chip to chip). Verify reset and interrupt lines are not held in the wrong state continously, like reset always being low.
#3 - Check all test points with a logic probe, scope, logic analyzer to ensure they look reasonable in the power-up state.
#4 - Ensure that debug tools, like JTAG, connect to the microcontroller and communicate properly.
#5 - Ensure that RS232 ports works correctly and initialized early in the code so you can use it for simple debuging and reporting run-time errors. This is critically important if you don't have a scope and/or logic analyzer. I consider it mandatory to have RS232 on all my microcontroller designs, or at a minimum bring the UART TTL-level pins out to a header so I can connect it to an off-board RS232 converter chip. Though RS232 isn't cutting-edge or fancy or fast, it's hard to replace as a cheap and simple debug interface for engineering use.
#6 - Initialize all port pins on the microcontroller to match the hardware design, such as in / out / peripheral and other pins settings like pull-up / pull-down / logic type / ... Configure early in the startup code.
#7 - Most microcontrollers have the ability to read pins, even if the pins are configured as a peripheral. For a cheap and easy way to verify your pin levels, read every pin or groups of pins, and "print" their state to the RS232 port. Verify each pin looks correct, should you expect it to be low or high or toggling or don't care. This is an easy step to find hardware problems or solder bridges or misconfigured pins. If pins don't have the correct 0/1 value, then other code sure the heck won't work correctly.
#8 - Create a simple debug menu via RS232 that allows you to choose different self tests or code to exercise different capabilities. Keep the code around so you can use it later to test engineering builds of your boards, or the next respin of your board.
#9 - If you have external RAM, you MUST run extensive memory tests after you first get the board to ensure you don't have any problems, either bad design / bad chip / solder problems. I always include a quick memory test on power-up on my shipped products...for large RAM I don't test the entire RAM on power-up but instead test part of it or test addresses spread out across the chip. If the RAM has any weird problems, I want to know ASAP, so I'm not chasing problems that look like the cause is coming from something else.
#10 - If plan to ship a bunch of the hardware or use it is mission critical or 24/7, then you should create a bunch of self-tests that you can put in a loop to burn in your boards over night before shipping, possibly run a subset of them at power-up (might take too much time...something you have to consider on case-by-case), and have some method a user can run self-tests (not practical for all products).
#11 - For all projects that I work on, I prefer to have a software-controlled heart-beat LED attached to each and every microcontroller / processor, and hardware-controlled heart-beat LED attached to each and every FPGA. Why? Because I can quickly determine if a processor locked up, or the FPGA didn't load correctly, without needing any other tools than my eyes. NOTE: Don't blink the heart-beat LED with a timer output pin, because you can't tell when your CPU locks-up or crashes.
#12 - I prefer to have test points for every interrupt pin, so I can easily check them with a scope or logic analyzer.
#13 - I prefer to have a bunch of generic I/O connected to a header (including a ground on the header), so I can pulse or change states on them with software in real-time, and then examine them with a scope or logic-analyzer. When I'm working on interrupt functions, or having problems with them, I'll dedicate one pin per interrupt, then pull the pin high with software when I start the interrupt and pull it back lown before I exit the interrupt, and hooking them all up to a logic analyzer provides an accurate representation of when all my interrupt routines are running.
#14 - I prefer to have grounded test point on the board, so they can be used as connection points for scope ground clips. The larger the board, the more you should have. Why the heck should I waste a bunch of time trying to find a fricking ground? This isn't critical, but you will miss it when your board doesn't have it.
I might have forgotten some things, so I'll come back and add more later.
Other experienced engineers might want to leave some tips too.
Enlightenment
Last edited: