On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
<andreas.fritiof...@gmail.com> wrote:
> On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin <freddie_cho...@op.pl> wrote:
>> Hi!
>>
>> I've doubts about this commit
>> http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5
>> Today I've noticed that resetting the chip with OpenOCD does NOT reset
>> peripheals (the chip is STM32F103RBT8), which IMO is not very good...
>>
>> Do you think this patch should be reverted? Are there any important reasons
>> to not have "reset_config" in stm32.cfg as in many other target cfg files?
>>
>
> I don't think this specific patch is the problem. I've run with
> 'reset_config none' for a long time without any trouble. Before this
> patch there were a bunch of reset issues. Please don't revert it.
> Besides, having reset signals wired is optional and a board/adapter
> level decision, and should not be specified in the target file.
>
> If the peripherals are not getting reset I suspect some other patch
> has sneaked in that changed the "soft reset" behavior from a real
> reset to a core only reset. Perhaps to fix issues with other Cortex-M3
> implementations. I haven't run HEAD for a while, but if I find some
> time I'll try to confirm and locate the problem.

Without having tested it, commit 3c69eee9 seems to be the problem.
While it's good that the reset type is now configurable, changing the
default behavior wasn't perhaps the best idea. It would have been
better to keep SYSRESETREQ as the default and change it in the configs
for cores that haven't wired it up to the "master reset".

Regards,
Andreas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to