소프트웨어, 하드웨어 브레이크 포인트의 차이?

소프트웨어, 하드웨어 브레이크포인트의 차이 ??

여러가지 기술 Tip 2008/10/29 09:34

CCS를 이용하여 C2000을 개발하다보면 각종 변수의 상태 및 DSP 동작의 확인을 위해 브레이크포인트를
활용하게 됩니다.

이 브레이크포인트는 소프트웨어 브레이크포인트와 하드웨어 브레이크포인트로 구분이 되는데요.
이 둘의 차이에 대해 설명한 좋은 글이 TI Knowledge-Base에 있어 옮겨왔습니다.


Q: What is the difference between software and hardware breakpoints?

A: As the names might indicate, a hardware breakpoint is implemented in hardware and a software breakpoint is implemented in software.  But what does that mean to the user?  When should they use a hardware breakpoint? A software breakpoint?  What are the advantages and disadvantages of each?

SOFTWARE BREAKPOINTS
When a software breakpoint is set, the emulation driver reads the instruction at that location, removes the first byte of the instruction, and replaces it with a software breakpoint opcode.  This software breakpoint opcode is what tells the CPU to halt at this instruction.  The byte that was removed from the instruction is then placed into a breakpoint table where it is associated with the address that it was removed from.   The driver will then read back the instruction to be sure that the breakpoint has been set properly.
 
When a RUN is issued from the Code Composer Studio, the CPU is started running.  Periodically, CCS polls the target for status to see if it has halted.  As long as the CPU continues to run, CCS does nothing except continue polling.  If CCS determines that the CPU has halted, it first queries the CPU to see how it halted. (i.e. software breakpoint, hardware breakpoint, embedded breakpoint, user halt)  If the CPU returns a status of “Halted by Software Breakpoint”, the driver reads the PC, looks up the breakpoint in the breakpoint table, and replaces the breakpoint opcode with the byte from the actual instruction. (The user should never see the breakpoint opcode in the disassembly window.)  If the breakpoint remains enabled after the instruction has been executed by either a run or a step, the first byte of the instruction gets replaced again by the software breakpoint opcode.

Since software breakpoints are implemented in software, their number is virtually unlimited.  So long as there is memory on the host to store the breakpoint information, a software breakpoint can be implemented.  However, software breakpoints can only be used in RAM.  If the target memory cannot be written to, then the breakpoint opcode cannot be inserted.  If it’s necessary to set a breakpoint in ROM, Hardware Breakpoints should be used.

HARDWARE BREAKPOINTS
As noted earlier, Hardware Breakpoints are implemented in hardware.  This means that there are physical hardware units located on chip to enable hardware breakpoints.  The Breakpoint portion of these analysis units is basically a set of address comparators.  The user can program the comparators to watch for a specific address on the Program Address bus.  When that address appears on the bus, the breakpoint triggers and halts the CPU.

While the CPU is running, CCS simply continues to poll the target for status until it sees a HALT.  If a hardware breakpoint is encountered, CCS first checks why the target is halted.  A Hardware Break status tells CCS that it has to do nothing in the way of checking the breakpoint table.

The advantage of hardware breakpoints that they can be used in any type of memory.  A hardware breakpoint works as well in RAM as in ROM.  However, the limitation of hardware breakpoints is that there is a very small number of them.  Typical TI targets usually have 2 or 4 hardware breakpoints on chip.  Targets with cTOOLS will have more.  Additionally, these analysis units can be used for more than just hardware breakpoints.  They also can have event counters and timers on them.  If a counter or timer is being used, that’s one less unit that’s available for a hardware breakpoint.

EMBEDDED BREAKPOINTS
An embedded breakpoint is a breakpoint that is implemented in target code.  Not all targets necessarily have embedded breakpoints.  On the C55x, the embedded breakpoint is implemented with the estop_1() assembly instruction.  Embedded breakpoints are really software breakpoints, but they are implemented in the target application, and the debugger doesn’t have to do anything with the breakpoint table.

Embedded breakpoints only work if an emulator and debugger are connected to an application.  This keeps code in the field from inadvertently halting if an embedded breakpoint has been implemented in code.  If a debugger is not connected, the embedded breakpoint is handled as a nop.



** Code Composer Studio will automatically take care of deciding between a hardware and a software breakpoint if the memory is mapped correctly.  If no memory map is used, CCS will only try to set a software breakpoint.  If the memory is not RAM, the Breakpoint set will fail;

출처: http://www.tms320blog.co.kr/books/125