?? 00000006.htm
字號:
<?xml version="1.0" encoding="gb2312"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"/><title>BDM手冊6 turbolinux </title></head><body><center><h1>BBS 水木清華站∶精華區</h1></center><a name="top"></a>發信人: 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 />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 />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 /><a href="00000005.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一頁</a><a href="index.htm">回到目錄</a><a href="#top">回到頁首</a><a href="00000007.htm">下一篇</a></h1></center><center><h1>BBS 水木清華站∶精華區</h1></center></body></html>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -