ICEPick cold reset

Hi,

There is only one Reset available that is triggered by the on-chip emulation logic (aka System Reset), and I am trying to get a confirmation to which one was implemented in the particular case of DM814x family of devices.

BTW, is there anything specific that you observed to figure out that the CCS menu option triggers the emulation warm reset?

As a general rule, from the CCS reset menu one may see the following resets:

• Software Reset: The reset is done entirely by running code such as setting the PC to a specific location and initializing registers to known values.  It does not reset peripherals or even the entire device.
• Hardware Reset: A hardware signal is used to reset the CPU.  It does not reset peripherals or the entire device, just the CPU for which it is triggered. Generally a more complete reset than a software reset.
• System Reset: This is the ICEPick controlled reset. It is equivalent to pulling a power on reset to all CPUs in the device.  It should reset everything in the device except the debug logic.
• Board Reset: This pulls the SRST pin on the debug probe header.  This is a power on reset for the entire board and does reset the debug logic. Only implemented on a few CPUs, and not available on TI 14 pin header.

The System Reset (ICEPick) could be called cold or warm depending on context. It is a cold reset for everything inside the device, but you might call it a warm reset because it doesn’t reset the debug logic.

CPU Reset is sometimes a software reset or a hardware reset depending on what’s available on the target.

Hope this helps,

Rafael

desouza said:

There is only one Reset available that is triggered by the on-chip emulation logic (aka System Reset)

The documentation suggests otherwise, since it explicitly lists "Emulation Cold Reset" and "Emulation Warm Reset". Some data from table 2-36 "Reset sources":

desouza said:

BTW, is there anything specific that you observed to figure out that the CCS menu option triggers the emulation warm reset?

While the table claims every reset other than TRSTz also resets PLLs, dividers, and power state for each IP, my experience is otherwise.  The difference between warm and cold reset is very easy to notice. For example, if you make a mistake reconfiguring the PLL of the main processor then you get a lockup which is not cleared by "System reset" in CCS, nor asserting the RESETz pin, nor (most disturbingly) by the watchdog reset. Only a PORz works (or manually fixing the PLL settings via JTAG). Also, the PWRCTRL register for one of the power domains has the bizarre property that any write to it (regardless of value) forces it on, warm reset insensitive. Many control registers are also insensitive to warm resets.

(The documentation actually also contradicts itself: e.g. section 2.7.16 "RESETz sequence" (page 478) mentions "Chip clocks are not affected as both PLL and dividers are intact.")

Matthijs van Duin said:

Only a PORz works (or manually fixing the PLL settings via JTAG)

Forgot to add: triggering a software cold reset by writing to the PRCM register via JTAG fixes the problem too of course, but as the table above correctly shows this also resets emu logic so you're instantly greeted with something like

SEVERE: DAP: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect.

or some other error (invariably with an equally wrong diagnosis).

Hi,

Matthijs van Duin said:

The documentation suggests otherwise,

The TRM mentions all types of resets available on the device, but the Emu cold reset is not exposed in CCS, nor anywhere else. Therefore, I confirm that Emu warm reset is the only one that is available for use by you (which matches your findings).

The details about each reset and its properties are not defined at the software but instead at the device level, therefore I am unable to provide any additional insights with this regard. As a user of several of these devices, I can also tell that PORz is usually the safest to bring back a device/core from such disruptive scenarios (bad PLL config, for example).

Regards,

Rafael

desouza said:

The TRM mentions all types of resets available on the device, but the Emu cold reset is not exposed in CCS, nor anywhere else. 

So although this mechanism exists, and presumably resides in ICEPick (considering it is also called "ICEPick POR") and is therefore only accessible via JTAG, it is not available in TI's own software for JTAG-debugging of their own processors, "nor anywhere else" ?  You can probably imagine this sounds like a rather strange statement, but ok.

desouza said:

I can also tell that PORz is usually the safest to bring back a device/core from such disruptive scenarios

Well obviously PORz will bring back a device from anything (well, almost), it's a bit disturbing though that a watchdog reset doesn't, considering the sole purpose of a watchdog is to reset a device into a working state again if it becomes unresponsive.  Oh well, the power management IC also has a watchdog feature, I guess it's time to take a closer look at that...