?? 00000007.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手冊7 turbolinux </title></head><body><center><h1>BBS 水木清華站∶精華區</h1></center><a name="top"></a>發信人: 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 />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 /><a href="00000006.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一頁</a><a href="index.htm">回到目錄</a><a href="#top">回到頁首</a><a href="00000008.htm">下一篇</a></h1></center><center><h1>BBS 水木清華站∶精華區</h1></center></body></html>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -