Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
  • G06F11/2268—Logging of test results
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Prevention of errors by analysis, debugging or testing of software
  • G06F11/362—Debugging of software
  • G06F11/3648—Debugging of software using additional hardware

Definitions

• the present invention relates to microcontrollers and memory devices, and more particularly to the use of software breakpoints in memory devices to halt program execution on microcontrollers.
• JTAG Joint Test Action Group
• breakpoints are executed based on instructions processed by a microprocessor during execution of a program.
• a software breakpoint relies on a breakpoint instruction or "breakpoint pattern" that is stored in the memory accessed by the microprocessor.
• breakpoint pattern can be stored in the memory at a particular memory location so that when the program causes the pattern at that location to be executed, the breakpoint occurs.
• the debugging agent instructs the microprocessor to replace the original instruction at a designated breakpoint address in the memory with the breakpoint pattern.
• the replaced, original instruction is stored in other memory.
• the breakpoint pattern is fetched and executed, forcing the microprocessor to enter into a debug state.
• the microprocessor can be instructed to return to non-debug mode by the debugging agent.
• the original instruction is restored to the breakpoint memory address and executed (in some embodiments, the breakpoint pattern can then replace the original instruction again at the breakpoint address), and the microprocessor is returned to normal execution of the remaining program instructions.
• each debugging agent works as a memory monitor, so that each time a software breakpoint is set, the instruction is replaced in the memory with the breakpoint pattern. Each time the breakpoint is passed over or removed, the breakpoint instruction is replaced in the memory with the original instruction.
• setting software breakpoints requires that all system memories be writable.
• a system for providing a software breakpoint for a memory includes a microprocessor, a memory device accessible through a data bus and an address bus coupled to the microprocessor, and processing logic coupled to the memory device and to the microprocessor, the processing logic operative to set the software breakpoint for the memory device by substituting a value to be read from the memory device with a breakpoint pattern, where the breakpoint pattern is sent to the microprocessor on the data bus instead of the value.
• a method for providing a software breakpoint for use with a memory device includes receiving an address value from a microprocessor in a read access of the memory device, and substituting a data value stored in the memory device with a breakpoint pattern and providing the breakpoint pattern to the microprocessor.
• a method for providing software breakpoints for a memory device includes receiving an address and data in a write access from a microprocessor to the memory device, storing the address in a breakpoint cache in a breakpoint management unit if the data matches a breakpoint pattern, and clearing a stored address in the breakpoint cache of the breakpoint management unit if the data does not match the breakpoint pattern.
• the present invention provides an architecture that allows software breakpoints to be used with memory devices in which data cannot be written with a simple microprocessor write access, such as most non-volatile memory devices.
• the present invention allows multiple such memory devices to be provided with software breakpoints with a minimum of additional logic and registers, thus reducing the cost of the system significantly.
• Figure 1 is a block diagram illustrating a prior art system including a microprocessor and memory devices
• Figure 2 is a block diagram illustrating a system of the present invention for providing software breakpoints for a non- volatile memory devices
• Figure 3 is a schematic diagram illustrating an example of the logic used in a software breakpoint management unit of Fig. 2 for clearing and storing software breakpoints;
• Figure 4 is a schematic diagram illustrating an example of the logic used in a software breakpoint management unit of Fig. 2 for providing software breakpoints
• Figure 5 is a flow diagram illustrating a method of the present invention for setting or clearing software breakpoints in a non- volatile memory
• Figure 6 is a flow diagram illustrating a method of the present invention for reading software breakpoints in a non- volatile memory.
• the present invention relates to software breakpoints for use with memory devices to halt program execution on microcontrollers.
• the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements.
• Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art.
• the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
• he present invention is mainly described in terms of particular systems provided in particular implementations. However, one of ordinary skill in the art will readily recognize that this method and system will operate effectively in other implementations.
• the present invention will also be described in the context of particular methods having certain steps. However, the method and system operate effectively for other methods having different and/or additional steps not inconsistent with the present invention.
• FIGURE 1 is a block diagram of a prior art system 10 including a microprocessor and on-chip memory devices.
• System 10 includes microprocessor 12, random access memory (RAM) device 14, non- volatile memory (NVM) device 16, system address decoder 18, and bitwise data multiplexer 20.
• RAM random access memory
• NVM non- volatile memory
• Microprocessor 12 generates control signals when performing read or write accesses to slave devices (such as the memory devices 14 and 16).
• the RAM device 14 is able to store data which can be later overwritten or erased.
• the NVM device 16 stores data, but cannot traditionally store a software breakpoint pattern, since that pattern cannot be written into the memory with a simple microprocessor write access.
• nonvolatile memory devices such as ROM (read-only memory), EPROM (Electrically Erasable Read-Only Memory) and flash memory, are unsuitable for use with software breakpoint patterns at least for this reason.
• the microprocessor 12 control signals include a read/write control signal 30, an access size control bus 32, an address bus 34, and a write data bus 36.
• the read/write control signal 30 selects the read or write operation for a memory device 14 or 16.
• the address bus 34 is coupled to the system address decoder 18; the access size control bus 32 can also be coupled to the decoder 18 if address misalignment is to be managed.
• the system address decoder 18 generates slave select signals to each slave device to indicate to the slave devices to perform a transfer requested by the master (the microcontroller 12), such as a read or a write operation.
• Slave select signal 38 is sent to RAM device 14, and slave select signal 40 is sent to ROM device 16.
• the write data bus 36 couples the microprocessor 12 to the memory devices 14 and 16 provides the data from the microprocessor 12 that is to be written in RAM device 14.
• FIGURE 2 is a block diagram of one embodiment of a system 100 of the present invention for providing software breakpoints for a system including volatile and nonvolatile memory devices.
• System 100 includes microprocessor 102, RAM device 104, nonvolatile memory (NVM) device 106, system address decoder 108, software breakpoint management unit (SBMU) 110, and bitwise data multiplexer 112.
• Microprocessor 102 generates control signals when performing read or write accesses to slave devices (such as the memory devices 104 and 106). hi the described embodiment, the microprocessor 102 is included on the same chip or integrated circuit as the other components of system 100. hi other embodiments, the microprocessor 102 can be provided separately from the other components. Microprocessor 102 can be any type of suitable microcontroller.
• the RAM device 104 is able to store data which can be later overwritten or erased, and thus can easily store standard software breakpoints from a debugging agent typically run externally and operating through microprocessor 102.
• RAM device 104 can be any of a variety of programmable memory devices, typically volatile memory such as static random access memory (SRAM).
• SRAM static random access memory
• the NVM device 106 is a non-volatile memory device that stores data that can be read by microprocessor 102. However, data cannot be easily written or changed by a simple microprocessor write access.
• non-volatile memory device refers to standard read-only memory (which is programmable only once), electrically programmable read only memory (EPROM), electrically erasable read-only memory (EEPROM), and flash memory, as well as any other similar types of non- volatile memory. All of these referred types of memory cannot be easily used with software breakpoints, since they do not have the versatility in programming that volatile memory such as RAM 104 has, and cannot have data written to them with a simple microprocessor write access.
• the control signals produced by microprocessor 102 include a read/write control signal 120, an access size control bus 122, an address bus 124, and a write data bus 126.
• the read/write control signal 120 selects the read or write operation to enable that operation for a memory device 104 or 106.
• the address bus 124 is coupled to the system address decoder 108 to provide addresses in memory device 104 or 106 to the decoder 108.
• the access size control bus 122 can also be coupled to the decoder 108 if address misalignment is to be managed.
• the system address decoder 108 generates slave select signals for the slave devices to indicate to the appropriate slave device to perform a transfer requested by the master (the microprocessor 102), such as a read or a write operation.
• the slave select signal 128 is provided to RAM device 104, and the slave select signal 130 intended for NVM device 106 is provided to the software breakpoint management unit (SBMU) 110.
• SBMU software breakpoint management unit
• the write data bus 126 couples the microprocessor 102 to the memory devices 104 and 106 and SBMU 110 and provides the data from the microprocessor that is to be written to a memory device 104 or 106 at the location specified by the address value on the address bus 124 (a write data bus can be used for NVM device 106 if it is an EEPROM or flash memory, for example).
• a software breakpoint pattern can be sent on the write data bus
• debugging agent which is typically used when debugging an application program.
• the debugging agent can also send the original instruction, that was replaced by the breakpoint pattern, on the write bus 126, to replace the breakpoint pattern.
• an exception occurs such that the execution of the program is halted and an exception handler momentarily takes control of the processor, provides information to the debugging program, etc.
• the SBMU 110 manages software breakpoints that are set for NVM device 106.
• the SBMU 110 filters the incoming slave select signal 130 for NVM device 106 by replacing it with a new slave selection signal 140 for the NVM device 106.
• the selection signal 140 is sent to the NVM device 106 to perform a normal read operation when the microprocessor's read access does not correspond to a breakpoint, i.e., when the read access is at an address that is not a breakpoint address.
• the SBMU 110 does not provide selection signal 140, and instead substitutes the breakpoint pattern via the SBMU output data bus 142.
• the SBMU 110 bypasses the response from NVM device 106 given through the NVM output bus 134 by filtering the NVM selection signal 140 when the instruction fetch corresponds to a breakpoint.
• the SBMU 110 For a write access to NVM device 106, the SBMU 110 detects and checks the write operations. If the SBMU 110 detects the write of a breakpoint pattern, the related address is stored into an address cache as a breakpoint address, thus effectively storing the software breakpoint for the NVM device 106. If the SBMU 110 detects the write of the original instruction to be restored (data that is not the breakpoint pattern), then the related breakpoint address cache is released (cleared). This operation is described in greater detail below with respect to Figs. 3-6.
• the output bus 132 of RAM device 104, the output bus 134 of NVM device 106, and the output bus 142 of SBMU 110 are coupled to the bitwise data multiplexer 112, which multiplexes the output buses 132, 134, and 140 and provides data on these buses to the microprocessor 102 via a read data bus 136.
• the multiplexer 112 also receives the memory selection signals 128 and 140, as well as an SBMU selection signal 143, which informs the multiplexer whether to send the data on the SBMU data bus 142 over the read data bus 136 (i.e., when a read access to a breakpoint address is made), or to send the data on the NVM output bus 134.
• additional non- volatile memory devices can be coupled to the software breakpoint management unit (SBMU) 110, where the SBMU can provide software breakpoints for any and all of the connected non-volatile memories.
• the system address decoder 108 can send an additional selection signal to the SBMU 110 for each additional non- volatile memory device used, and SBMU 110 can send a corresponding selection signal to an additional non-volatile memory device when appropriate.
• decoder selection signal 131 for a second non- volatile memory device can be sent from system address decoder 108 to SBMU 110, and SBMU 110 can send out selection signal 141 to the second non- volatile memory device (not shown).
• SMBU 110 control software breakpoints for multiple non- volatile memory devices is a major advantage of the present invention, since the processing logic or cache memory of the SBMU does not need to be duplicated for each additional non- volatile memory device, thereby greatly reducing the logic and registers needed, as well as the cost of the system.
• FIGURE 3 is a schematic diagram of a store and clear breakpoint circuit 200 that is included in the software breakpoint management unit (SBMU) 110 of Fig. 2.
• This circuit 200 is used when a debugging agent wishes to store a software breakpoint in the NVM device 106, or when the debugging agent wishes to restore the original instruction in the NVM device 106 at the memory location storing the software breakpoint.
• the SBMU 110 allows N software breakpoints to be stored (set), using N sets of dedicated registers in the SBMU.
• the software breakpoint that is being stored or cleared is labelled I, and one or more other software breakpoints are labelled J, where I and J are indexes into the range between 0 and (N-I) breakpoints.
• a software breakpoint pattern is stored in a breakpoint pattern register 202.
• this same breakpoint pattern is used as the pattern for all stored breakpoints for NVM device 106.
• This pattern when recognized by the software on the microprocessor during regular execution of code, causes a break in the program execution for debugging purposes.
• the breakpoint pattern is sent from register 202 via bus 204 (bus 204 is equivalent to the output bus 142 in Fig. 2) to comparator 206, which compares the breakpoint pattern to data received on the input write data bus 126.
• the data on the write data bus 126 is data that the debugger running on microprocessor 102 wishes to write to the NVM device 106. If the data on the write bus 126 is a breakpoint pattern, then it is a storing operation, in which the debugger wishes to store the breakpoint at a specified address. If the data is other data that is not the breakpoint pattern, then it is assumed to be a clear operation, in which the debugger wishes to restore the original data that was stored at the breakpoint's memory address.
• the comparator 206 compares the breakpoint pattern to the data and generates a comparison flag 208 indicating whether the two inputs to the comparator are equal (high) or not (low). If the data on the comparator's two inputs are equal, the data on the write data bus 126 matches the software breakpoint pattern.
• the non- volatile memory input selection signals 130 and 131 are provided by the system address decoder 108, where signal 130 is the selection signal for NVM device
• 106 and signal 131 is the selection signal for a different non- volatile memory device, if present. These signals can select which of multiple non- volatile memories, including NVM device 106, that the microprocessor wishes to read data from. If additional nonvolatile memory devices are used, then each additional memory device can have its own signal similar to signals 130 and 131.
• the selection signals 130 and 131 (and any other selection signals) are logically combined at OR gate 212 to generate a global selection signal 214, indicating that a non- volatile memory device has been selected.
• the comparison flag 208, the read/write control signal 120 (with a write command or inverted read command, and from microprocessor 102 as shown in Fig.
• the store breakpoint command if true, indicates that the debugger's write access to NVM device 106 is a store breakpoint operation, and that the characteristics of the current write access on bus 126 must be stored.
• a breakpoint status register 220 stores a status bit or "tag" for the breakpoint I; if the bit is 0, then the registers for breakpoint I are not in use, and if the bit is 1, the registers are in use.
• the bit from status register 1220 is sent out on line 222 to an inverter 224, which generates a flag signal 226.
• breakpoint J There are also (N -I) other software breakpoints that can be stored in dedicated registers in the SBMU 110. Each of these other breakpoints has a breakpoint status register similar to register 220 and an address register similar to address register 236, as well as its own logic circuit similar to circuit 200, and which are not shown in Fig. 3. Any other software breakpoint that was set prior to the current breakpoint I is referred to herein as breakpoint J, where J ⁇ I.
• Status register bits 227 from the breakpoint status registers J are subject to a bitwise AND operation at AND gate 228, i.e., all the J status bits are ANDed.
• a status flag signal 230 is generated from the AND gate 228 that indicates when all of the previous set of registers J (where J ⁇ I) are already in use, i.e., when the breakpoints J were previously set and are already in use.
• Status flag signal 230, store breakpoint command 218, and status flag signal 226 are all input to AND gate 232 which generates a store breakpoint I command 234.
• the command 234 is only generated when all previous breakpoints are in use, when the current breakpoint register is free to store a breakpoint, and when the incoming data of a write operation matches the breakpoint pattern.
• the store breakpoint command 234 is provided from AND gate 232 to the breakpoint I address register 236, and is used to enable the storage of the value of the input address bus 124 in the address register 236. Other portions of the circuit 200 are used when a software breakpoint is to be stored or cleared.
• the input address bus 124 is compared to the addresses stored in the breakpoint pattern registers.
• a comparison flag 240 is generated by the comparator 238, and this flag indicates whether or not the data on the address bus 124 matches the breakpoint address where the software breakpoint I has been set.
• the comparison flag 240 If the comparison flag 240 is true, a match has occurred, and the action to be taken depends on whether it is currently a write access to clear the breakpoint by the debugger, or a read access during program execution to read the instruction at the breakpoint address. This write or read access is indicated by the control signal 120. If the current access is a write access, then the related breakpoint I in use can be cleared (if the incoming pattern is not equal to the software breakpoint pattern) or stored (if the incoming pattern is equal to the software breakpoint pattern). If the current access is a read access, then the SBMU 110 can return the software breakpoint pattern stored in the breakpoint pattern register 202 on the output data bus 142 to the bitwise data multiplexer
• the matching software breakpoint pattern comparison flag 208 is sent to an inverter 250 to be inverted, generating a flag 252 that, if it is high, indicates that the data on the incoming write data bus 126 is not equal to the software breakpoint pattern, and thus is a clear operation.
• Flag 252 write input command signal 120, and global selection signal 214 are input to AND gate 254, which produces a clear breakpoint command 256.
• the clear breakpoint command 256, the breakpoint I status register bit 222 (indicating, if high, that the breakpoint I is in use), and the address comparison flag 240 (indicating that the addresses of the data to be written and the address register 236 match) are all input to AND gate 258, which produces a clear breakpoint I signal 260.
• the clear software breakpoint I command 260 is active only when the breakpoint I registers are in use, when the input address bus matches the breakpoint I address, and when the current write access is not to store a breakpoint pattern.
• a breakpoint management enable status register 262 stores an enabled status or a disabled status for breakpoint management. In the described embodiment, only when this register 262 is enabled can a breakpoint be stored. Typically, the management register 262 is enabled during debugging.
• the register's status is sent as signal 264 to an AND gate 266.
• the store breakpoint I command 234 and the breakpoint I status register bit 222 are input to an OR gate 268, whose output 271 is a set breakpoint status register bit command provided to the AND gate 266.
• the third input to the AND gate 266 is the clear breakpoint I command 260 which has been inverted by inverter 270 on line 272.
• the AND gate 266 produces a set/clear breakpoint I status register bit command 274, which is provided to the breakpoint I status register 220 to set its state.
• a breakpoint I "in use" status is set in breakpoint I status register 220 only when a store breakpoint I command 234 is active and while the clear breakpoint I command 260 is not active.
• the breakpoint I status register 220 is cleared only when a clear breakpoint I command 260 is active (which is also when the breakpoint management of the system is disabled through register 262).
• the breakpoint I status register is cleared, then the set of registers for breakpoint I is considered cleared, and a new address for a new breakpoint can then be written into address register 236 (over the old address).
• FIGURE 4 is a schematic diagram of a breakpoint providing circuit 300 included in the software breakpoint management unit (SBMU) 110 of Fig. 2 for providing a breakpoint pattern instead of a stored instruction during a read access.
• the breakpoint pattern is provided when the microprocessor 102 requests data at the breakpoint address with a read operation to NVM device 106.
• the circuit 300 When microprocessor 102 (or other master device) is performing a read access to a memory location where a software breakpoint has been previously set, the circuit 300 is in charge of providing the breakpoint pattern to be put on the read data bus 136 in place of the data in the non- volatile memory 106 that the microprocessor 102 is intending to access.
• the breakpoint pattern is stored in the breakpoint pattern register 202 (as also shown in Fig. 3) which sends out the breakpoint pattern on bus 142 to the multiplexer 112 as shown in Fig. 2.
• Circuit 300 includes additional logic used to filter selection signals for multiple non- volatile memory devices such as NVM device 106 while generating a selection signal related to the SBMU 110 that is provided to the multiplexer 112. This additional logic used to filter selection signals is used if a multiplexed architecture is used for the read data bus, or in any other architectures, since data selection or enable (for tri-state busses) needs this filtering.
• the address stored in the breakpoint I address register 236 and the incoming address bus 124 are input to a comparator 304, which compares the signals and generates a comparison signal 306 indicating if the data on the address bus 124 matches the address related to the breakpoint I location.
• the non- volatile memory selection signals 130 and 131 are provided to OR gate 212 (the same as in Fig. 2) to produce the single non- volatile memory selection signal 214.
• the selection signal 214, the match breakpoint I address comparison signal 306, a read control signal 312 from the microprocessor 212 (which is active high during read operations), and the breakpoint I status register bit 222 from breakpoint I status register 220 are provided as inputs to AND gate 314.
• AND gate 314 produces the signal 316 which indicates whether the current read access matches the breakpoint I address.
• Each of the N software breakpoints provided by the system 100 requires a comparator coupled to an AND gate using the same input signals, similar to comparator 304 and AND gate 314, and which are not shown in Fig. 4.
• the addresses of the other in-use breakpoints J in the SBMU 110 are compared to the current read access by their respective comparators and AND gates.
• AU the resulting signals (similar to signal 316), each indicating whether the current read access matches a software breakpoint J address (with J different than I), are represented as bus 318 in Fig. 4 and are provided at inputs of an OR gate 320.
• the breakpoint I signal 316 is also provided at an input of OR gate 320, and the OR gate produces a signal 322 that indicates whether the current read access matches a software breakpoint location, i.e., matches an address of any breakpoint currently in use by the debugger in SBMU 110.
• Signal 322 is provided to an input of AND gate 324 along with the status flag 264 from the software breakpoint management enable status register 262, which indicates whether the breakpoint management is enabled (register 262 is set as a result of a configuration made through the microprocessor 102 or from a test configuration; breakpoint management and the SBMU 110 can be enabled or disabled (default is disabled), so that the SBMU functionality is only enabled when necessary).
• the output of AND gate 324 is a SBMU data selection signal 143.
• the selection signal 143 is output from the SBMU and is also input to an inverter 330 which generates a flag 332 indicating whether there is (low), or is not (high), a breakpoint set at the address which is being accessed.
• Flag 332 is used as a gate signal for the selection signals 140 and 141, where the flag 332 is provided at an input to the AND gate 334 and an input to the AND gate 336, and the selection signal 130 is input to AND gate 334 while the selection signal 131 is input to AND gate 336.
• the flag 332 acts to let through needed memory selection signal 130 to the NVM device 106 as signal 140 (or lets through signal 131 as signal 141 to a different non- volatile memory device) only when the read access is not performed at a location storing a software breakpoint. This allows the NVM device 106 to provide non-breakpoint data stored at the address requested by the microprocessor.
• the SBMU selection signal 143 is received and used by the read data bus multiplexer 112 to cause the multiplexer 112 to select the breakpoint pattern received from the SBMU 110 on bus 142 from the breakpoint pattern register when a read access to a breakpoint address is performed, instead of selecting data from the bus 134 received from the NVM device 106 (the breakpoint pattern register 202 preferably is always sending out the breakpoint pattern).
• the multiplexer 112 then sends the breakpoint pattern to the microprocessor 102 on bus 136 as shown in Fig. 2.
• the present invention thus allows software breakpoints to be set for multiple different memory devices using a minimum of components.
• the logic of the SBMU 110 is able to manage several software breakpoints at system frequency (full speed) on one or more memory devices without any addition of cache memory or complex logic.
• the logic described above in Figs. 3-4 can manage N software breakpoints and need only include one programmable register able to define the breakpoint pattern
• N registers for address storage
• N status register bits 220 to provide in-use status for the breakpoints
• N comparators 238 to compare an input address with the stored addresses in the address registers.
• additional components can be included.
• N registers (where N is the number of breakpoints) can be provided for memorizing the size of a written breakpoint pattern in addition to the breakpoint address, if the breakpoint can be different than a data default size.
• An additional status register can be included to indicate whether the maximum number of software breakpoints that the SBMU 110 is able to manage, have been set.
• pipeline stages can be included in the implementation of the invention, as required by system bus architecture, as is well-known. If such pipeline stages are used, then the buses and lines shown in Fig. 2 may be passed through pipeline stage(s) before or after their equivalents are shown in Figs. 3 or 4. For example, buses and lines 120, 124, 130, 131, and 126 of Fig. 2 can be passed through a synchronization stage (pipeline stage) before being received at components as shown in Figs. 3 and 4.
• a synchronization stage pipeline stage
• FIGURE 5 is a flow diagram illustrating a method 400 of the present invention for managing software breakpoints during a write access to a non- volatile memory, such as NVM device 16. This process describes setting or clearing a software breakpoint; the process including reading a breakpoint pattern previously set is described below with respect to Fig. 6.
• the method starts at 402, and in step 404, the SBMU 110 receives a breakpoint write access command from the microprocessor 102, typically originating from a debugger program agent (typically running on a device separate from the microprocessor) that the user is utilizing during debugging procedures.
• the write access usually includes an address in the memory (provided on address bus 124), and data that is to be written to that address
• the debugger does not know this, and assumes it can be written to.
• the debugger can use a JTAG port to send data directly to a memory device via the microprocessor without requiring any application running on the microprocessor to talk to the memory.
• the debugging agent may wish to set (i.e., write) a software breakpoint instruction at a particular address of the NVM device 106, referred to herein as the "breakpoint address.”
• This typically entails replacing an existing original instruction at the breakpoint address with the breakpoint instruction (or "pattern").
• the original instruction can be stored in an intermediate memory location or register while the breakpoint is being used).
• the breakpoint pattern is desired to be placed at a memory location which will be accessed during execution of the program stored in the NVM device 106 which is being debugged, and the user wishes to halt program execution for debugging purposes, e.g.
• the microprocessor copies the original instruction at the breakpoint address to an intermediate location before writing the breakpoint pattern at the breakpoint address.
• the original instruction is one of the instructions of the program that is being executed (and debugged). This intermediate location can be located anywhere in memory or other storage area. Alternatively, the debugger may wish to remove or clear a previously- written software breakpoint with the write access received in step 404, by replacing the breakpoint pattern with the original instruction.
• the SBMU 110 catches the address and data of the write access that is intended for NVM device 106, and compares the data portion of the write access with the breakpoint pattern, which the SBMU 110 has stored in its breakpoint pattern registers. It is assumed herein that the breakpoint pattern is unique and not similar to any actual data.
• hi step 408 it is checked whether the input data for the write access is the same as the breakpoint pattern. If so, then the debugger is trying to set a breakpoint at the address specified in the write access (a breakpoint address). If this is the case, in step 410 the SBMU 110 stores the address portion of the write access in an internal cache, such as register 236 in the embodiment of Fig. 3, as a tagged breakpoint address.
• the address is stored only in a register that is free and does not already hold a different software breakpoint that is in use. This address is tagged, indicating that the breakpoint at this address is in use, and that no other breakpoints can be stored at this address. For example, a status register like register 220 of Fig. 3 can be associated with the address register 202 and can have a bit set as the tag.
• the process is then complete at 414. If the input data does not match the breakpoint pattern in step 408, then the process continues to step 412. This is assumed to indicate that the debugger is trying to clear the breakpoint by replacing the breakpoint pattern at the address specified in the write access with the original instruction; the original instruction is the data portion of the write access.
• the SBMU 110 clears (releases) the cache storing the breakpoint address that matches the input address in the write access.
• the clearing of the breakpoint is accomplished by clearing status register 236, associated with the matching address cache (the address in the address register need not be cleared, and can be written over with another breakpoint address).
• SBMU does not examine the original instruction (the data itself) that is included in the write access, and makes the assumption that if the debugger wishes to store data at the breakpoint address that is not the breakpoint pattern, it is the original instruction. Note that, since the original instruction was never actually replaced by the breakpoint pattern in the NVM device 106, the original instruction sent in the write access does not need to be written in any memory. The process is then complete at 414.
• the SBMU 110 can store N breakpoints, where N is one less than the number of programmable registers (one register is needed to program the breakpoint pattern in relation to the debugger in use). If all the available registers store a breakpoint that is in use, then additional breakpoints are not stored. However, as soon as a software breakpoint is cleared, a new breakpoint can then be set.
• FIGURE 6 is a flow diagram illustrating a method 450 of the present invention for managing software breakpoints for a read access of a non- volatile memory during program execution.
• This process describes the situation where the microprocessor 102 executes a program having code instructions stored in the NVM device 106, a request is made to read the breakpoint address, and a software breakpoint is provided to the microprocessor.
• This read access occurs during the execution of the program running on the microprocessor 102, and is typically not initiated by the debugging agent. If the microprocessor retrieves what it recognizes as a breakpoint pattern, it will halt execution, allowing the user to debug the program more easily.
• the method starts at 452, and in step 454, the SBMU 110 receives a read access radical
• code fetch (code fetch) request that is intended for data stored in the NVM device 106.
• the code fetch request includes an address in the NVM device from which the data is desired to be retrieved, provided on address bus 124 of Fig. 2.
• step 456 the SBMU checks whether the address of the fetch request matches any of the cached and tagged addresses.
• the tagged addresses are those addresses used to store a software breakpoint, and the software breakpoints are actually stored in a cache (such as registers) in the SBMU 110, as described above with reference to Fig. 3, and not in NVM device 106. If the read access request address does not match any tagged addresses, then the requested address does not hold a breakpoint, and the process continues to step 458, in which the SBMU 110 allows a normal read access of the data at the requested address in the NVM device 106. hi the embodiment of Fig. 2, the SBMU 110 can provide the select signal 140 to the NVM device 106 to allow the read operation.
• the requested data at the requested address is sent by the NVM device 106 to the multiplexer 112 and to the microprocessor via the read data bus 136.
• the process is then complete at 462. If the fetch request address does match a tagged address at step 456, then the microprocessor 102 has requested an address that stores a breakpoint, and the process continues to step 460.
• the SBMU 110 overrides (or bypasses) the read access to the NVM device 106 and instead substitutes the breakpoint pattern for any data at that address in the NVM device.
• the breakpoint pattern stored in a register of the SMBU, is provided to the multiplexer 112, which provides the pattern to the microprocessor 102 via the read data bus 136.
• the process is then complete at 462.
• the microprocessor 102 executes the received breakpoint pattern and performs the appropriate exception routines. After the exception, if the original instruction (that was replaced by the breakpoint pattern) needs to be executed, then the write access request to restore the original instruction (and clear the breakpoint) can be processed by the SBMU as described above with reference to Fig. 4. Similarly, the process of Fig. 4 handles a write access for setting a breakpoint in the NVM device 106.
• the present invention may be suitable for other types of memory devices which may be volatile, and which are not easily used with software breakpoints and not able to be written to by a simple microprocessor write access.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Quality & Reliability (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Debugging And Monitoring (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=36692857

Family Applications (1)

Country Status (2)

Family Cites Families (2)

• 2006
  • 2006-01-18 EP EP06718861A patent/EP1849073A2/de not_active Withdrawn
  • 2006-01-18 WO PCT/US2006/001853 patent/WO2006078790A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events