Clock problems during debug

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Nov 20 13:58:53 MST 2014
Hello engineers,

We trying to debug/program a lpc1114/333 but there is something wrong and we are out of ideas. We use the simple led blinky example. When programming the chip with SWD everything seams to be ok even after verifying. When we start the debug session in LPCXpresso the status change in running but the debug led is not blinking. When pauze the debugging we can't step through the program. when switching the power off and on the led starts to blink.

-The bootloader pin is high

We use the internal oscillator

---------system_LPC11xx.c------------

#define CLOCK_SETUP           1
#define SYSCLK_SETUP          1
#define SYSOSC_SETUP          1
#define SYSOSCCTRL_Val        0x00000000
#define WDTOSC_SETUP          0
#define WDTOSCCTRL_Val        0x000000A0
#define SYSPLLCLKSEL_Val      0x00000001
#define SYSPLL_SETUP          1
#define SYSPLLCTRL_Val        0x00000023
#define MAINCLKSEL_Val        0x00000000
#define SYSAHBCLKDIV_Val      0x00000001
#define AHBCLKCTRL_Val        0x0001005F
#define SSP0CLKDIV_Val        0x00000001
#define UARTCLKDIV_Val        0x00000001
#define SSP1CLKDIV_Val        0x00000001

[lpcware]

Content originally posted in LPCWare by justmakeit on Mon Jan 26 14:41:53 MST 2015

---

Quote: TheFallGuy
You don't need any plugins. Just  configure it as described here
https://www.segger.com/nxp-lpcxpresso.html

---

For existing projects with other ICs (LPC1766 and LPC 1857) we already used the setup mentioned above (from Segger) without problems.
Only when we tried using it with the LPC1114 as decribed in the first post we ran into problems during debug.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Sat Jan 24 08:03:48 MST 2015
You don't need any plugins. Just  configure it as described here
https://www.segger.com/nxp-lpcxpresso.html

[lpcware]

Content originally posted in LPCWare by 1234567890 on Sat Jan 24 05:33:43 MST 2015
Unfortunately J-Link isn't supported (yet) by LPCXpresso IDE, e.g. look at http://www.lpcware.com/content/forum/lpcxpresso-segger-j-link
Don't try GNU ARM Eclipse SEGGER J-Link debugger plug-in because it doesn't work in this case and can have sideeffects.

You can also have a look at https://www.segger.com/nxp-lpcxpresso.html

[lpcware]

Content originally posted in LPCWare by justmakeit on Sat Jan 24 03:00:51 MST 2015
Just tried the LPC-Link 2 programmer instead of the J Link EDU we where using until now.
Surprisingly everything works imediatly! After programming the debug sessions starts directly and we are able to step through our code.

Not sure what the differences are between interfacing both programmers.
The J Link EDU is connected through a GDB server
The LPC-Link 2 is connected directly to LPC Xpresso with the RedLink Server.

We still woul like to be able to program with the J Link debugger but are not sure were to look, software seems OK, probably a debug configuration or hardware connection?

[lpcware]

Content originally posted in LPCWare by justmakeit on Wed Jan 21 13:46:07 MST 2015
Hi,

Thanks for the reply.
Unfortunately in our debug configuration (GDB hardware debugging) this option is not available.

[lpcware]

Content originally posted in LPCWare by nerd herd on Wed Jan 14 09:06:28 MST 2015
Hi justmakeit,

Just a blind suggestion, but can you go into your debug launch configuration and see if "vector catch" is set to true? If it is not, can you set it to true and see if there is any change in behavior? Also, try putting the board into ISP mode before each debug session.

[lpcware]

Content originally posted in LPCWare by justmakeit on Sun Jan 11 03:58:07 MST 2015
Could our problem be caused by the j-link programmer configuration, where the reset procedure after programming goes wrong?
Not sure how this process works but because repowering the board seems to work after programming en trying to debug.

Any suggestions?

[lpcware]

Content originally posted in LPCWare by justmakeit on Sat Dec 13 07:49:15 MST 2014
The ISP pin has already a pullup resistor.

I just managed to step through the startupfile and during the main function the debugging stopped working at the function "GPIOSetDir( 1, 4, 1 );"
When I add a function call before this function the problem still occurs at this same function call "GPIOSetDir( 1, 4, 1 );"

When I remove this function "GPIOSetDir( 1, 4, 1 );" the debugging stops at the next functioncall "GPIOSetDir( 2, 3, 1 );"

Not sure what can go wrong with this functions?

Without debugging (disconnect en connect the power after the debugging session freezes) the program seems to run OK.

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Dec 11 16:00:05 MST 2014

---

Quote: TheFallGuy
have you checked your circuit for ISP? It needs to be tied high or low - sorry, I cant remember which... There are several posts on this topic in these forums, probably worth a look.

---

:D  :D

E.g. #16 or #17 of this thread...

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Thu Dec 11 15:46:58 MST 2014
If you don't hit a breakpoint, that implies that it is not starting at all. The 0x1fff..... Address is in the on chip ROM. this makes me wonder if you have a problem with ISP. have you checked your circuit for ISP? It needs to be tied high or low - sorry, I cant remember which... There are several posts on this topic in these forums, probably worth a look.

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Dec 11 14:20:25 MST 2014
Thanks for the fast reply.

We use the J-link EDU from segger with its GDB server.
The breakpoints set in the startupfile have no effect, when starting the debug session the program runs without stopping. only when we pause the debug session we get the result posted earlier.

The J-link programmer works with the same configuration for LPC1766 and LPC1857 in other projects.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Thu Dec 11 14:03:43 MST 2014
Which debug probe are you using?

Looks like your code has taken an exception during startup code (0xfffffff9 is the stack marker for an exception handler). Suggest you set the initial breakpoint on ResetISR. And single step to find out what is causing the exception.

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Dec 11 13:51:37 MST 2014
We just soldered a second PCB, this time with an external 12MHz crystal attached.
We started with a fresh Blinky project and didn't change a single line of code.

Unfortunately the same problems occur:
Programming seems to go ok but again when the debugging starts a SIGTRAP message occurs and the CHIP doens't do anything.
Measuring at both the CLK pins shows a flat line.

After powering off and on of the supply power we measure a clean 12MHz on the clock pins.

Any suggestions?

See attached images for our debug config and the SIGTRAP message.

[lpcware]

Content originally posted in LPCWare by justmakeit on Sat Nov 29 06:13:51 MST 2014
The 10K at PIO0_1 we already added afterwards, we can increase the 2K2 of the reset pin.

The 10K required at the ISP pin we learned the hard way in a previous project after days of searching :P

Thanks for all the feedback, we start to get a good idea of the problems.

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Nov 27 15:57:50 MST 2014

---

Quote: justmakeit
True, before we start searching to a difference between schematic and board, is our schematic for use with SWD debugging ok?

---

SWO isn't necessary...

I'm using a simple SWD connection with GND / SWCLK / SWDIO / Reset without problems...

I'm not sure if you are using a Link or Link2...

Your SWD connection is correct, but I would recommend to use 10k pull-ups at PIO0_1 (ISP) and Reset.

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Nov 27 15:40:54 MST 2014
True, before we start searching to a difference between schematic and board, is our schematic for use with SWD debugging ok?

Is for example the SWO pin needed for debugging?

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Nov 27 15:21:50 MST 2014

---

Quote: justmakeit
We just found out that programming is not the issue...

---

So it's a hardware problem and time to check your schematic / board...

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Nov 27 15:17:23 MST 2014
We just found out that programming is not the issue, after programming and starting debug, the debug freezes.
When we disconnect the power and programmer and connect this again the Blinky program starts and the LEDs light up.

each change in out program works after stopping debug and reconnecting the power and programmer to the IC.

we now know the code is correct but don't understand why the debuging is freezing the IC.

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Nov 27 14:34:39 MST 2014

---

Quote: justmakeit
When we start debugging in LPC Expresso the program holds and shows SIGTRAP.

---

:quest:

Then use Single Step to line 106... There's your problem starting...

To avoid problem you should comment out CLKOUT setting and all timers.

Try to run a very simple program, just toggling Pins...

[lpcware]

Content originally posted in LPCWare by justmakeit on Thu Nov 27 13:54:49 MST 2014
We have the CMSISv2p00_LPC11xx project added as reference to the Blinky project and added both to the workspace so we don't have to copy the system_LPC11xx.c to the Blinky project if I'm right.

we changed the configuration a bit:

- disabled SYSOSC_SETUP because we only want to use IRC clock
- MAINCLKSEL is still the IRC clock

we have a 2K2 connected between P0_1 and VCC to prevent the IC from going into bootloader mode.
P0_1 is also configured as CLKCOUT for the IRC clock but we only measure a constant 3V3 at this pin.

When we start debugging in LPC Expresso the program holds and shows SIGTRAP.

See attached picture.