Clock & PLL config verification in tool?

[lpcware]

Content originally posted in LPCWare by cwpjr on Sat Jun 15 12:27:38 MST 2013
Is there a way to verify clock and PLL speed and input selection in the debug session?

I'm changing clock stuff and the only notion of the tool noticing is during debug download; the assumed clock at flash download programming changes.

The peripheral views do reflect my clock / pll init values.

The reason I ask is that my changes should make things faster yet they seem slower!

[lpcware]

Content originally posted in LPCWare by cwpjr on Sun Jun 16 15:56:37 MST 2013
Ok Thanks.

I got my board (no external xtal) to run the uart demo by setting pll clock to irc and mainclock to pll in the #defines in the system_LPC11xx.h file...
#define SYSPLLCLKSEL_Val      0    // 0x00000001
#define SYSPLL_SETUP          1
#define SYSPLLCTRL_Val        0x00000023
#define MAINCLKSEL_Val        0x00000003

FYI, this also works on the NXP demo board.

However, now, my app downloads and *runs* but
I get to open a new thread because of strange behaviour.... :confused:

[lpcware]

Content originally posted in LPCWare by R2D2 on Sat Jun 15 17:30:04 MST 2013

---

Quote: cwpjr
Requires external tools, like a frequency counter or a scope.

---

Yes, and so it's independent. Reading back you setup just can confirm that your setup is used. A simple error (like wrong crystal frequency) and you don't get the expected result.
CLKOUT can check your frequency within minutes :)

[lpcware]

Content originally posted in LPCWare by cwpjr on Sat Jun 15 16:55:52 MST 2013
R2D2   What's wrong with CLKOUT?

Requires external tools, like a frequency counter or a scope.

Whats wrong with asking if the info is derivable within the tool?

[lpcware]

Content originally posted in LPCWare by R2D2 on Sat Jun 15 12:46:35 MST 2013
What's wrong with CLKOUT?