On 12/07/2010 05:16 PM, Freddie Chopin wrote:
On 2010-12-04 15:47, Freddie Chopin wrote:
This is directly related to the findings from this post:
https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html
I've only removed srst_pulls_trst and comments that mentioned that (and
comments that were not very helpful)
So what's wrong with this patch that I've tested on LPC2103 and it
works better than before?
The problem is that in fact LPC2000 targets need the srst_pulls_trst option.
Your claim is: "The srst_pulls_trst option doesn't apply to LPC2000
devices, and therefore must be removed from the target scripts."
And this is your argument: "I can show that I'm able to stop the CPU
before it executes the first instruction of my code."
I want to show that your argument is invalid.
The srst_pulls_trst option must be applied to targets that reset the TAP
controller when the system reset is applied. LPC2000 (except
LPC28xx/29xx) is such a target. While RESET input is active, you cannot
access the TAP controller.
As a consequence it is not possible to keep the device in reset state,
set a breakpoint at 0, release reset, and have the CPU stop at 0 before
it executes the first instruction. For LPC2000 you must release the
reset in order to get access to the TAP controller. As getting access
takes quite a few JTAG clock cycles, the CPU will inevitably execute code.
Now this is perhaps what causes some confusion: It's not the user
firmware that gets executed after reset, it's *always* the primary boot
code!
Without looking in detail at what you've done, I admit that it is indeed
possible to stop an LPC2000 before it executes the user firmware.
However, it is not possible to stop the CPU before it executes *any*
code. Boot code always starts running.
srst_pull_trst must remain in the LPC2000 target configurations.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
