📄 381.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="382.htm">下一篇</a>]
<hr><p align="left"><small>发信人: doot (ltt), 信区: Embedded <br>
标 题: BDM手册3 <br>
发信站: BBS 水木清华站 (Thu Oct 26 16:19:07 2000) <br>
<br>
Limitations, etc. <br>
The limitations to crash and burn debugging come down to time and money. It <br>
is ultimately <br>
more expensive to spend a great deal of time tracking down each bug. Debuggi <br>
ng this way <br>
is similar to trying to fix a mechanical device in a dark room. Just turn on <br>
the light, use a <br>
debugger of some type. <br>
ROM monitors are actually very powerful in their debugging abilities. One of <br>
the first <br>
drawbacks is a chicken and egg type of problem. If you are writing the monit <br>
or for a new <br>
processor, how do you debug it? Typically, you crash and burn to get basic c <br>
ommunication <br>
functions working. Then you add debug statements (fprints in C) and do a mod <br>
ified or <br>
“informed” crash and burn to get the debug monitor working. If you are goo <br>
d, and you are <br>
porting a known monitor, this should not take too much time (relatively spea <br>
king). <br>
Another drawback to ROM monitors is that the target processor is always runn <br>
ing. Why is <br>
this a problem? Many processors (especially smaller microcontrollers) have p <br>
eripherals or <br>
features that never stop. For instance, the timer on Motorola’s 68HC05 runs <br>
continually, <br>
even when you enter the monitor. Thus, any debugging of timer interrupts is <br>
difficult if <br>
not impossible. This includes real- time schedulers, a common piece of softw <br>
are. <br>
ROM monitors are also just that, monitors in ROM. Thus, you must have some R <br>
OM for <br>
the monitor. Some processors let you get around this if they have a type of <br>
auto- bootload <br>
that will load code into RAM on start- up (Motorola 68HC11), usually via a s <br>
erial port. In <br>
general, the monitor must be resident and takes anywhere from 256 bytes of c <br>
ode to 30K <br>
and up. <br>
A typical ROM monitor will only debug code that resides in RAM. This means t <br>
hat your <br>
hat your <br>
target must have enough RAM to hold the code and have it in the same (or equ <br>
ivalent) <br>
memory map as the final product’s ROM. The main reason for needing the code <br>
in RAM is <br>
for controlling the program’s execution. Breakpoints are typically implemen <br>
ted in software <br>
(inserting an opcode for a “trap”) and thus must be in RAM. Single steppin <br>
g is often done <br>
by inserting breakpoints in appropriate places. <br>
ROM monitors use processor resources or require additional hardware. The mon <br>
itor must <br>
communicate with an external debugger (or, minimally, a “dumb” terminal) a <br>
nd this <br>
requires a UART. It may be an on- chip UART (thus using a resource) or an ex <br>
ternal <br>
UART requiring special hardware just for debug, eating up valuable board rea <br>
l estate, etc. <br>
Finally, since the ROM monitor runs on the target processor, upon reset it t <br>
ypically does <br>
some housekeeping on the chip. This may include initializing chip selects, s <br>
etting the <br>
stack pointer, clearing memory, etc. If the target code does not recreate th <br>
is initialization, <br>
the environment that the target code runs in will be different than that env <br>
ironment <br>
during debug. This is assuming that the final product does not go to the ROM <br>
monitor on <br>
reset. This is a vitally important point. Again, the final code may not be <br>
running in the <br>
same environment as the tested code. <br>
ROM emulators main limitation is that they are limited to systems that conta <br>
in external <br>
ROM. This eliminates many microcontrollers that run in single- chip mode. Ad <br>
ditionally, <br>
since they basically implement a ROM monitor, all the drawbacks just mention <br>
ed may <br>
apply. <br>
In- circuit emulators also have some drawbacks. The vast majority have some <br>
type of <br>
interface to the outside world (your target circuit) that is not 100% identi <br>
cal to the interface <br>
on the actual chip (contrary to the advertising for the emulator). For insta <br>
nce, the oscillator <br>
circuit is usually in the emulator, not your target. Additionally, many emul <br>
ators must <br>
re- create parallel ports on microcontrollers since the emulator uses them a <br>
s address and <br>
data lines for its own use. There are exceptions. Philips Semiconductors’ X <br>
A emulator chip <br>
uses a totally separate bond- out section for emulation and all user pins ar <br>
e available <br>
without buffering or recreation. The factory debugger/ emulator is actually <br>
as pure an <br>
emulator as you can get, i. e.: no signal modification or additional loading <br>
on the user side <br>
of the chip. Do be aware that the author of this manual is the designer of t <br>
hat board and <br>
may be prejudiced. <br>
Additionally, an in- circuit emulator is not always available. Many of the n <br>
ewer <br>
microcontrollers are actually designed with a single customer in mind. That <br>
customer may <br>
buy hundreds of thousands of chips but only need three or four debug station <br>
s. It is not <br>
worth the cost of developing an ICE for three sales! One solution is from He <br>
wlett Packard <br>
with their “Distributed Emulation”, basically an OCD debugger and a sophis <br>
ticated logic <br>
analyzer working with a single user interface to essentially create a custom <br>
ICE. <br>
In- circuit emulators are generally expensive. They typically include high- <br>
speed memory <br>
(read: expensive), ASICs (read: expensive), and specialized cables (read: ex <br>
pensive). <br>
On the positive side, an ICE will typically give you real- time trace, not u <br>
se processor <br>
resources, and allow debugging without target hardware. <br>
As for OCD, it has no drawbacks. <br>
Seriously, it does have a few drawbacks. The target usually needs RAM instea <br>
d of ROM <br>
for debugging, but this is not always necessary. There typically, but not al <br>
ways, is no form <br>
of real- time trace. <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="382.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 + -