On Monday 11 January 2010, Edgar Grimberg wrote: > I'm doing target tests according to a test plan. I want to test the > basic functionality of OpenOCD:
Test Plan? That sounds ... pleasantly organized!! :) > * Connectivity: telnet, GDB > * Reset, using the provided configuration scripts, on targets with > blank flash: reset init, reset halt > * JTAG speed: MHz values and return clock > * debugging: load into RAM, software breakpoint, single step in RAM, > hardware breakpoint, single step in ROM > * RAM access: writing simple patterns to RAM and reading back > * FLASH: probe, fill, erase, program using GDB load > > The list is open and I welcome any additions.. Looks like a good basic plan, though it doesn't cover fault paths and negative testing. An ARM9 example would be triggering each exception vector and making sure the "arm9 vector_catch" mechanism handles it properly -- covering the cases where the vector is caught by OpenOCD, as well as ones where it isn't. The issues there being whether or not OpenOCD handles things correctly when it should handle them, and likewise ignores them when it shouldn't. As you surely know, bugs in fault handling code paths are relatively common... Also for ARM9 (and ARM7): semihosting. That's had almost no attention so far. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
