On Wednesday 16 September 2009, Øyvind Harboe wrote: > > > > A change that could be useful is adding a way to see that config > > data in TCL. Maybe just having the no-params "reset_config" call > > return the currently-applicable strings. (Not display; return, > > so TCL scripts can use those values.) > > What I'd like to see is reset_config split into two: > > - one tcl proc that implements the reset_config scheme to manipulate > the existing state(reset_config as-is)
You mean re-package the state and replace the command code (written in C) with a Tcl proc? Otherwise I don't see why anything should need to change... > - a low end function(in C) that just sets the flags passed in, ignoring > any previous history. Why #2? One "x = y;" assignment suffices ... I don't follow. I'm still collecting issues with the reset code. One will be coming up with the Beagle support, I think ... how to trigger resets without SRST (which isn't available on that JTAG connector). I think the preferred solution would be to find out more of the ICEpick commands; some of them can reset the ARM (or DSP as relevant) cores. But those docs may not be very available to us. A second-tier solution would be having a way to intercept the "$TARGET arp_reset [assert|deassert] $HALT" logic and kick in a watchdog reset. My first inclination is to have such stuff written in TCL... _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
