📄 00000003.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手册3 turbolinux </title></head><body><center><h1>BBS 水木清华站∶精华区</h1></center><a name="top"></a>发信人: doot (ltt), 信区: Embedded <br />标 题: BDM手册3 <br />发信站: BBS 水木清华站 (Thu Oct 26 16:19:07 2000) <br /> <br />Limitations, etc. <br />The limitations to crash and burn debugging come down to time and money. It <br />is ultimately <br />more expensive to spend a great deal of time tracking down each bug. Debuggi <br />ng this way <br />is similar to trying to fix a mechanical device in a dark room. Just turn on <br /> the light, use a <br />debugger of some type. <br />ROM monitors are actually very powerful in their debugging abilities. One of <br /> the first <br />drawbacks is a chicken and egg type of problem. If you are writing the monit <br />or for a new <br />processor, how do you debug it? Typically, you crash and burn to get basic c <br />ommunication <br />functions working. Then you add debug statements (fprints in C) and do a mod <br />ified or <br />“informed” crash and burn to get the debug monitor working. If you are goo <br />d, and you are <br />porting a known monitor, this should not take too much time (relatively spea <br />king). <br />Another drawback to ROM monitors is that the target processor is always runn <br />ing. Why is <br />this a problem? Many processors (especially smaller microcontrollers) have p <br />eripherals or <br />features that never stop. For instance, the timer on Motorola’s 68HC05 runs <br /> continually, <br />even when you enter the monitor. Thus, any debugging of timer interrupts is <br />difficult if <br />not impossible. This includes real- time schedulers, a common piece of softw <br />are. <br />ROM monitors are also just that, monitors in ROM. Thus, you must have some R <br />OM for <br />the monitor. Some processors let you get around this if they have a type of <br />auto- bootload <br />that will load code into RAM on start- up (Motorola 68HC11), usually via a s <br />erial port. In <br />general, the monitor must be resident and takes anywhere from 256 bytes of c <br />ode to 30K <br />and up. <br />A typical ROM monitor will only debug code that resides in RAM. This means t <br />hat your <br />target must have enough RAM to hold the code and have it in the same (or equ <br />ivalent) <br />memory map as the final product’s ROM. The main reason for needing the code <br /> in RAM is <br />for controlling the program’s execution. Breakpoints are typically implemen <br />ted in software <br />(inserting an opcode for a “trap”) and thus must be in RAM. Single steppin <br />g is often done <br />by inserting breakpoints in appropriate places. <br />ROM monitors use processor resources or require additional hardware. The mon <br />itor must <br />communicate with an external debugger (or, minimally, a “dumb” terminal) a <br />nd this <br />requires a UART. It may be an on- chip UART (thus using a resource) or an ex <br />ternal <br />UART requiring special hardware just for debug, eating up valuable board rea <br />l estate, etc. <br />Finally, since the ROM monitor runs on the target processor, upon reset it t <br />ypically does <br />some housekeeping on the chip. This may include initializing chip selects, s <br />etting the <br />stack pointer, clearing memory, etc. If the target code does not recreate th <br />is initialization, <br />the environment that the target code runs in will be different than that env <br />ironment <br />during debug. This is assuming that the final product does not go to the ROM <br /> monitor on <br />reset. This is a vitally important point. Again, the final code may not be <br />running in the <br />same environment as the tested code. <br />ROM emulators main limitation is that they are limited to systems that conta <br />in external <br />ROM. This eliminates many microcontrollers that run in single- chip mode. Ad <br />ditionally, <br />since they basically implement a ROM monitor, all the drawbacks just mention <br />ed may <br />apply. <br />In- circuit emulators also have some drawbacks. The vast majority have some <br />type of <br />interface to the outside world (your target circuit) that is not 100% identi <br />cal to the interface <br />on the actual chip (contrary to the advertising for the emulator). For insta <br />nce, the oscillator <br />circuit is usually in the emulator, not your target. Additionally, many emul <br />ators must <br />re- create parallel ports on microcontrollers since the emulator uses them a <br />s address and <br />data lines for its own use. There are exceptions. Philips Semiconductors’ X <br />A emulator chip <br />uses a totally separate bond- out section for emulation and all user pins ar <br />e available <br />without buffering or recreation. The factory debugger/ emulator is actually <br />as pure an <br />emulator as you can get, i. e.: no signal modification or additional loading <br /> on the user side <br />of the chip. Do be aware that the author of this manual is the designer of t <br />hat board and <br />may be prejudiced. <br />Additionally, an in- circuit emulator is not always available. Many of the n <br />ewer <br />microcontrollers are actually designed with a single customer in mind. That <br />customer may <br />buy hundreds of thousands of chips but only need three or four debug station <br />s. It is not <br />worth the cost of developing an ICE for three sales! One solution is from He <br />wlett Packard <br />with their “Distributed Emulation”, basically an OCD debugger and a sophis <br />ticated logic <br />analyzer working with a single user interface to essentially create a custom <br /> ICE. <br />In- circuit emulators are generally expensive. They typically include high- <br />speed memory <br />(read: expensive), ASICs (read: expensive), and specialized cables (read: ex <br />pensive). <br />On the positive side, an ICE will typically give you real- time trace, not u <br />se processor <br />resources, and allow debugging without target hardware. <br />As for OCD, it has no drawbacks. <br />Seriously, it does have a few drawbacks. The target usually needs RAM instea <br />d of ROM <br />for debugging, but this is not always necessary. There typically, but not al <br />ways, is no form <br />of real- time trace. <br /> <br />-- <br /> <br />※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.117.114.7] <br /><a href="00000002.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一页</a><a href="index.htm">回到目录</a><a href="#top">回到页首</a><a href="00000004.htm">下一篇</a></h1></center><center><h1>BBS 水木清华站∶精华区</h1></center></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -