> > Said differently: STM32 can use the current Cortex-M3 NVIC reset > > logic with no problems. Good to know. > > Nice!
Agreed. :) > At least the "high-density device limitations" for my STM32F103VE > deosn't seem to list any reset problems: > > http://www.st.com/stonline/products/literature/es/14732.pdf They might not view it as a problem; or, since it's limited to debug support, which most vendors do in collaboration with tool vendors that embed workarounds in their products, maybe it just never got generally documented. Marketing teams have this annoying habit of pressuring engineers to have *short* buglists. That was one of the things that sucked hardest about Intel's early XScale chips ... you needed to get their early buglists and *SAVE THEM* since many bugs never really got fixed, they just got dropped from later official lists. So if you were using "current" buglists, you kept having to rediscover old bugs ... and come up with workarounds. :( > >> 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 ... :) > > I'll try to do some more testing (flashing, gdb, etc.) tomorrow and send > in a patch if everything works. Thanks. > > 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. > > Hmm, 49 of 77 target files specify a reset type ;) The first one I saw was "reset config none", which is rather strongly on the pointless side of things. ;) Not all of those specify how SRST or TRST are wired. I spoke a bit too broadly ... "gates" options also belong with target configs if they're non-standard, as do most "srst pulls trst" options, when they reflect chip issues not board wiring. There's still a lot of ... goofy/wrong code floating around. Especially related to reset configuration and handling. I'm *very* glad that most of the Cortex-M3 parts in the tree seem to act OK when SRST is not used. That's a much cleaner model for development. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
