Hardware Breakpoints

Hardware Breakpoints use special on-chip breakpoint registers found on only a few devices. Microcontrollers with hardware breakpoint registers support only a few breakpoints (typically 1-4). But, they require almost no overhead and allow programs to execute at full speed.

ISD51 currently supports hardware breakpoints on the TI MSC1210 devices. This feature must be enabled in the ISD51.H header file using the TI_MSC1210_BREAKS #define.

When this feature is enabled, hardware breakpoints may be used with these TI devices.

Known Issues

Following is a list of issues with hardware breakpoints on the MSC1210 devices:

• Program execution may stop up to two CPU instructions after a breakpoint. This is a chip limitation and not a limitation of the software.
• The Read and Write attributes are ignored for XDATA access breakpoints. Program execution stops on any access to the specified address.
• Hardware breakpoints require use of the interrupt 6 vector (address 0x33). Unfortunately, this interrupt is also used for other on-chip peripherals such as the A/D Converter, (milli)second timer, PFI, and SPI interface. ISD51 redirects interrupts for these peripherals to interrupt 13 (address 0x6B). If your application uses peripherals that generate interrupt 6, you must change your interrupt service routine to use interrupt 13 instead.
• Program execution may stop on the wrong address due to instruction prefetches. When a prefetch occurs on a break address, the breakpoint is triggered even when the instruction is not executed. This can happen in the following situations:
  1. Breakpoint after a loop:

     void func(void) {
       while(...) {
         ...;
       }
       ...;        // a breakpoint here may be triggered...
                   // even when the loop has not completed
     }
     

  2. Breakpoint at the beginning of a function:

     void func1(void) {
     ...
     }
     
     void func2(void) {  // a breakpoint here may be triggered
                         // when the CPU is at the end of func1
     ...
     }
     

     Note

     • The linker does not locate functions in ascending sequence. Therefore, the function order in the C source module may not match the order in which functions are stored in memory. Review the function segment information in the linker map (*.M51) file or use the disassembly window to determine the function order in memory.
  3. Breakpoint after a function call:

     void func1(void) {
     ...
       func2();
     ...         // a breakpoint here may be triggered
                 // at the beginning of func2
     }
     

     Note

     • This affects the Step-Over command which inserts a breakpoint after CALL instructions. The CPU may stop at the beginning of the called function.