📄 384.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="385.htm">下一篇</a>]
<hr><p align="left"><small>发信人: doot (ltt), 信区: Embedded <br>
标 题: BDM手册6 <br>
发信站: BBS 水木清华站 (Thu Oct 26 16:24:18 2000) <br>
<br>
Designing Your Prototype <br>
There are many things to consider in designing your prototype target to take <br>
advantage of <br>
the OCD capabilities. <br>
1: Use it! <br>
This may sound simplistic but some designers are so accustomed to ROM monito <br>
rs or <br>
emulators that the decision is made not to use the on- chip debugging featur <br>
es. If you are <br>
not going to use the features, maybe another member of the design or integra <br>
tion team <br>
will. It takes very little to leave the option open to others. Minimally … <br>
2: Place the specified header on your board, if possible. <br>
If the prototype is not the same PC card as the end product then there is su <br>
re to be room <br>
on the board for the header. If there is not room, there are other options. <br>
Take a look at <br>
the header specification from the manufacturer and the debugger you plan on <br>
using. You <br>
using. You <br>
will probably find signals that you do not need. The RISCWatch header from I <br>
BM contains <br>
several “no connect” signals and a “key” pin (rather, missing pin). If y <br>
ou must, you can <br>
substitute a smaller header and make a conversion cable. The Motorola BDM fo <br>
r the <br>
CPU16/ CPU32 family contains two ground signals and a DATA STROBE signal. Ty <br>
pically, <br>
one ground may suffice and most debuggers do not use the data strobe. The he <br>
ader does <br>
not have to be a dual- row header on .1 centers. Although this is the specif <br>
ication, feel free <br>
to modify it to fit your needs. Be somewhat careful about the layout, it is <br>
helpful to keep <br>
higher frequency lines separated. If you are using a wiggler, this is not a <br>
problem since <br>
the frequency does not usually surpass 100K bps. <br>
3: Watch those traces! <br>
It is best to keep the OCD connector close to the CPU since the lines are ty <br>
pically not <br>
buffered. It is important to keep the traces approximately the same length, <br>
especially the <br>
especially the <br>
serial communications lines. For Motorola, these are the DSI, DSO, and DSCK <br>
lines. For <br>
JTAG interfaces, the TMS, TDO, TDI, and TCK lines. I have seen problems, eve <br>
n with low <br>
speed wigglers, when the lines meander around the board from the processor t <br>
o the <br>
header, particularly with 3.3 volt parts. Remember that some JTAG ports are <br>
used for <br>
both hardware and software testing. The hardware use may necessitate connect <br>
ing many <br>
chips on the board together via a JTAG daisy chain. This will greatly effect <br>
software <br>
testing and noise on the chain. Think this out carefully and watch your desi <br>
gn. <br>
4: Watch those resistors! <br>
Motorola chips, in particular, set up the OCD configuration and access durin <br>
g the hardware <br>
reset. It is vitally important that the debugger correctly control these lin <br>
es during this <br>
time. Equally important is what happens when you test the board without a de <br>
bugger <br>
attached. The manufacturer will also offer a recommended circuit for the OCD <br>
/ JTAG <br>
header which may or may not include resistor pull- ups and/ or pull- downs. <br>
Additionally, <br>
other signals on the header may have recommended circuits (i. e.: IBM sugges <br>
ts a 1K <br>
series resistor on the power sense line for the 4xx processors). <br>
5: Connect the boot chip select to RAM. <br>
Virtually all of the on- chip debugging equipped processors have multiple ch <br>
ip selects. <br>
Typically, one of them is configured during a hardware reset to be used with <br>
whatever <br>
boot ROM or start- up code ROM is in the system. Many newer designs use a FL <br>
ASH <br>
EEPROM for this purpose. During debug, it is obviously advantageous to use R <br>
AM instead <br>
of ROM to hold the code under test. One possibility is to have another chip <br>
select pointing <br>
to a bank of RAM (that may or may not be in the final product). The problem <br>
here is that <br>
when you or the debugger cause a hard reset, the chip select for the RAM is <br>
NOT appropriately <br>
configured. This must somehow be done (see section on why most OCD debuggers <br>
do not <br>
have ZEN). Additionally, you will be testing code running with a chip select <br>
different from <br>
that in the final product, something better to avoid. <br>
I recently solved the problem this way … My boot chip select and general ch <br>
ip select zero <br>
went to a 2x3 pin header. On the board was a 128K FLASH EPROM and a 128K sta <br>
tic <br>
RAM. By changing the jumpers on the header, either device could be controlle <br>
d by either <br>
chip select. During initial debug, the RAM received the boot chip select. Af <br>
ter code was <br>
burned into the FLASH (in target, via an OCD Flash programmer), the jumpers <br>
were <br>
changed and final debug and test was conducted. You will also find that if y <br>
ou socket your <br>
boot ROM, there may be a RAM with the same footprint that will fit in the so <br>
cket during <br>
debug, or a simple socket adapter may be fabricated (thank goodness for tech <br>
nicians!). <br>
Don’t forget to make the socket writable. This is the ideal solution. <br>
Another common practice in a final product is to have the application code i <br>
n as slow, <br>
small, and narrow a boot ROM as possible. This allows inexpensive storage. T <br>
he actual <br>
boot code then sets up the hardware (minimally, the other chip selects) and <br>
copies the <br>
application code from the slower ROM to faster system RAM. This is followed <br>
by a jump to <br>
the start of the application. This kind of simple boot program is easy to im <br>
plement. You <br>
may want to have the boot section of the code written and placed into a ROM <br>
on the boot <br>
chip select line. During debug, the application code would not be in the ROM <br>
but still on <br>
the host. When you reset the target under test, you would then execute the b <br>
eginning of <br>
the boot code to set up the hardware and then return to the OCD. Now your ap <br>
plication <br>
under test may be downloaded to the RAM on the chip select with which it wil <br>
l run in the <br>
final system. <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="385.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 + -