Replies inside your text: On 12.3.2015 7:59, Paul Fertser (Code Review) wrote: > Paul Fertser has posted comments on this change. > > Change subject: target/adi_v5_swd, cortex_m: properly handle more cases > requiring reconnect > ...................................................................... > > > Patch Set 3: > > Tomas, let's try to separate all the issues here. > > 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)
> > 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). reset_config srst_only: reset run works ok when OpenOCD is in-sync. Unfortunately reset does not work after OpenOCD detected a failure (Illustrated in both logs ocd_reset_halt_psos.txt and ocd_reset_halt.txt) Actually OpenOCD fails before it asserts srst signal. 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. > > 3. You basically say that vector catch on reset makes no sense for this > target, as it can't meaningfully talk to the debugger after stopping in that > secure area. I think for cortex_m it means that "reset halt" can't be used at > all, ever, and that should be just a documented quirk. In this case you will > need to override gdb-erase-start handler from "reset init" to "reset; halt; > psoc4_init" for gdb "load" to work. You can also add an aux function to the > config that would set testmode, reset; halt; set pc, sp; a user that really > needs "reset halt" functionality then could use this ad-hoc reset. 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. > > 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)? Or use a jim tcl function in a configurable event - maybe too slow. > > 5. Is your current ocd_process_reset_init not good enough? It seems to cover > all the usecases nicely, should we bother at all? > If we eliminate the regression then there is no need to bother particularly with PSoC4. What really need to be improved is reset robustness at all. And I used PSoC4 peculiarities as a good test case. Nothing more. Tom ------------------------------------------------------------------------------ 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
