A method for blocking external debugger application from analysing code of software program installed on computing device. The method including initializing software program including an application program and an internal debugger application. The software program, upon initialization thereof, instructs internal debugger application to load application program in internal debugger application. The internal debugger application is configured to utilize kernel resources of an operating system of the computing device. The method includes executing internal debugger application to set one or more break-points in code of application program to define execution path for code of application program, executing application program as per defined execution path for code thereof, stopping execution of code of application program upon reaching any of one or more break-points therein, and handing control to internal debugger application to provide an address for next instruction to be executed in defined execution path for code of application program.

Systems and methods for debugging multi-core processors with configurable isolated partitions have been described. In an illustrative, non-limiting embodiment, an integrated circuit, may include: a plurality of Cross-Trigger Matrices (CTMs) configured to establish a debug network among a plurality of multi-cluster tiles (MCTs), where each MCT includes a plurality of processor cores, and where each processor core is assigned to a respective isolated partition of processor cores; and a System Interface (SI) coupled to the plurality of CTMs, where the SI is configured to control the plurality of CTMs to enable or disable at least a portion of the debug network to allow an isolated partition to be debugged independently of another isolated partition. A method may include enabling or disabling, by the SI, buses between the MCTs to create isolated debug networks, each isolated debug network corresponding to a distinct isolated partition of processor cores.

The present disclosure relates to a computing platform and a relative computer implemented method for synchronize the prototype execution and simulation of hardware devices. The computing platform (1) comprises a debugger module (2), a memory (3) for storing instructions and data of a computer program; a CPU (4) configured for executing said computer program; said debugger module (2) being in signal communication with said memory (3) through a first debugger channel (dbg2Mem). Characteristic of the computing platform is that it comprises at least one pin (7) and at least one trigger point module (8), said at least one pin (7) being connectable to an electronic device (Ext) that is external to the computing platform; said at least one trigger point module (8) being in signal communication with said at least one pin (7) through a first trigger channel (tgr2pin), said debugger module (2) through a second trigger channel (t2d), said CPU (4) through a third trigger channel (tProbe), said at least one trigger point module (8) having a first register (10a) for storing a first trigger point (RefStartTrgPnt) that corresponds to a first instruction of said program to be monitored.

Embodiments of recovering data in computing devices and associated methods of operations are disclosed therein. In one embodiment, a method includes receiving a failure notification indicating that a core of a main processor is experiencing a catastrophic failure causing the core unable to execute instructions. In response, a flush command can be issued to an uncore of the processor via a debug port instructing the uncore to copy any data currently residing in a processor cache of the main processor to a volatile memory. The method further includes issuing a self-refresh command causing the volatile memory to enter a self-refresh mode in which the data copied from the processor cache is maintained and unmodifiable by the main processor during a reset of the main processor.

Embodiments include apparatuses, methods, and computer devices including a processor and a device programmer coupled to the processor. The processor may detect an error during an execution of a program on the processor, and transmit an error message to the device programmer. Afterwards, the processor may receive a probe input signal from the device programmer to stop the execution of the program on the processor, and transmit a probe output signal to the device programmer to indicate that the execution of the program on the processor has stopped. On the other hand, the device programmer may receive the error message from the processor, and transmit the probe input signal to the processor to stop the execution of the program on the processor. Afterwards, the device programmer may receive the probe output signal from the processor.

A processor includes an execution pipeline that includes a plurality of execution stages, execution pipeline control logic, and a debug system. The execution pipeline control logic is configured to control flow of an instruction through the execution stages. The debug system includes a debug pipeline and debug pipeline control logic. The debug pipeline includes a plurality of debug stages. Each debug pipeline stage corresponds to an execution pipeline stage, and the total number of debug stages corresponds to the total number of execution stages. The debug pipeline control logic is coupled to the execution pipeline control logic. The debug pipeline control logic is configured to control flow through the debug stages of debug information associated with the instruction, and to advance the debug information into a next of the debug stages in correspondence with the execution pipeline control logic advancing the instruction into a corresponding stage of the execution pipeline.

An apparatus includes an event message generator configured to generate an event message. The apparatus further includes a filter circuit configured to receive the event message and to send a first portion of the event message to a destination device. The filter circuit is further configured to selectively send a second portion of the event message to the destination device at least partially based on an event traffic load associated with the destination device.

Roughly described, a method of powering down a portion of an integrated circuit chip, the portion of the integrated circuit chip comprising a plurality of peripheral circuits, each peripheral circuit being connected to a respective debug unit, the method comprising: prior to power down, extracting from each debug unit configuration information of that debug unit; storing the configuration information of the debug units in a memory on the integrated circuit chip during power down of the portion of the integrated circuit chip; and on power up, restoring the configuration information of each debug unit to that debug unit prior resuming operation of that debug unit and the peripheral circuit connected to that debug unit.

Apparatus and methods are disclosed for nullifying memory store instructions and one or more registers identified in a target field of a nullification instruction. In some examples of the disclosed technology, an apparatus can include memory and one or more block-based processor cores configured to fetch and execute a plurality of instruction blocks. One of the cores can include a control unit configured, based at least in part on receiving a nullification instruction, to obtain an instruction identification for a memory access instruction of a plurality of memory access instructions and a register identification of at least one of a plurality of registers, based on a first and second target fields of the nullification instruction. The at least one register and the memory access instruction associated with the instruction identification are nullified. Based on the nullified memory access instruction, a subsequent memory access instruction is executed.

Control events may be signaled to a target system having a plurality of components coupled to a scan path by using the clock and data signals of the scan path. While the clock signal is held a high logic level, two or more edge transitions are detected on the data signal. The number of edge transitions on the data signal is counted while the clock signal is held at the high logic state. A control event is determined based on the counted number of edge transitions on the data signal after the clock signal transitions to the low logic state.