Hi,
After several soldering bugs removed, I finally get my crossconnect with Crossworks connecting properly with my custom LPC2368 board. However, when I try to download any code (to start debugging) I get the "Loader verify failed" message. I have to rewrite the reset script to this:

TargetInterface.setNSRST(0);
TargetInterface.message("Hello");
TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0xFFFFFFFF,0x00000000, 0xFFFFFFFF, 0x100,0xF7);
TargetInterface.setNSRST(1);
TargetInterface.message("Hello again");
TargetInterface.waitForDebugState(1000);
TargetInterface.trst();
TargetInterface.message("Try Now");

To get the connection working.
Forgetting about the silly messages in the script, is there anything I did wrong? I forgot any vital code to make the loader work? I'm using the Loader_lpc2368.elf with LIBMEM_RPC_Loader.
I cannot even erase the entire memory with the Right_mouse_click -> "Erase All" command. Don't you guys have also any "LPC programming and configuration for dummys" link?
I'll be forever thankfull for any insigt.

Start a New Thread

Hi,

> After several soldering bugs removed, I finally get my crossconnect
> with Crossworks connecting properly with my custom LPC2368 board.
> However, when I try to download any code (to start debugging) I get the
> "Loader verify failed" message. I have to rewrite the reset script to
> this:
>
> TargetInterface.setNSRST(0);
> TargetInterface.message("Hello");
> TargetInterface.setICEBreakerBreakpoint(0, 0x00000000,
> 0xFFFFFFFF,0x00000000, 0xFFFFFFFF, 0x100,0xF7);
> TargetInterface.setNSRST(1);
> TargetInterface.message("Hello again");
> TargetInterface.waitForDebugState(1000);
> TargetInterface.trst();
> TargetInterface.message("Try Now");
>
> To get the connection working.

Ok, I guess the important point here is that your board seems to take a long
time to get under control. I'm not sure that setting the ICEBreaker register
happens to do anything with the board (seemingly) in reset.

> Forgetting about the silly messages in the script, is there anything I
> did wrong? I forgot any vital code to make the loader work? I'm using
> the Loader_lpc2368.elf with LIBMEM_RPC_Loader.
> I cannot even erase the entire memory with the Right_mouse_click ->
> "Erase All" command. Don't you guys have also any "LPC programming and
> configuration for dummys" link?
> I'll be forever thankfull for any insigt.

Have you really reset your board? You're also not calling resetAndStop, so
I'm not sure things are going to be too stable.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Start a New Thread

Thanks Paul.
I've tested this:

TargetInterface.setNSRST(0);
TargetInterface.message("Hello");
TargetInterface.setICEBreakerBreakpoint(1, 0x00000000, 0xFFFFFFFF,0x00000000, 0xFFFFFFFF, 0x100,0xF7);
TargetInterface.setNSRST(1);
TargetInterface.message("Hello again");
TargetInterface.waitForDebugState(1000);
TargetInterface.trst();
TargetInterface.message("Resetting and stop...");
TargetInterface.resetAndStop(100);
TargetInterface.message("Try Now");

With and whithout the setIceBreaker line and i've used a Led in RSTOUT pin to see when processor resets. Every time I order the reset by CrossWorks, the led blinks.

Start a New Thread

Solved!!!!
My problem is that what you said, Paul. The wiggler don't stopping the device. However, every time that I connect to the LPC and my device type gets filled, also my debug interface type reverts to ARM7DI. Then, reading the help from Rowley (http://ccgi.rowley.co.uk/support/faq.php?do=article&articleid4) I go step by step of the topics.
-The JTAG Connection is at minimum cable size, checked.
-Incorrect support package, checked. Downloaded ok, status acquired fine.
-Reset signals, checked. Led at RSTOUT blink when reset command.
-Invalid code? I'm not trying to use any codes, only mass erase, checked.

Then I try to connect the wiggler and change the Debug Interface type to ARM7TDI.

That's when the gold flows...

Code download and verification just went smoothly. I think that can be a minor glitch in CrossWorks identifying an ARM7TDI as ARM7DI, even when I select the correct package whithin the project properties.

Anyway, thanks Paul for the insight.

Start a New Thread