JTAG debugging: peripherals do not stop

Started by "lit...@rocketmail.com" August 9, 2010
Hi all,

I am debugging a program on an LPC2148 using OpenOCD/JTAG/GDB. Setting hardware breakpoints work fine, GDB stops the program flow, BUT my timers continue to run!

How do I configure the JTAG or GDB to also stop the peripherals? It's really annoying because when I continue the program, the timers need about 90 secs to wrap around until the next match event is generated.
I must do something fundamentally wrong, how can the peripherals continue as the CPU has already stopped?

Thanks for some helpful suggestions,

cheers Patric

An Engineer's Guide to the LPC2100 Series

Peripherals can still run, even though your CPU can be idle. I don't think you can stop the timers - without shutting them off. Or, I should say I don't know of a way.

Sutton

--- In l..., "littlezaphod@..." wrote:
>
> Hi all,
>
> I am debugging a program on an LPC2148 using OpenOCD/JTAG/GDB. Setting hardware breakpoints work fine, GDB stops the program flow, BUT my timers continue to run!
>
> How do I configure the JTAG or GDB to also stop the peripherals? It's really annoying because when I continue the program, the timers need about 90 secs to wrap around until the next match event is generated.
> I must do something fundamentally wrong, how can the peripherals continue as the CPU has already stopped?
>
> Thanks for some helpful suggestions,
>
> cheers Patric
>

Hi

> How do I configure the JTAG or GDB to also stop the peripherals? It's really annoying because when I continue the program, the timers need about 90 secs to wrap around until the next match event is generated.

It has nothing to do with the JTAG. It is a SoC thing. If NXP does not
foresee stopping peripherals when you enter debug-mode, you are pretty off.

But if you use GDB, you might modify it, to stop the peripherals as soon
as you hit a breakpoint (direkt in source or with scripting).

--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Ah, this is annoying. I havent done JTAG debugging yet but I wondered
about this.
Does anybody know how do the peripherals behave on the LPC17xx

Regards,
Alejandro
Hi

When peripherals are configured there are sometimes bits that control their behavior under certain conditions (like when the debugger hits a break point, when the CPU sleeps, etc.). If there is no such bit in the peripheral in question (or possibly in a peripheral clock register) it will continue to run.

The LPC17XX have the same peripherals as the LPC23XX and these don't have such controls (as far as I remember).

A simulator can often be of better use for debugging time-critical code (HW timers, protocols with timeouts etc.) since it can freeze all peripherals and external signal stimulus when stepping code, making things possible which are unrealistic on real targets.

See also the uTasker project for LPC2XXX and LPC17XX since this contains a real-time simulator which can greatly improve development efficiency.

Regards

Mark
http://www.uTasker.com

--- In l..., Alejandro Celery wrote:
>
> Ah, this is annoying. I havent done JTAG debugging yet but I wondered
> about this.
> Does anybody know how do the peripherals behave on the LPC17xx
>
> Regards,
> Alejandro
>