Regarding your comments about documenting stuff. At some point we're risk drowning the user in information that he can't possibly relate to. If the issues relate to the current state of OpenOCD w.r.t. a problem we'll be fixing in the code in the next 3-6 months, then perhaps it is better to document it as a known problem? If at all?
Perhaps the sort of issues that you talk about above belong in an extended "known problems" section? Ideally OpenOCD should just "work" selecting the right work area for you, or minimally your target script should have a sensible default. It is a known problem that there is no "right" value for size working area. > (C) FUTURE: > Maybe we even create a "-dcc-work-area" target option? > It would always be backed up and restored .. > And - it needs to be smart about GDB loading over the top of it. > > Maybe we create a "-flash-work-area" target option? > > Today - existing OpenOCD code treats "work area as work area" > generically. Why can't DCC downloads backup whether the configuration said to backup or not? It's only 24 bytes, what's the downside? The "backup" option to work area could be interpreted as "OpenOCD *may* optimize by *not* restoring memory after using it" > (D) On chips like ARM 9 - that have Vector Catch. > Vector Catch should be enabled during this period. > And "restored to previous state" when done. > Perhaps this should be on any time "run algorithm" is used. I seem to recall a JTAG debugger that stopped GDB on the instruction that caused the a memory fetch abort. Can we do this for OpenOCD? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
