?? 00000008.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手冊end turbolinux </title></head><body><center><h1>BBS 水木清華站∶精華區</h1></center><a name="top"></a>發信人: doot (ltt), 信區: Embedded <br />標 題: BDM手冊end <br />發信站: BBS 水木清華站 (Thu Oct 26 16:25:47 2000) <br /> <br />OCD specifics <br />There are a handful of OCD debuggers available on the market. They range in <br />price from <br />freeware to several thousand dollars. All of them give you the basics: read <br />and write <br />registers, read and write memory, download code, single step, run, etc. Most <br /> give you <br />source level debug capabilities. Some work only with assembly code, others w <br />ith any <br />language. The differences of most concern are how the aforementioned situati <br />ons are <br />handled. Is there “hidden” initialization? Are there “user friendly” tra <br />ps? And what about <br />that start- up stuff? <br />Just like getting out of bed in the morning is tough for many of us, some pr <br />ocessors need a <br />helping hand coming out of reset. Let us assume that my suggestions for desi <br />gning your <br />prototype were ignored. Your target has its boot chip select attached to a R <br />OM chip of <br />some type. Since this is debug time, there is no code in the ROM as of yet. <br />You have a <br />debugger connected to the OCD header and want to start testing your code. Yo <br />u have the <br />debugger reset the target and then download your code. WRONG! Upon reset, th <br />e only <br />properly setup chip select line will be the boot chip select. This is pointi <br />ng to useless ROM. <br />Whatever chip select is attached to your RAM must be initialized. But by who <br /> (or what)? <br />Some debuggers have built in setups for known hardware such as various manuf <br />acturer’s <br />development boards. Usually you can describe your custom target via dialogs <br />to tell the <br />debugger how to setup the board. Other debuggers allow you to write command <br />files <br />(“ macros”, “scripts”, etc.) to do the setup. These files have commands <br />such as WRITEL <br />0x1234, 0x5678 which would write a LONG value of hexadecimal 1234 to locatio <br />n <br />hexadecimal 5678. With some debuggers you must explicitly run the command fi <br />le every <br />time you reset the processor, others do this automatically. Again, the main <br />problem with <br />doing this is that your code is now in an environment that is different from <br /> the reset <br />environment, and your code did not cause this change. If the only command is <br /> a setup of <br />the RAM chip select, this is probably not too big a problem. Probably. <br />Another setup issue is the speed of the target processor. Many of the newer <br />processors use <br />an inexpensive 32 kilohertz crystal along with an on- chip phase lock loop ( <br />pll) to boost the <br />system frequency. Upon reset, the pll is at some default value, quite possib <br />ly a very slow <br />one. Often, your application’s initialization code will set the pll to some <br /> faster value, but <br />during debug this only happens after your code is downloaded. If the debugge <br />r does not do <br />any type of setup (hidden or not) and you do a download (via the boot chip s <br />elect), the <br />processor is most likely running at a slow speed. This will slow down your d <br />ownload which <br />is always too long, no matter what the speed! This is another reason that yo <br />u must <br />thoroughly think about how the setup will work. <br />Talking about speed, one more issue that has not been discussed is raw OCD s <br />peed. All of <br />the OCD protocols are implemented serially. The limit, or maximum OCD speed, <br /> is usually <br />a function of the CPU clock speed. Typically, the OCD may only run one- thir <br />d or one- half <br />of the CPU speed. Most OCD hardware interfaces start at a slow speed since t <br />he processor <br />speed usually cannot be determined. If the speed of the interface is not set <br /> for the maximum <br />speed (either the fastest the CPU will handle or the fastest the interface c <br />an run, which <br />ever is slower) the speed of debugging is affected. This is most obvious in <br />the download <br />speed of code. Some debuggers will allow you to modify the interface speed i <br />n a command <br />file. You would do this only after you set any pll speed, of course. Additio <br />nally, you will <br />probably have to set the interface speed to be slow at the start of the comm <br />and file. Why? <br />Once you RESET the target processor, it is running at its default speed. If <br />this is slow, you <br />must slow the interface to do your pll setup, then speed up the interface. A <br />nd you thought <br />this was going to be easy. Ideally, you may have a macro that runs whenever <br />you hit the <br />debugger RESET TARGET button or command on your debugger that will: <br /> 1. Reset the target CPU <br /> 2. Lower the OCD speed <br /> 3. Set the processor PLL for desired speed <br /> 4. Raise the OCD speed to as fast as the processor will allow <br />So how do you choose a debugger? <br />Bascially, use the information in this paper, ask questions of the vendor, a <br />nd see the <br />debugger in use. Does it work with your favorite compiler? How does it commu <br />nicate with <br />the target? What is the “invasiveness” and are those items fully documente <br />d? <br />I am prejudiced about debuggers. I have written and marketed several from ba <br />sic DOS <br />assembly language based debuggers to complete Windows based high level syste <br />ms. For <br />these reasons, I will leave you to your own devices. Feel free to contact me <br /> for information <br />about debuggers and what I have to offer. <br />Good luck and good debugging. <br />Craig Haller <br />President <br />Macraigor Systems Inc. <br />P. O. Box 1008 <br />Brookline Village, MA 02147 <br />(617) 739- 8693 <br />(617) 739- 8694 - fax <br />www. macraigor. com <br />craig@ macraigor. com <br /> <br />-- <br /> <br />※ 來源:·BBS 水木清華站 smth.org·[FROM: 202.117.114.7] <br /><a href="00000007.htm">上一篇</a><a href="javascript:history.go(-1)">返回上一頁</a><a href="index.htm">回到目錄</a><a href="#top">回到頁首</a><a href="00000009.htm">下一篇</a></h1></center><center><h1>BBS 水木清華站∶精華區</h1></center></body></html>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -