📄 380.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="375.htm">上一层</a>][<a href="381.htm">下一篇</a>]
<hr><p align="left"><small>发信人: 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>
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>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="375.htm">上一层</a>][<a href="381.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -