An operation method of a nonvolatile memory device includes receiving control signals and a data signal from external of the nonvolatile memory device, generating debugging information based on the control signals and the data signal, receiving a debugging information request from external of the nonvolatile memory device, and outputting the debugging information in response to the debugging information request.

A method for managing a product includes: placing an integrated circuit in a bootstrap mode with debugging prohibition in response to each reset or power-up of the integrated circuit and in an absence of a reception, on a test access port of the product, of a first command; and placing the integrated circuit in an analysis mode with debugging authorization in response to reception, on the test access port, of the first command following the reset or the power-up of the integrated circuit. Placing the integrated circuit in the analysis mode is maintained at least as long as a second command has not been received on the test access port. Placing the integrated circuit in the bootstrap mode and placing the integrated circuit in the analysis mode are performed in response to a determination that the integrated circuit has never before been placed in the analysis mode with debugging authorization.

A semiconductor device, for example an integrated circuit such as a microcontroller (MCU) or a digital signal processor (DSP), includes a semiconductor die coupled with a power supply line, a debug module coupled with the semiconductor die to exchange semiconductor die debug command and data signals with the semiconductor die, and a modem coupled with the power supply line. The debug module is arranged to convey the semiconductor die debug command and data signals over the power supply line.

Systems, devices, and techniques relating to remote debugging are described. A described device includes a first processor core configured to provide an application execution environment, memory coupled with the first processor core; a second processor core configured to provide a secure execution environment; and a communication interface coupled with the first processor core and the second processor core, the communication interface being configured to communicate with external devices, the communication interface being shared at least between the application execution environment and the secure execution environment. The second processor core can be configured to monitor the application execution environment of the first processor core, determine whether to allow a debug session with an external device, via the communication interface, based on credentials received from the external device, and provide, via the debug session, read and write access to the memory and one or more registers of the first processor core.

Provided are a multichip debugging method and a multichip system adopting the same. The multichip system includes: a first chip including a first debugging port and first identification (ID) information, a second chip including a second debugging port and second ID information, and a test access port (TAP) electrically connected to the first debugging port and the second debugging port and configured to connect to a test apparatus via the TAP.

In some aspects, a method for managing leakage power includes coupling a first supply rail to a cache memory if a processor is in a first performance mode, wherein the processor accesses the cache memory, and coupling a second supply rail to the cache memory if the processor is in a second performance mode. The method also includes detecting gating of a clock signal to the cache memory or the processor, and, upon detecting gating of the clock signal, switching the cache memory from the second supply rail to the first supply rail if the cache memory is currently coupled to the second supply rail.

Various embodiments are generally directed to an apparatus, method and other techniques to receive debug trace information via one or more pins, generate a packet comprising the debug trace information and a header, the header comprising header information to send the packet to a device coupled via one or more network connections, determine a location in a data buffer of an interface controller for the packet, and write the packet to the data buffer of the interface controller at the location.

An approach for debugging a circuit implementation of a software specification includes translating a high-level language debugging command into a hardware debugging command that specifies the value(s) of a condition in the circuit implementation, and a storage element(s) at which the value(s) of the condition is stored. The hardware debugging command is transmitted to a debug controller circuit that generates a single clock pulse to the circuit implementation. The debug controller circuit reads a value(s) from the storage element(s) specified by the hardware debugging command and determines whether or not the value(s) satisfies the condition. The debug controller circuit generates another single clock pulse in response to the value(s) read from the storage element(s) not satisfying the condition. Generation of pulses of the clock signal is suspended and data indicative of a breakpoint is output in response to the value(s) read from the storage element(s) satisfying the condition.

In general, trace and debug logic should not be affected by all functional or destructive resets of a processing system. However, certain events, such as power supply related events may be utilized to reset the trace and debug logic since the trace and debug logic may cease correct operation if the provided power supply is insufficient. In addition, it may be beneficial for a debugger to initiate requests to reset trace and debug logic. Further, fault triggers from critical path monitors may be candidates as a source of reset for the trace and debug circuitry. For example, when critical path monitors trigger a fault, the fault may be from the logic associated with either trace and debug logic or the logic which is being debugged or traced. As such, in some instances both trace and debug circuitry and the processing system may be inoperable and may need to be reset.

A real-time debugger implementation maintains and manages multiple debug contexts allowing developers to interact with real-time applications without breaking the system in which the debug application is executing. The debugger allows multiple debug contexts to exist and allows break points in real-time and non-real-time code portions of one or more applications executing on a debug enabled core of a processor. A debug monitor function may be implemented as a hardware logic module on the same integrated circuit as the processor. Higher priority interrupt service requests may be serviced while otherwise maintaining a context for the debug session (e.g., stopped at a developer defined breakpoint). Accordingly, the application developer executing the debugger may not have to be concerned with processing occurring on the processor that may be unrelated to the current debug session.