As for the configuration with main_fclk, i was referring to the next use case:
All my application startup, crank up the PLL to the desired value, and pretty much leave it there. And I guess all applications that are not consumption sensitive kinda do the same thing. We might be able to "adaptively clock" the debug speed like this: 0. set adapter_khz to a small value, like 100kHz 1. reset target 2. wait a few ms 3. read out the pll values 4 if pll is not connected go to 2 5. read out pll values, determine cpu clock speed <-- this is where main_fclk might be needed if we are running from there. 6. divide it by 7 (just to make sure it's gonna work), and use it as adaptor_khz Regards, Ákos Vandra On 22 May 2012 12:35, Akos Vandra <[email protected]> wrote: > On 22 May 2012 12:28, Peter Stuge <[email protected]> wrote: >> 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. > > That's true, and kindof makes the rest of my letter invalid. Just need > to move the PLL code to a new procedure. > A full reset is necessary of course, as it doesn't really have any > meaning to "continue" the new code. > > Regards, > Ákos ------------------------------------------------------------------------------ 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
