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.
Trouble writing to flash on LPC2468
Started by ●February 10, 2011
Reply by ●February 11, 20112011-02-11
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
> 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
Reply by ●February 11, 20112011-02-11
----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
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
Reply by ●February 11, 20112011-02-11
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.
> 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.
Reply by ●February 11, 20112011-02-11
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.
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.
Reply by ●February 13, 20112011-02-13
--- 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.
>
> 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.
Reply by ●February 14, 20112011-02-14
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.
> 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.
Reply by ●February 14, 20112011-02-14
--- 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.
> 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.
Reply by ●April 4, 20112011-04-04
