Can't step through PLL setup code

Development Boards MicroMod
1

GDB is unable to keep stepping through instructions when I feed changes into the PLLCON register.

My setup is GDB → OpenOCD → USB-JTAG → LPC2378-STK

I am executing the code from Flash.

lpc2378_init:   LDR     R0, =PLLFEED
                MOV     R1, #0xAA
                MOV     R2, #0x55

                @ 1. Disconnect PLL (if connected) and feed
                LDR     R3, =PLLSTAT
                LDR     R4, [R3]
                TST     R4, #(1 << 25)          @ PLLSTAT:25 set means connected
                BNE     pll_disable             @ If already disconnected, skip

                LDR     R6, =PLLCON
                MOV     R5, #(1 << 1)           @ Prep value for PLLCON (bit 1 set means connect)
                TST     R4, #(1 << 24)          @ Check PLLSTAT:24 to see if PLL is already enabled
                ORREQ   R5, R5, #1              @ Prep value for PLLCON (enabled bit)
                STRB    R5, [R6]                @ Update PLLCON
                STRB    R1, [R0]                @ PLLFEED <- 0xAA
=>              STRB    R2, [R0]                @ PLLFEED <- 0x55

While stepping through that last line of code, OpenOCD issues an error message:

Error:  timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0

Then GDB seems to stay stuck on that line of code, but in fact the processor is no longer halted:

(gdb)
(gdb)
(gdb)
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0

Program received signal SIGINT, Interrupt.
lpc2378_init () at hwinit.s:86
(gdb) monitor poll
target state: running
(gdb)

After this happens, I am no longer able to halt the processor using OpenOCD.

> halt
timed out while waiting for target halted
Runtime error, file "command.c", line 436:

I have tried setting a breakpoint after the PLL setup code (no stepping through this time), and the breakpoint simply doesn’t work; also I cannot halt the processor using OpenOCD (same message as above).

I would be very grateful if you have any idea what’s going on here and/or how to get around it.

2

My initial thought - if the clocking of the device is occuring at the previous (non-PLL clock speed) and the JTAG interface is not adaptive, once the CPU connects to the PLL and starts running at, say ~ 58MHz instead of the “raw” clock freq1uency of 14.7456MHz, the JTAG clock synch with your debugging device may be lost.

Try NOT single stepping through it all, but just checking the PLLSTAT register afterward (set breakpoint there) to see if the PLL is running and connected to the CPU - if it shows as connected, don’t worry about it and keep on coding.

My $.02

3

Yes, ftsolutions, it’s possible that the JTAG is losing communication due to clock speed differences.

But I cannot set a breakpoint after the PLL code. If I set one before and one after, the JTAG connection seems to be lost while passing through the PLL code (even if I don’t step through it). So it won’t stop at the breakpoint afterwards.

If I set a breakpoint only after the PLL code, it also doesn’t work. OpenOCD gives me error messages during initialization, complaining about JTAG communication failure.

4

Unfortunately I don’t have this problem when using IAR and the Segger J-Link, though it would sometimes lose the connection while single stepping through and hitting the instruction where the PLL is then connected to the CPU cluck and suddenly the CPU clock speed is changed - but hitting a breakpoint afterwards is no problem for me with this setup.

When I Was using a very simple parallel port (Wiggler) device it was more problematic. Since I am not using OpenOCD I cannot offer you any other help that is likely to be of use in this, sorry.