Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
Freddie Chopin wrote: I will violently oppose any attempt to add the option back to config files for 2148 and 1768. Expect all sorts of bits and bytes thrown at you. Right now we need to violently demand this patch to be committed ; I'm hoping to hear test results from Rolf soon, as long as he does not discover any problem I think the patch should be committed. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-09 10:07, Peter Stuge wrote: I'm hoping to hear test results from Rolf soon, as long as he does not discover any problem I think the patch should be committed. I'm afraid they are hoping that we get bored with waiting for any reply or decision, and that this good idea will die. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On Thu, Dec 9, 2010 at 5:02 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-12-09 10:07, Peter Stuge wrote: I'm hoping to hear test results from Rolf soon, as long as he does not discover any problem I think the patch should be committed. I'm afraid they are hoping that we get bored with waiting for any reply or decision, and that this good idea will die. I don't know who they are, but I assure you someone is watching you(plural) ;-) -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 12/09/2010 08:33 PM, Freddie Chopin wrote: On 2010-12-09 20:05, Rolf Meeser wrote: --- Freddie Chopinfreddie_cho...@op.pl schrieb am Do, 9.12.2010: Von: Freddie Chopinfreddie_cho...@op.pl Betreff: Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts An: openocd-development@lists.berlios.de Datum: Donnerstag, 9. Dezember, 2010 17:02 Uhr On 2010-12-09 10:07, Peter Stuge wrote: I'm hoping to hear test results from Rolf soon, as long as he does not discover any problem I think the patch should be committed. I'm afraid they are hoping that we get bored with waiting for any reply or decision, and that this good idea will die. Hi Freddie, Don't look for a conspiracy everwhere... Let me say that I fully support your change request now. I have done some investigation on this, and found that this configuration works reliably on all devices, including the very first generation. I also discovered that the big commercial players use this method in the meantime. It was different before! I want to say thank you for pushing this hard enough to get our attention :-) Rolf You probably forgot to CC the list - this message is addressed only to me. Or maybe that was the plan, and you're writing another message for the list... 4\/3!! Conspiracy-seeker (; Freddie ;-) (I pressed Reply instead of Reply to all. It was my last action before I left the office in a big hurry for my train...) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
Rolf Meeser wrote: Let me say that I fully support your change request now. I have done some investigation on this, and found that this configuration works reliably on all devices, including the very first generation. Great. Thanks for confirming this on more devices than I could! Acked-by: Peter Stuge pe...@stuge.se ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-06 00:35, Rolf Meeser wrote: Copy protection of LPC controllers relies on the fact that it is not possible to halt the processor right after reset. If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. The copy protection still works fine - as soon as it's enabled JTAG access is impossible and no reset_config options can change this. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-08 06:57, Peter Stuge wrote: Freddie Chopin wrote: I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. Thanks. U'r welcome [; I will violently oppose any attempt to add the option back to config files for 2148 and 1768. Expect all sorts of bits and bytes thrown at you. It has wasted enough of my life time already thank you very much. Right now we need to violently demand this patch to be committed ; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
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
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. On 2010-12-07 20:45, Rolf Meeser wrote: 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. If what you say is true, than why I was able to halt the chip after reset at address 0 with MEMMAP still selecting bootloader? Don't you think that bootloader code would change MEMMAP value after it's executed? After normal reset (after which the chip is running) and halting the chip some time later at address 0 I see my code, MEMMAP is changed (not by me) to 1. When I do reset halt (when reset_config is separate), at address 0 I can see the code of the bootloader, MEMMAP value is 0. Here a simple experiment that shows that you're wrong. reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. mdw 0xe01fc040 0xe01fc040: arm disassemble 0 16 0x 0xe59f201c LDR r2, [r15, #0x1c] 0x0004 0xe3a03000 MOV r3, #0x0 0x0008 0xe1020093 SWP r0, r3, [r2] 0x000c 0xe2822028 ADD r2, r2, #0x28 0x0010 0xe1021093 SWP r1, r3, [r2] 0x0014 0xe3c03007 BIC r3, r0, #0x7 0x0018 0xe5023028 STR r3, [r2, #-0x28] 0x001c 0xe51ff004 LDR r15, [r15, #-0x4] 0x0020 0x7fffe178 SVC 0xffe178 0x0024 0xe002c014 AND r12, r2, r4, LSL r0 0x0028 0xe01fc000 ANDS r12, r15, r0 0x002c 0x ANDEQ r0, r0, r0 0x0030 0x ANDEQ r0, r0, r0 0x0034 0x ANDEQ r0, r0, r0 0x0038 0x ANDEQ r0, r0, r0 0x003c 0x ANDEQ r0, r0, r0 bp 0 4 hw breakpoint set at 0x resume target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x60d3 pc: 0x mdw 0xe01fc040 0xe01fc040: 0001 arm disassemble 0 16 0x 0xe59f00a4 LDR r0, [r15, #0xa4] 0x0004 0xe580 STR r0, [r0] 0x0008 0xea04 B 0x0020 0x000c 0xe1a0 NOP 0x0010 0xe1a0 NOP 0x0014 0xc460ff58 STRGTBT r15, [r0], #-0xf58 0x0018 0xe1a0 NOP 0x001c 0xe1a0 NOP 0x0020 0xe59fd088 LDR r13, [r15, #0x88] 0x0024 0xe321f0d1 MSR CPSR_c, 0x00d1 0x0028 0xe59fd084 LDR r13, [r15, #0x84] 0x002c 0xe321f0d2 MSR CPSR_c, 0x00d2 0x0030 0xe59fd080 LDR r13, [r15, #0x80] 0x0034 0xe321f0d7 MSR CPSR_c, 0x00d7 0x0038 0xe59fd07c LDR r13, [r15, #0x7c] 0x003c 0xe321f0db MSR CPSR_c, 0x00db As you see I can halt the code at 0, MEMMAP is 0 (bootloader), at address 0 I see bootloader code. I set the breakpoint at 0, resume, the breakpoint is hit, MEMMAP is 1 (flash), at address 0 I see my code. Tell me where I'm wrong, but try to show an example that proves your point, because my LPC2103 clearly behaves differently than you'd expect it to. You say this option is required, I say it's not, the experiments show reliable debugging etc. so where's the problem?
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 12/07/2010 09:40 PM, Freddie Chopin wrote: reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain I tested the srst_gates_jtag instead of the srst_pull_trst option on the only LPC2000 board that I have here available at home. It works fine on this board despite its weird external reset hardware. I'll check that again with different hardware tomorrow. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
Hi, Freddie Chopin wrote: I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. Thanks. I have had significant development issues both with LPC2148 and LPC1768 having reset_config srst_pulls_trst in their target files. It was impossible to control either microcontroller with srst_pulls_trst set. In case of 2148 it was a matter of my code generating an exception before OpenOCD could take control. Since the pins were independent on chip and JTAG connector I tried removing srst_pulls_trst and that immediately allowed me to reliably control the CPU. I was quite annoyed at whomever had set this option. It took me a while to discover the first time. Especially as it was my first project using OpenOCD. I only patched these two target configs as I encountered the issue on each of them, specifically because I thought that maybe this was something that had been true for earlier LPC2000 and had been extrapolated to all of the configs. Since Freddie needs it also for 2103 I guess it's plain wrong, and only some really badly designed boards need it. (Agree, we need that capability infrastructure.) You say this option is required, I say it's not, the experiments show reliable debugging etc. so where's the problem? I will violently oppose any attempt to add the option back to config files for 2148 and 1768. Expect all sorts of bits and bytes thrown at you. It has wasted enough of my life time already thank you very much. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 12/05/2010 11:00 PM, Freddie Chopin wrote: So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? Are you sure this is correct? Copy protection of LPC controllers relies on the fact that it is not possible to halt the processor right after reset. If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
--- On Sun, 12/5/10, Freddie Chopin freddie_cho...@op.pl wrote: So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? Which ones are useless? Which are wrong? And for the latter , why haven't we seen specific bug reports, followed by trivial patches? The first sane example of that option which I ever herd was for some LPC chip where it was described as a silicon work-around (and thus it made sense to be in a target file). I think everyone agrees that when board wiring calls for that option, it belongs in a board config file rather than elsewhere. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On Mon, Dec 6, 2010 at 12:35 AM, Rolf Meeser rolfm_...@yahoo.de wrote: On 12/05/2010 11:00 PM, Freddie Chopin wrote: So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. Here in Poland, 2010 is the Chopin's year hahah! They knew the right person to select! Congratulations Freddie! :D -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
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)
4\/3!!
From 74e3b52516be9211fa6ea6a89853ac7a3a1fa478 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 4 Dec 2010 15:45:40 +0100
Subject: [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
LPC2xxx do not require reset_config srst_pulls_trst. This can cause various
strange problems when flashing the chip, because reset halt actually allows
the chip to run for some short period of time and execute some code.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2103.cfg |3 +--
tcl/target/lpc2124.cfg |3 +--
tcl/target/lpc2129.cfg |3 +--
tcl/target/lpc2294.cfg |3 +--
tcl/target/lpc2378.cfg |3 +--
tcl/target/lpc2478.cfg |3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/tcl/target/lpc2103.cfg b/tcl/target/lpc2103.cfg
index 714267f..7f14555 100644
--- a/tcl/target/lpc2103.cfg
+++ b/tcl/target/lpc2103.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2124.cfg b/tcl/target/lpc2124.cfg
index c511589..df71bdd 100644
--- a/tcl/target/lpc2124.cfg
+++ b/tcl/target/lpc2124.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2129.cfg b/tcl/target/lpc2129.cfg
index 103f18e..2587bf7 100644
--- a/tcl/target/lpc2129.cfg
+++ b/tcl/target/lpc2129.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0xcf1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2294.cfg b/tcl/target/lpc2294.cfg
index 6f34171..ecf0599 100644
--- a/tcl/target/lpc2294.cfg
+++ b/tcl/target/lpc2294.cfg
@@ -14,8 +14,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2378.cfg b/tcl/target/lpc2378.cfg
index 65b554c..21fdd1b 100644
--- a/tcl/target/lpc2378.cfg
+++ b/tcl/target/lpc2378.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index df46c10..99c8ce9 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 100
jtag_ntrst_delay 100
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On Sat, Dec 4, 2010 at 10:47 PM, Freddie Chopin freddie_cho...@op.pl 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) Fred, I think the right place to define reset_config should be in files in board directory, not in target. The same target device could be present on many boards, with different circuit of JTAG connector. - We could have no connection for TRST signal (it is optional and in this case the TAP reset is obtained pulling down two signals together, don't remember which). - We could have no SRST (very common case, unfortunately) - We could have boards where SRST and TRST are connected together (I never found one, but...) Best Regards, Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
