On Monday 09 November 2009, Thomas Kindler wrote: > David Brownell wrote: > >> Even "reset halt" will let the CPU run for some amount of time > >> (e.g. enough to print a Hello-World string to the serial port..). > > > > Now *that* is a bug. And one that I suspect is specific to STM32, or > > at least to your particular chip, since I've not observed it on my > > tiny sample of Stellaris chips. > > > > What happens if you tell OpenOCD not to use SRST? The Cortex-M3 can > > reset using NVIC, without SRST. It has two NVIC resets ... see > > cortex_m3_assert_reset(). > > Well.. the whole reset stuff seems like black magic to me anyways. The > documentation says that there's a gazillion of possible ways to reset: > > 4 signals: none, trst_only, srst_only, trst_and_srst > 4 combinations: seperate, combined, srst_pulls_trst, trst_pulls_srst > 2 gates: srst_gates_jtag, srst_nogate > 2 TRST type: trst_push_pull, trst_open_drain > 2 SRST type: srst_push_pull, srst_open_drain > > makes 128 different combinations, not counting the various _width and > _delay tuneables. Are all of them useful? And tested?
If there's no SRST, then none of the SRST-related settings matter. Likewise with TRST. The timings are orthogonal, much like the color of the sky over your head right now. So there really aren't as many options as you suspect... I don't have any reason to think those don't function as defined. Except maybe the "trst pulls srst" option, which ISTR was coded more or less on speculation. > Back to your question: I tried all of the four signal options, and > /basically/ all of them work. I can attach log files if needed. > > "none" and "trst_only" seem to be the best options -- only one reset, > or reset-and-immediate-halt, as expected. Said differently: STM32 can use the current Cortex-M3 NVIC reset logic with no problems. Good to know. (Most of the Stellaris parts don't have a TRST signal. You might double check to see if your board even uses it. If not, "none" is your best answer. It's the OpenOCD default, too.) > "srst_only" and "trst_and_srst" give double-resets and run-before-halts. Pretty much like some of the Stellaris parts. The issue there is that SRST is resetting some of the debug logic, but that's supposed to be left untouched ... according to ARM. You might want to consult ST, or the STM32 docs (and errata) to see if this is viewed as an erratum or just a variance from how ARM says things should work. A stop-on-reset flag gets set before SRST, then SRST fires; and it runs because that stop-on-reset flag (vector catch) got unexpectedly cleared. > But "trst_and_srst" is defined as the default in stm32.cfg .. perhaps > it's just the wrong reset type?! The stm32.cfg shouldn't specify a reset type at all, since the right configuration depends on what the *board* wires up. Send a patch in ... :) There are a handful of targets that can't be debugged without both SRST and TRST; those are the only ones with any business providing such a config option in a target config file. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
