📄 386.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="387.htm">下一篇</a>]
<hr><p align="left"><small>发信人: doot (ltt), 信区: Embedded <br>
标 题: BDM手册end <br>
发信站: BBS 水木清华站 (Thu Oct 26 16:25:47 2000) <br>
<br>
OCD specifics <br>
There are a handful of OCD debuggers available on the market. They range in <br>
price from <br>
freeware to several thousand dollars. All of them give you the basics: read <br>
and write <br>
registers, read and write memory, download code, single step, run, etc. Most <br>
give you <br>
source level debug capabilities. Some work only with assembly code, others w <br>
ith any <br>
language. The differences of most concern are how the aforementioned situati <br>
ons are <br>
handled. Is there “hidden” initialization? Are there “user friendly” tra <br>
ps? And what about <br>
that start- up stuff? <br>
Just like getting out of bed in the morning is tough for many of us, some pr <br>
ocessors need a <br>
helping hand coming out of reset. Let us assume that my suggestions for desi <br>
gning your <br>
prototype were ignored. Your target has its boot chip select attached to a R <br>
OM chip of <br>
some type. Since this is debug time, there is no code in the ROM as of yet. <br>
You have a <br>
debugger connected to the OCD header and want to start testing your code. Yo <br>
u have the <br>
debugger reset the target and then download your code. WRONG! Upon reset, th <br>
e only <br>
properly setup chip select line will be the boot chip select. This is pointi <br>
ng to useless ROM. <br>
Whatever chip select is attached to your RAM must be initialized. But by who <br>
(or what)? <br>
Some debuggers have built in setups for known hardware such as various manuf <br>
acturer’s <br>
development boards. Usually you can describe your custom target via dialogs <br>
to tell the <br>
debugger how to setup the board. Other debuggers allow you to write command <br>
files <br>
(“ macros”, “scripts”, etc.) to do the setup. These files have commands <br>
such as WRITEL <br>
0x1234, 0x5678 which would write a LONG value of hexadecimal 1234 to locatio <br>
n <br>
hexadecimal 5678. With some debuggers you must explicitly run the command fi <br>
le every <br>
time you reset the processor, others do this automatically. Again, the main <br>
problem with <br>
doing this is that your code is now in an environment that is different from <br>
the reset <br>
environment, and your code did not cause this change. If the only command is <br>
a setup of <br>
the RAM chip select, this is probably not too big a problem. Probably. <br>
Another setup issue is the speed of the target processor. Many of the newer <br>
processors use <br>
an inexpensive 32 kilohertz crystal along with an on- chip phase lock loop ( <br>
pll) to boost the <br>
system frequency. Upon reset, the pll is at some default value, quite possib <br>
ly a very slow <br>
one. Often, your application’s initialization code will set the pll to some <br>
faster value, but <br>
during debug this only happens after your code is downloaded. If the debugge <br>
r does not do <br>
any type of setup (hidden or not) and you do a download (via the boot chip s <br>
elect), the <br>
processor is most likely running at a slow speed. This will slow down your d <br>
ownload which <br>
ownload which <br>
is always too long, no matter what the speed! This is another reason that yo <br>
u must <br>
thoroughly think about how the setup will work. <br>
Talking about speed, one more issue that has not been discussed is raw OCD s <br>
peed. All of <br>
the OCD protocols are implemented serially. The limit, or maximum OCD speed, <br>
is usually <br>
a function of the CPU clock speed. Typically, the OCD may only run one- thir <br>
d or one- half <br>
of the CPU speed. Most OCD hardware interfaces start at a slow speed since t <br>
he processor <br>
speed usually cannot be determined. If the speed of the interface is not set <br>
for the maximum <br>
speed (either the fastest the CPU will handle or the fastest the interface c <br>
an run, which <br>
ever is slower) the speed of debugging is affected. This is most obvious in <br>
the download <br>
speed of code. Some debuggers will allow you to modify the interface speed i <br>
n a command <br>
file. You would do this only after you set any pll speed, of course. Additio <br>
nally, you will <br>
probably have to set the interface speed to be slow at the start of the comm <br>
and file. Why? <br>
Once you RESET the target processor, it is running at its default speed. If <br>
this is slow, you <br>
must slow the interface to do your pll setup, then speed up the interface. A <br>
nd you thought <br>
this was going to be easy. Ideally, you may have a macro that runs whenever <br>
you hit the <br>
debugger RESET TARGET button or command on your debugger that will: <br>
1. Reset the target CPU <br>
2. Lower the OCD speed <br>
3. Set the processor PLL for desired speed <br>
4. Raise the OCD speed to as fast as the processor will allow <br>
So how do you choose a debugger? <br>
Bascially, use the information in this paper, ask questions of the vendor, a <br>
nd see the <br>
debugger in use. Does it work with your favorite compiler? How does it commu <br>
nicate with <br>
the target? What is the “invasiveness” and are those items fully documente <br>
d? <br>
I am prejudiced about debuggers. I have written and marketed several from ba <br>
sic DOS <br>
assembly language based debuggers to complete Windows based high level syste <br>
ms. For <br>
these reasons, I will leave you to your own devices. Feel free to contact me <br>
for information <br>
about debuggers and what I have to offer. <br>
Good luck and good debugging. <br>
Craig Haller <br>
President <br>
Macraigor Systems Inc. <br>
P. O. Box 1008 <br>
Brookline Village, MA 02147 <br>
(617) 739- 8693 <br>
(617) 739- 8694 - fax <br>
www. macraigor. com <br>
craig@ macraigor. com <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="387.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 + -