On Sat, May 03, 2014 at 09:17:02AM -0700, Duane Ellis wrote: > On May 3, 2014, at 8:42 AM, Paul Fertser <[email protected]> wrote: > > You wouldn't try to set a breakpoint on a dead/crashed system, or > > would you? > > *YES* - but that might happen later (continuing the example above) > *maybe the PC stopped inside of memset(), I might need to step out a > *few times …. and single step may require breakpoints. But - maybe > *some of the system clocks are off and you cannot probe all > *locations. > > It’s messy, very messy and ugly - there is no simple solution here.
Hardware (FPB) breakpoints work everywhere but there're few of them, I understand. So you say you'd like to be able to tell exactly when you can place a software breakpoint and when you have to resort to FPB, and for that you're proposing to introduce additional config file command to specify all the RAM sections (actually not all but only those that we can directly modify via DAP), do I understand it right? So how about this simple solution: if the address is in target working-area, use sw breakpoint, otherwise hw? I understand that's not exactly what you want but is it a good enough approximation? BTW, most OpenOCD upstream configs for microcontrollers specify the whole SRAM region as working area. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
