📄 385.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="386.htm">下一篇</a>]
<hr><p align="left"><small>发信人: doot (ltt), 信区: Embedded <br>
标 题: BDM手册7 <br>
发信站: BBS 水木清华站 (Thu Oct 26 16:25:07 2000) <br>
<br>
6: Set up FLASH ROM for writability. <br>
There are tools on the market that allow for programming of FLASH EEPROM whi <br>
le it is <br>
on the target board. These tools work through the on- chip debugger. By conf <br>
iguring the <br>
FLASH in such a way that the processor can write to it, the work of programm <br>
ing it is <br>
much easier. This might entail simply running a WRITE line to the chip (5 vo <br>
lt only <br>
FLASH) and/ or the addition of 12 volts controlled by a port pin (preferred) <br>
or a jumper. <br>
Typically this means adding a trace or two to the PC board. Definitely worth <br>
the added <br>
copper. (The author sells such a program!) <br>
Designing Your Product <br>
Many of the same issues apply here as in designing your prototype. <br>
1: Use it! <br>
This is not as obvious as it is with the prototype. There are many reasons t <br>
o have access to <br>
the OCD in a final product. With the proper host support, FLASH EEPROM progr <br>
amming <br>
is possible, production line testing, in- field debug and much more. Even if <br>
you don’t intend <br>
to use it after production starts, the lack of access to OCD, if it is ultim <br>
ately needed, may <br>
be very costly. <br>
2: Place the specified header on your board, if possible. <br>
It is not nearly as important as with the prototype to use the factory speci <br>
fied header. See <br>
the hints in the prototype section for using a different header if necessary <br>
. <br>
3: Watch those traces! <br>
This is as important, if not more, than with the prototype. Your product may <br>
be in a less <br>
friendly environment (electrical noise, etc.) and you may not be able to con <br>
trol the <br>
environment as easily. <br>
4: Watch those resistors! <br>
As important as with the prototype if not more so. You want to ensure that a <br>
ll start up <br>
parameters are correct, this is especially important with Motorola’s BDM in <br>
terfaces. <br>
5: Set up FLASH EEPROM for writability. <br>
This is extremely important. The ability to easily program FLASH, both on th <br>
e production <br>
line and in the field, will prove invaluable. Additionally, this allows you <br>
to eliminate the <br>
use of sockets for the EEPROMs. See the prototype section for hints on imple <br>
mentation. <br>
Choosing a Debugger <br>
Some general thoughts and information on debuggers, then specifics about OCD <br>
debuggers. <br>
First, the “invasiveness” of debuggers. By this I refer to the amount of s <br>
ystem setup that <br>
the debugger does for the user. A ROM monitor typically must do some setup, <br>
such as <br>
setting up the stack, initializing chip selects, etc. An OCD debugger does n <br>
ot have to do <br>
this but often does. Why does this matter? If the debugger does ANY setup wo <br>
rk and your <br>
code does not reproduce this setup in the exact way (and possibly at the exa <br>
ct time) your <br>
code will not be running in the same environment as when it is tested. This <br>
is a perfect <br>
example of why your code will work with the debugger but not directly out of <br>
ROM. An <br>
OCD debugger may or may not have to do setup, it actually depends on your ha <br>
rdware <br>
configuration as we will see. Other similar invasions are the initialization <br>
of general <br>
registers, setup of an oscillator pll, etc. <br>
Second, there are also different thoughts on how much the debugger should pr <br>
otect you, <br>
the user. A common target has a bank of RAM into which your code is loaded f <br>
or testing. <br>
Assume your code is running in real- time and it “goes into the weeds” (no <br>
t your code!), in <br>
other words there may be an errant pointer and you are now executing out of <br>
uninitialized <br>
RAM, garbage code. You may not know this and the code may go for a while, re <br>
eking all <br>
sorts of havoc, until, for some reason the debugger regains control. This is <br>
a tough one to <br>
debug unless you have a large trace buffer. Alternatively, the debugger coul <br>
d have filled <br>
d have filled <br>
memory with some specific instruction before downloading your code. If this <br>
is a BREAK, <br>
BGND, TRAP, or INTERRUPT instruction that the debugger would recognize, a br <br>
eak <br>
would have occurred at the first errant instruction. Should the debugger do <br>
this <br>
automatically? What about interrupt vector tables? Should the debugger fill <br>
in all <br>
uninitialized vectors and trap on their use? <br>
Some of these issues are easier to deal with than others, depending on the t <br>
arget chip. The <br>
embedded PowerPC chips have many options for protecting the user. By setting <br>
bits in a <br>
register you can cause the on- chip debugging mode to be entered (hence, a b <br>
reakpoint) for <br>
various events such as execution of an unrecognized opcode, misaligned data <br>
fetch, etc. If <br>
the debugger secretly sets these bits, you are debugging in a different envi <br>
ronment than <br>
that in which your code will run. This is probably OK, but is it? Does your <br>
debugger give <br>
you access to these bits? <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="386.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 + -