Forums

Trouble writing to flash on LPC2468

Started by benknnnn February 10, 2011
Heya,

We've been having issues writing to the flash of an LPC2468 using JTAG, the issue being is that we simply can't write when using JTAG.

By using the default boot loader, we are able to download our .hex file to the device using Flash Magic, and the program will run fine. Interestingly, we can also attach the debugger (CrossStudio) to the device and follow the execution after using Flash Magic to program it. The JTAG port can also read the contents of the flash. I have checked to make sure that CRP is disabled.

So far we are unsure where the problem lies, and have tried replacing the LPC2468 on one of our boards with a previous batch of the same processor that we know to have worked. We have been using the CrossConnect for ARM Lite and Olimex ARM-USB-OCD JTAG connectors.

Here are the schematics of the board, with respect to the JTAG connection.

http://i56.tinypic.com/i77xjc.png
http://i52.tinypic.com/33mvm01.png

Any help is very much appreciated.
Ben.

An Engineer's Guide to the LPC2100 Series

benknnnn wrote:
> We've been having issues writing to the flash of an LPC2468 using JTAG,
> the issue being is that we simply can't write when using JTAG.

Can't connect with JTAG or data is written wrong or can't write at all?

If the written data is bad, you may have told the IAP wrong clock speed. Note
that, if you have old code already programmed into the FLASH, it may run for
some time before JTAG manages to halt it and may manage to change the clock
speed - depending on your code, of course.

If you can't connect with JTAG at all, you may have wrong JTAG clock speed.
Maximum is 4MHz/6 as long as the core runs from IRC.

If JTAG works but you still can't write at all, then I dunno.

--

Timo

----Original Message----
From: l...
[mailto:l...] On Behalf Of benknnnn
Sent: 11 February 2011 00:23 To: l...
Subject: [lpc2000] Trouble writing to flash on LPC2468

> Heya,
>
> We've been having issues writing to the flash of an
> LPC2468 using JTAG, the issue being is that we simply
> can't write when using JTAG.
Are you using crossworks to program - if so what is it saying to you?

--
Tim Mitchell

An update on the problem: We have successfully written to the flash from JTAG when using our recently-replaced Eclipse IDE on the same board that we are having troubles with using CrossWorks.

> Are you using crossworks to program - if so what is it saying to you?

Yeah this problem occurs only when using CrossWorks. It attempts to download and then verify the LIBMEM loader, but fails to verify that the loader is on there. If we disable using the loader, it will write the program, and say the download has completed, but the verify will once again fail.

I believe this is covered in our FAQs.

You have defined STARTUP_FROM_RESET, so need to read about what that means
in the FAQs.

What you can do is simply have a small delay in your startup code that
allows the JTAG adapter some time to gain control of the CPU without the
target running user-level code, changing PLLs, setting up DMAs, setting up
peripherals (and anything else it might do, like start the watchdog...)

-- Paul.

> -----Original Message-----
> From: l... [mailto:l...] On Behalf
Of
> benknnnn
> Sent: 11 February 2011 14:44
> To: l...
> Subject: [lpc2000] Re: Trouble writing to flash on LPC2468
>
> An update on the problem: We have successfully written to the flash from
> JTAG when using our recently-replaced Eclipse IDE on the same board that
we
> are having troubles with using CrossWorks.
>
> > Are you using crossworks to program - if so what is it saying to you?
>
> Yeah this problem occurs only when using CrossWorks. It attempts to
download
> and then verify the LIBMEM loader, but fails to verify that the loader is
on
> there. If we disable using the loader, it will write the program, and say
> the download has completed, but the verify will once again fail.

--- In l..., "Paul Curtis" wrote:
>
> I believe this is covered in our FAQs.
>
> You have defined STARTUP_FROM_RESET, so need to read about what that means
> in the FAQs.
>
> What you can do is simply have a small delay in your startup code that
> allows the JTAG adapter some time to gain control of the CPU without the
> target running user-level code, changing PLLs, setting up DMAs, setting up
> peripherals (and anything else it might do, like start the watchdog...)
>
> -- Paul.
>
Hi again,

If the problem is because of STARTUP_FROM_RESET being defined, then would undefining fix the problem? The first time we attempted to download to the target was without STARTUP_FROM_RESET being defined, and this is when we discovered that writing using the JTAG was not working.

In any case, I have removed STARTUP_FROM_RESET from the pre-processor definitions and downloaded the image using Flash Magic, observation of the LEDs provides insight that the code is not running from reset, and attaching the debugger shows it is branching infinitely in reset_wait. However, we are still unable to then download to the target using JTAG, the same message appears, "LIBMEM RPC loader has not initialized correctly". Additionally we have tried higher and lower JTAG clock dividers. Also, regarding your comments on user code configuring the PLL etc, we have removed these configurations (PLL, MAM, Watch dog, we haven't implemented DMA) to no success.

We have tried this firmware build on a previous revision of the board we are currently using and it downloads via JTAG fine on CrossWorks. However we are unsure what to make of this (whether or not it is hardware related), owing to the fact we can download via JTAG using our Eclipse IDE (with OpenOCD).

Thanks again,
Ben.

Hi,

> If the problem is because of STARTUP_FROM_RESET being defined, then
> would undefining fix the problem? The first time we attempted to
> download to the target was without STARTUP_FROM_RESET being defined,
> and this is when we discovered that writing using the JTAG was not
> working.

One assumes you've looked at why this could be a problem in our FAQs? Are
you using adaptive clocking? Did you wire the JTAG port correctly?

> In any case, I have removed STARTUP_FROM_RESET from the pre-processor
> definitions and downloaded the image using Flash Magic, observation of
> the LEDs provides insight that the code is not running from reset, and
> attaching the debugger shows it is branching infinitely in reset_wait.

Ok.

> However, we are still unable to then download to the target using JTAG,
> the same message appears, "LIBMEM RPC loader has not initialized
> correctly". Additionally we have tried higher and lower JTAG clock
> dividers. Also, regarding your comments on user code configuring the
> PLL etc, we have removed these configurations (PLL, MAM, Watch dog, we
> haven't implemented DMA) to no success.
>
> We have tried this firmware build on a previous revision of the board
> we are currently using and it downloads via JTAG fine on CrossWorks.
> However we are unsure what to make of this (whether or not it is
> hardware related), owing to the fact we can download via JTAG using our
> Eclipse IDE (with OpenOCD).

Did you use adaptive clocking? All LPC2000s are synthesized parts and will
require adaptive clocking or a clock divider to divide TCK so that it's
1/6th the core frequency.

-- Paul.

--- In l..., "Paul Curtis" wrote:

> One assumes you've looked at why this could be a problem in our FAQs? Are
> you using adaptive clocking? Did you wire the JTAG port correctly?
>

> Did you use adaptive clocking? All LPC2000s are synthesized parts and will
> require adaptive clocking or a clock divider to divide TCK so that it's
> 1/6th the core frequency.
>
> -- Paul.
>

Hi again,

We have tried playing around with the target properties, using adaptive clocking on Auto, On and Off with both our adapters (CrossConnect for ARM and Olimex ARM-USB-OCD) but without any success.

We believe our JTAG port is wired correctly, as we have used the same wiring before. The schematics for the wiring are as shown:

http://i56.tinypic.com/i77xjc.png
http://i52.tinypic.com/33mvm01.png

Additionally, I previously forgot to include the schematic of the adapter we use in between the CrossConnect/Olimex and the Microprocessor:

http://i52.tinypic.com/2r5td86.png

Thanks again,
Ben.

Final update, for sake of completion. The problem was solved by setting the Loader Parameter to 0. (In Project Properties -> Target Loader Options -> Loader Parameter)
With thanks to Rowley for their support.

Ben.