freddie_chopin wrote: > > I would suggest to merge these patches asap, they boost the flashing > > speed, and debugging responsiveness tremendously! > > But how are you going to use it for anything more than flashing?
I think Akos was refering to the ftdi driver, but you make an excellent point about the PLL while debugging. Indeed flashing is a very different operation from debugging and they can not be mixed at will. OpenOCD should ideally track current state so closely that it will always know what is going on and perhaps will mess with the target PLL automatically, only on flash commands? I believe the common case is to write flash and then reset halt, to debug the flashed firmware. This is nice and structured, and I think for this case it's fine for OpenOCD to crank up clocks for flashing. Rather than changing this for current commands I might favor adding a new command (or option, or subcommand) for flashing, which first sets up PLLs where possible, then does the flash operating, and then does a reset. > in my code - there are functions to start PLL again, which needs > them to be disabled Yes, it's important that when the target executes code it will see documented reset state for the chip. Do you see a way for this requirement to not conflict with the desire for OpenOCD to use as high speed as possible for debug communication? //Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
