Akos Vandra wrote: > Flashing interfering with debugging is surely undesirable.
For starters I think it would be perfectly fine to add "new" flash operations which clobber all debugging state and do a full reset after completion. > I'm thinking we might be able to save the PLL state before the flash > operations, and restore them after. Maybe? I like the idea, but can we be sure that flashing will only affect the PLL and never anything else? Some targets use a flash loader, downloaded to the target by OpenOCD. We don't want to try to restore that state. I think it's fine for a start to just require reset after flashing. > Note however that in this case there is a problem that we > can't be sure of the main oscillator frequency. However that may be > supplied as a configuration parameter from the board file. I think it's important to avoid configuration as far as possible. Requiring reset after a (new) flashing command sounds fine to me if it means we can avoid all configuration. //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
