On Thu, Mar 12, 2015 at 10:58:59AM +0100, Tomas Vanek wrote:
> >1. Does this patch introduce a regression in current psoc4 support or not?
>
> Unfortunately yes.
> arp_waitstate fails in the state "need-to-be-reconnected" (log
> ocd_reset_halt_psos.txt)

I'll try to digest that. Do I understand it right that it's with
hardware srst and 2596 applied? It's very strange because 2596
shouldn't affect reset when srst is used. If only it worked by chance
and fixes in 2596 exposed another bug.

> >2. Does sysresetreq (without SRST configured) work for 2a. "reset" 2b. 
> >"reset halt"? Does SRST "reset" work (afaict, yes)?
> reset_config none: reset run/halt w/o srst works ok (as before).

So 2596 doesn't regress sysresetreq case for psoc4, ok.

> Actually OpenOCD fails before it asserts srst signal.

During "arp examine" from the tcl reset_inner_proc? But you're using a
custom proc anyway, you do not need to try examine before
resetting. In fact, I can not see a solid reason anyone would want a
reexamination right before reset for any target, probably it can help
in some edge cases, but failure to "arp examine" shouldn't stop reset
from proceeding, I agree with that.

> I mean reset run with srst should be so robust as it can act in any state.
> Decide yourself if this is reason for a new change or not.

Agreed.

> There is alternate way to halt PSoC4 before it starts executing
> code. I integrated it to redefined ocd_process_reset_init.  It
> worked well before this change. I do not understand why do you
> propose a workaround executing code after reset when a better
> workaround exists.

Just for the sake of a discussion, in case we might come with a better
solution (which is unlikely in this case, no doubt here).

> >4. Is this the example of a target that would benefit from 
> >ahbap_debugport_init on hardware reset deassertion?
> Probably yes. On the other hand I doubt about using it for every target.
> Why not to do reinit just when srst_pulls_trst flag is set (or introduce a
> new flag)?

I was proposing exactly that, do that debugport_init after deassertion
only if srst is available and srst pulls trst (this flag sounds
appropriate enough).

> What really need to be improved is reset robustness at all. And I used PSoC4
> peculiarities as a good test case. Nothing more.

I understand, and I was asking you to review my reset patches exactly
because of that :)

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[email protected]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to