Freddie Chopin wrote: >>> How common is what? Lack of SRST? >> >> Yes? > > For me such situations are almost impossible,
Impossible? Weird measure of common. :) > but some strange and bizarre policy makes default target file for > stm32 tell OpenOCD there is no reset at all... My perception of the situation is strongly the opposite. There is no policy, relax, there is just people working together making something generic that works. This is a difficult task. > Number of things that users of OpenOCD have to do prior to using it > for it's main purpose tends to grow, rather than shrink... Maybe things need to get a little worse before they can get a lot better. I think we're still learning about cm3. > Completely off-topic: sometimes I think, that open-source projects > are just a cover-up made by people working for big companies Sorry, this is a bit silly. I can understand that open source projects are immensely frustrating if there is some kind of incompatibility, be it attitude or philosophy or even trivial stuff like coding style. And the fact that projects to a high degree are based on voluntary contributions means that it can be basically impossible to get something done the way you like unless you do it yourself. I am not complaining that *you* do not contribute here, I mean this completely generally. I also completely understand that not everyone can do the changes themselves, but it's also important to remember that those who selflessly do want to contribute code changes that will help others have very limited resources, so it might take time. Using the program is also very important, I belive that testing and bug reports is the only way to make significant progress.. And documentation, and training for others, and so on.. Just remember that this is really just piece of sh*t software that we are hacking on to make it do a decent job. It is still good enough to sell products based on, and sometimes it's many many times better than proprietary products, but it is still not that amazing. Very little software is. Fixing that is of course a huge task, but we all want to make things better and try to help as best we can. >>> If SRST is available, no soft-reset is required. >> >> Of course. What decides on the code path? > > I don't understand the question, Sorry, it was unclear. I meant to ask how openocd knows to use SRTS or soft-reset and if soft-reset then how it knows to use SYSRESETREQ or VECTRESET. I guess it's all target and board config files. > so here is a blind answer... > 1. no chip resets, no cortex-m3 reset method specified - use > SYSRESETREQ (now use VECTRESET - does not reset peripherals) > 2. chip reset available, cortex-m3 reset method specified - use > cortex-m3 reset method that was specified What cm3 reset method would that be, for example? C code in OpenOCD? > 3. chip resets available, no cortex-m3 reset method specified - use SRST Ok. > 4. no chip resets, cortex-m3 reset method specified - use it, but > if cortex-m3 reset method is SRST that will be changed to > SYSRESETREQ (now it will be changed to VECTRESET, note as in 1.) Uh? So the cm3 reset method is not in C, but can be set to SRST? Freddie Chopin wrote: > On 2010-11-11 20:47, Spencer Oliver wrote: >> I disagree with this patch as SYSTEMRESET is not supported as >> expected on all cores. > > Shouldn't the code assume that this standard mechanism works as the > standard says? If some chip does not support it, than this chip > should have VECTRESET selected in its config file, why make trouble > for chips that obey this standard? I think this makes sense. If SYSRESETREQ is the standard and it is more complete then that should be the default, and those who don't support it can spec a degraded reset functionality if that's the best that can be done. >> I still believe the best way is for each core to state that it >> supports SYSTEMRESET over VECTRESET in the cfg file. I guess this is what I was asking about - how common are the two? Maybe it makes the most sense to always require explicit reset configuration in the config files. > LPC2xxx supposedly cannot be reset into halted mode (because SRST > pulls TRST) Please *stop* adding to this misconception! I've had to patch both lpc2148.cfg and lpc1768.cfg because someone apparently did not read the chip PDFs before making or changing the config files. It's nonsense. The whole issue is really simple IMO; each "level" of config file (cm3 vs. lpc1768, arm7 vs. lpc2148, etc) should reflect the accurate settings for that level, and more specific files can override more generic ones as neccessary. It's totally possible that there is no applicable default for cm3 in general, then we just don't spec anything on that level, and we make sure to add a check into openocd so that it screams at the user if no reset config has been made, when cm3 is used. //Peter _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
