📄 00000002.htm
字号:
<?xml version="1.0" encoding="gb2312"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"/><title>BDM手册2 turbolinux </title></head><body><center><h1>BBS 水木清华站∶精华区</h1></center><a name="top"></a>发信人: doot (ltt), 信区: Embedded <br />标 题: BDM手册2 <br />发信站: BBS 水木清华站 (Thu Oct 26 16:17:48 2000) <br /> <br />SECTION I <br />This section is not for old- timers, experienced debuggers, ICE gurus, and t <br />he like. It is <br />purely a light hearted look at the state of the art of microprocessor and mi <br />crocontroller <br />debugging through the years. The background is very helpful in understanding <br /> on- chip <br />debugging. Skip to SECTION II for the specific information about on- chip de <br />bugging. <br />Debugging through history <br />First there was the “crash and burn” method of debugging. We have all done <br /> this more <br />times then we admit. You decide to make a paper airplane. You fold it to the <br /> best of your <br />ability, toss it and it glides like a set of car keys. Do you A: take a slow <br /> motion video of its <br />flight, study it and modify the design, B: rent time at the wind tunnel at M <br />IT, C: crumble <br />it up, toss it, and try again, or D: claim that its sudden nose dive is a fe <br />ature? <br />You write your code, check it over once or twice, burn the EPROM and let it <br />run. If it <br />doesn’t work, you look at the code some more. At some point this is all we <br />have tools for. It <br />is not necessarily a bad method but it can be extremely slow. <br />There are several ways to improve the crash and burn method, an “informed” <br /> crash and <br />burn, if you will. Many times we will sprinkle output messages at various pa <br />rts of our <br />code. If we are lucky enough to have a monitor or LCD output device, differe <br />nt tasks or <br />routines can “announce” their execution by displaying a message. Short of <br />this, a single <br />LED may blink or turn on at certain points of the code. If the code “goes i <br />n the weeds”, <br />“crashes”, etc., we get an idea of where the problem lies by the last prop <br />er output. <br />After some time, the idea of a hardware single step was implemented. This le <br />t you cause <br />the processor to execute one instruction and then stop. At that point, vario <br />us signals could <br />be checked, etc. and you could determine what code was executing. The Intel <br />8041 was an <br />early microcontroller that allowed single stepping via a small, external har <br />dware circuit. <br />At some point in history, someone (and after reading this I will get lots of <br /> email claiming <br />credit) had the idea of a debugger monitor (aka ROM monitor). This is a smal <br />l piece of <br />code (that’s a relative statement) to help with debugging. It usually commu <br />nicates via a <br />serial interface to a host computer or some form of terminal. A basic monito <br />r allows for the <br />download of code, reading and writing of memory and registers, and perhaps m <br />ost <br />importantly setting breakpoints, single stepping, and real- time execution. <br />More complex <br />monitors may allow source code profiling, complex breakpoints, and more. <br />Soon after this, a new device was introduced. The ROM emulator is a plug- in <br /> replacement <br />for the ROM chips on the target. The device is connected to the host compute <br />r via a serial, <br />parallel, or more recently, an ethernet link. In its simpliest form, the ROM <br /> emulator <br />allows you to quickly download code (as opposed to programming the ROM in a <br />separate <br />programmer) and “crash and burn.” In its most sophisticated form, you can <br />download code <br />that contains a ROM monitor and communicate with the monitor via the emulato <br />r’s <br />connector. <br />Similiar in concept to the ROM emulator, the next major breakthrough in debu <br />gging was <br />the user friendly in- circuit emulator (ICE). This device allowed full acces <br />s to the <br />programmer’s model of the processor, hardware breakpoints, execution trace, <br /> and much <br />more. The ICE typically used a special version of the processor called a “b <br />ond- out”. This <br />form of the chip has many more leads on it, bringing typically internal sign <br />als to the <br />outside to be monitored and manipulated. System, or external, memory is also <br /> supplied <br />and may be mapped into the user space. This allows for debugging code before <br /> a target <br />system exists! Typically an ICE is a complex piece of hardware and software <br />and is <br />considerably more expensive than a monitor based debugger. <br />The latest addition to the debugger arsenal is on- chip debugging (OCD). Ear <br />ly on- chip <br />debuggers were basically debug monitors written into the microcode of the ta <br />rget processor <br />(Motorola CPU32 family of processors). More advanced systems added other fea <br />tures such <br />as real- time reading of the program counter (Analog Devices’ SHARC process <br />or) and near <br />real- time reading of memory locations (Motorola’s ColdFire). The basic OCD <br /> allows for <br />code download, reading and writing memory and processor resources, single st <br />epping, <br />processor reset, and status (running or halted). Typically, on- chip periphe <br />rals may be set <br />to shut down during OCD (as opposed to while the chip is executing user code <br />). <br />Some processors enhance their OCD with other resources truly creating comple <br />te on- chip <br />debuggers. IBMs 4xx PowerPC family of embedded processors have a seven wire <br />interface <br />(“ RISCTrace”) in addition to the OCD (“ RISCWatch”) that allow for a co <br />mplete trace of the <br />processor’s execution. Simply capturing these lines in real- time, a debugg <br />er can then <br />display a full trace of the last x instructions executed. <br /> <br />-- <br /> <br />※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.117.114.7] <br /><a href="00000001.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一页</a><a href="index.htm">回到目录</a><a href="#top">回到页首</a><a href="00000003.htm">下一篇</a></h1></center><center><h1>BBS 水木清华站∶精华区</h1></center></body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -