On Thursday 03 September 2009, Magnus Lundin wrote: > For the Omap353x we set the DSCR[DSCR_HALT_DBG_MODE] bit in the setup > script, and we then assume that the running application does not > actively play with the debug settings. > This can of course be discussed.
Cortex M3 does similar stuff but not in the init script; I see no reason not to just put this in the C code for both cores. A generic issue related to setting the halt mode debug flag (and similar debug hooks) is that if OpenOCD were to support debugging monitors for more than XScale -- which seems to require one! -- we'd need to change that and related things. I can't come up with a reason why debug settings would be changed that doesn't involve monitor mode (or equivalent). To recap: an alternative to halt mode debug is monitor mode, where debug traps are intercepted by target-resident code which handles them, and which communicates (using DCC or equivalent) with the external debugger. A compelling example of where that is needed seems to be motor control: the motor won't stop just because a breakpoint was hit, motor control activities need to continue. Maybe "debug just this task" applications fit too. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
