On Wed, Jan 15, 2014 at 4:30 PM, Ram Bhamidipaty <[email protected]> wrote:

>
>
>>> The overrun appears to happen after I call resume.
>>>
>>
>>
>> So what does the code you're resuming do? It's expected for the debugger
>> to
>> lose debug connectivity if the code puts the core into sleep mode. Or
>> disable JTAG pins for that matter. Try stepping instead of resuming and
>> see
>> how far you get.
>>
>>
> Turns out the problem is that the ARM code changes it's clock frequency.
>
> In my case - the ARM code needs to change the clock to some high speed. But
> when it comes out of reset the chip will be running at some low speed. What
> is the best way to handle this?
>

If the code increases the clock frequency it shouldn't be a problem. If
OpenOCD can talk to the chip out of reset, it should be able to do so after
the code has boosted the clock.

So is the issue that the initial clock frequency is too low for OpenOCD?
Then you should be able to debug with adapter_khz <some_low_value>, albeit
slowly.


> The openocd manual suggests using a reset handler or other tcl code to
> change
> the clock. But in my case I need ARM code to do that.
>

Why can't it be done in Tcl?


>
> Is there some other way?
>

A common setup is to set adapter_khz to a low value initially and also in
the reset-start handler. That ensures that you can get control of the
target at start and during a reset.

Since the frequency needed may be too low to load code efficiently, a
reset-init handler may be defined to set up PLLs etc and then increase
adapter_khz. Then, if you do a reset init before loading, you'll get better
performance.

Afterwards you should do a reset halt to load the new SP and PC. That will
not run the reset-init handler so the clock is left at the reset
configuration. If you know that the code you're starting increases the core
clock, you should be able to boost adapter_khz after resuming, maybe with a
little sleep in between.


> The manual does mention using adaptive clocking - for ARM devices is
> this the main solution?


I don't think it's common for Cortex-M devices to support RCLK but yes,
that would be a solution.

/Andreas
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to