Did I brick my 1768 Xpresso board?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dbrunell on Fri Sep 03 13:53:59 MST 2010
I have an application where I need to run the CPU clock at 104 MHz in order to get the correct ADC timing. I know that the 1768 is rated at 100 MHz, and I will have to use the 1769 in production, but I was hoping to stretch the 1768 a little for prototyping purposes. I inserted the following code at the beginning of my program to adjust the CPU clock frequency:

int main(void) {
    
    LPC_SC->PLL0CFG = 0x0005004E;
    LPC_SC->PLL0FEED = 0xAA;
    LPC_SC->PLL0FEED = 0x55;

    LPC_SC->CCLKCFG = 2;    // Change divisor to 3
...

I first tested the first three lines, prior to the CCLKCFG assignment, and it worked as expected (M=78, N=6, Fcco=312 MHz, CCLK=78 MHz). Then I added the line to change the CCLK divisor from 4 to 3 (value to assign is n-1), and the board stopped responding to the debugger. I get the following error now when I try to debug:

02: Failed on connect: Em(12). System rejected access at location 0xE000EDF0 
  - verify Population of memory and peripherals

Is there a way to recover from this?

I think there should be better documentation on how best to change the clock frequency. I can't find any source code examples for the LPCXpresso environment. I didn't want to modify system_LPC17xx.c, since changing part the CMSIS library seems like bad programming form.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Sep 28 02:36:56 MST 2010
As you are having problems with a purchased product, I suggest you contact our support group directly.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nacrisp on Tue Sep 28 02:29:02 MST 2010
Thanks for your quick reply...

Neither of those seem to work, I instantly get a pop-up saying:
O2: Failed on connect: Ee(02). Not connected to emulator.

Any other things I can try ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Sep 28 02:03:28 MST 2010
Hi,

It sounds like the target application that is running is preventing debug access. If the target has got into this state, the debugger can do some extra things to grab control of the target, that the Drag2Flash cannot.

I suggest that the best way forward is to:
- get the board into ISP mode
- from within LPCXpresso, erase the flash (use the Program Flash button in the toolbar)
- if this doesn't work, again, get the board into ISP mode, and use the debugger to program one of the RDB example applications.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nacrisp on Tue Sep 28 01:17:30 MST 2010
I have an application running on the dev board. It's running fine because it's chattering away on the UART0 and debug LEDs are flashing away, but I can no longer use drag2flash, debug, or mass-erase etc. Essentially I cant connect, with the following error: (jpeg attached)

O2: Failed on connect: Ee(02). Not connected to emulator.
Emu(0): Connected. Was: None. DpID: EDB6. Info RDBV20001

I can drag2flash etc on a colleagues dev board, so is it possible that some settings in my app have affected the serial wire debug?

I have powered up the dev board with the ISP switch depressed and this seems to stop my app running, but it starts up again when I try a drag2flash operation - when I hit switch SW4. - LED1 flashes faster as it should, but LEDS 2-5 are running as per my application.

regards,
Nick

lpcware · ‎06-15-2016

Content originally posted in LPCWare by woodchuck on Tue Sep 07 15:05:16 MST 2010

Quote: dbrunell
These are really fantastic parts, and NXP deserves kudos for pricing the development system within reach of everyone!

I couldn't agree more with this sentiment! But who is to thank? NXP, Embedded Artists, or Code_Red?

My wife's answer to such a question would be, "YES."

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dbrunell on Sat Sep 04 00:10:56 MST 2010
Thank you! Vector catch didn't work, but booting into ISP did the trick. Now it won't be a long, boring weekend without a development platform to work on. ;) These are really fantastic parts, and NXP deserves kudos for pricing the development system within reach of everyone (and for adding Linux support!).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Sep 03 23:44:18 MST 2010
It sounds like the settings you applied to the PLL/clock has destablized the part. This code is now resident in flash, it executes whenever you apply power to the board. You can approach this problem in two ways. First, set the vector catch option in your LPCXpresso project debug configuration to 'true':

Debug Configurations... -> Project -> Debugger (tab) -> Vector catch (Target configuration)

The LPCXpresso debug will attempt to catch the part out of reset. If this fails, you'll need to boot into the ISP. That is, GND P2.10, and assert RST. Once in the ISP, the target clock configuration is stable, and you should be able to connect. The first thing you'll want to do is restore the previous clock setting so whatever you leave in flash doesn't destablize the part again.

With regards to modifying the CMSIS code, there is nothing to stop you doing this. You just need to be aware that if you change the code in the library project, this will effect any other projects in the same workspace. Thus you might either want to do these changes in a copy of the CMSIS library in a separate "test" workspace, or else copy the CMSIS code from the library project into your actual test application project.

You might also want to make use of the "LPC17xx PLL Parameter Calculator" available from:

http://ics.nxp.com/support/documents/microcontrollers/?search=lpc17&Search.x=0&Search.y=0

Regards,
CodeRedSupport