Search the Community
Showing results for tags 'EEM'.
Found 1 result
-
Hi, Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0: #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled! For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs: if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data } As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong! They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later... To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints! Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime. All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire. DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
-
- 7
-
-
- Breakpoint
- Debug
- (and 1 more)
