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
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
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
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) Change target script for LPC2478
On 12/04/2010 10:31 AM, Freddie Chopin wrote: On 2010-12-04 00:32, Rolf Meeser wrote: This is a misconception. When OpenOCD tries to take control after a reset, the CPU is already running. ISP mode or existing user firmware may or may not have changed the clock tree. Like it or not, but there is no a priori knowledge of CPU clock. When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. With LPC23xx you are in the same situation as with older LPC2000 which required an external crystal. The operating frequency is *not* a target parameter, it is a board/application parameter. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. Are you blaming me for not having changed all the other lpc2xxx.cfg files yet? I promise I *will* change them all. They *must* be changed. See below. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! That's the whole point of OpenOCD's layered config file approach. Do you refuse to work with an LPC2138 device just because its target config file cannot include a clock frequency? There is no way to avoid a board file here. And at the risk of repeating myself, the situation for LPC23xx is the same. I've stated on multiple occasions that for me this whole policy is wrong. As for the second paragraph, you are wrong. All LPC2xxx target config files have that frequency embedded without possibility to change with some parameters in board config files and - somehow - people manage to use it without problems. And I like those files very much, because they work standalone, so in my favorite way. For me this policy is right. I'm willing to state this on as many occasions as required. Look at the ever so perfect standalone configs: lpc2148.cfg: The clock frequency is hard-coded as 14.756 MHz. Nobody will ever use this device with a 14.756 MHz crystal. Nobody. Never. Now assuming a realistic crystal of 12 MHz, the gentle user will use the device outside spec. With a 24 MHz crystal he might still be able to program the flash and verify correctly. Unfortunately he will have field returns, because the devices will certainly start failing after six months or so. This has already happened. lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not getting it. We're talking about a three-liner: 1. your interface, 2. your clock frequency, 3. your target. That's clearly a no-brainer! I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. You don't do it now? Then you're failing *miserably*. Having embedded frequencies in the target files is plain wrong. It *DOESN'T* work. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) New board config for Embedded Artists LPC2478-32
On 12/04/2010 10:02 AM, Øyvind Harboe wrote: also that name is very long compared to other names. I care about that because I have names in a dropdownlist on ZY1000 :-) Feel free to change embedded-artists into ea! Not every company name can be as compact as Zylin :-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 12/04/2010 12:35 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: For me this policy is right. I'm willing to state this on as many occasions as required. Speaking about this right/wrong policy - it's said that reset_config does not belong to target config files, yet you haven't changed that, but left these wrong command there... How come? Don't start trolling. I know you can do better. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Definitely my last post on this thread. On 12/04/2010 12:33 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. One last time. OpenOCD cannot halt an LPC2000 immediately after reset. It must let the CPU run, then try to gain control over the CPU as fast as possible. How fast it can do that depends on the JTAG clock and on delay settings. By the time OpenOCD has taken control, the CPU may have entered ISP mode (it does that if the flash contains no user firmware). In that case the clock will be 14.748 MHz, and not 4 MHz anymore. If there is valid user firmware, this firmware may have set the PLL to any value you like, leaving you with an unknown clock frequency. This process is not under your control. The only possible conclusion is that you cannot have knowledge of the CPU frequency even after reset halt. As a side note: This is the reason why PLL initialization of an LPC2000 device should first disconnect and disable the PLL before it configures/starts/connects it again. If the device runs standalone, this step is unnecessary (the PLL is off after reset). However, if you debug the application via JTAG, things are different: Your JTAG box may not be able to stop the CPU before the firmware starts the PLL. The debugger will then just set the program counter to 0, so that it *appears* to be the reset state. But it isn't. Running PLL initialization again on the now already connected PLL will let your system crash. That's a fact which you should accept. Not only because I do indeed work for NXP. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. You say there is none, I say there is. There's no way we can agree. If you follow the arguments above about clock frequency uncertainty, then with all due respect you cannot but agree :-) lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? Obviously this device cannot be used with 14.765 crystal because LPC2148 also cannot (see your paragraph above) - I don't know why is that, but if you say so... I haven't said so. I said that nobody will do it. The LPC2148 will only be used by people who want USB. That requires a 12 MHz crystal, 14.756 MHz will not work. Besides the general nonsense of default frequencies in all these files, I took this as an outstanding example of a config file that will fit *ZERO* real world applications. Changing these 5 numbers is pretty straightforward and people do that (as OpenOCD works for them). I do. And are you saying that programming flash with wrong speed causes it to fail LATER? Again - do you have some secret knowledge from NXP that general public doesn't? You do not want to write a 3-line board file to describe your application, but you do accept having to modify predefined files, with the risk that they get overwritten next time you update OpenOCD? Are you teasing me? This is not the place to teach you about flash technology. Just a simple reminder: Flash is an analog component. Not applying a proper programming pulse will leave a cell charged at only say 30%. Every flash cell loses charge over time, but while the correctly handled cell keeps its charge for 20 years, the incorrectly handled cell may already fail after a few months. Yes, this must be plain wrong, and you must be plain right, as the world is black and white. Ease of use does not matter, the most important thing is to be ultra-correct with everything. Do you actually care about the users, or maybe you're affiliated with Keil or IAR and your goal is to make using OpenOCD harder? Let me quote Sergeant Hartman: What is your major malfunction? Really - your change does nothing more than make OpenOCD harder to use, as everyone could change that frequency before that (and they did, as people were using OpenOCD successfully with those chips for a long time), but to do that no additional file was required. Again (and again) - default (whatever they may or may not be) values with warning for ALL LPC config files are GOOD. Adding board files with such default value is exactly the same as leaving default value inside target files. You
[Openocd-development] (patch) Fix sector layout for 512-KiB LPC2300/2400 parts
Hi,
This patch fixes the sector layout of the 512-KiB LPC2000 parts that use the
lpc2000_v2 variant. This affects LPC2300/2400 devices.
Older devices (LPC213x) had only 27 sectors available (500 KiB), but the
LPC2300 have 28 sectors (504 KiB).
Regards,
Rolf
From dc19097c753aa3185fe8111b440884e9a76a94a2 Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 14:06:11 +0100
Subject: [PATCH 4/5] Fix sector layout for 504-KiB LPC2000 devices
---
src/flash/nor/lpc2000.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/flash/nor/lpc2000.c b/src/flash/nor/lpc2000.c
index 14d0e44..fea663e 100644
--- a/src/flash/nor/lpc2000.c
+++ b/src/flash/nor/lpc2000.c
@@ -196,10 +196,13 @@ static int lpc2000_build_sector_list(struct flash_bank *bank)
case 256 * 1024:
bank-num_sectors = 15;
break;
- case 512 * 1024:
case 500 * 1024:
bank-num_sectors = 27;
break;
+ case 512 * 1024:
+ case 504 * 1024:
+bank-num_sectors = 28;
+break;
default:
LOG_ERROR(BUG: unknown bank-size encountered);
exit(-1);
@@ -210,7 +213,7 @@ static int lpc2000_build_sector_list(struct flash_bank *bank)
for (i = 0; i bank-num_sectors; i++)
{
- if ((i = 0) (i 8))
+ if (i 8)
{
bank-sectors[i].offset = offset;
bank-sectors[i].size = 4 * 1024;
@@ -218,7 +221,7 @@ static int lpc2000_build_sector_list(struct flash_bank *bank)
bank-sectors[i].is_erased = -1;
bank-sectors[i].is_protected = 1;
}
- if ((i = 8) (i 22))
+ else if (i 22)
{
bank-sectors[i].offset = offset;
bank-sectors[i].size = 32 * 1024;
@@ -226,7 +229,7 @@ static int lpc2000_build_sector_list(struct flash_bank *bank)
bank-sectors[i].is_erased = -1;
bank-sectors[i].is_protected = 1;
}
- if ((i = 22) (i 27))
+ else if (i 28)
{
bank-sectors[i].offset = offset;
bank-sectors[i].size = 4 * 1024;
--
1.7.2.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] (patch) Hitex LPC2929 board script fix
Hi,
Simple patch to change the name of the external flash of the Hitex LPC2929
board. Avoids a name conflict with the on-chip flash.
Regards,
Rolf
From b0a147ca2233f0b2a2972db36ef9d89c9ff96f0f Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 13:54:47 +0100
Subject: [PATCH 2/5] Fix flash name in Hitex LPC2929 board config
---
tcl/board/hitex_lpc2929.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcl/board/hitex_lpc2929.cfg b/tcl/board/hitex_lpc2929.cfg
index d9ca110..13d3872 100644
--- a/tcl/board/hitex_lpc2929.cfg
+++ b/tcl/board/hitex_lpc2929.cfg
@@ -28,7 +28,7 @@ $_TARGETNAME configure -event reset-start {
}
# External 16-bit flash at chip select CS7 (SST39VF3201-70, 4 MiB)
-set _FLASHNAME $_CHIPNAME.flash
+set _FLASHNAME $_CHIPNAME.extflash
flash bank $_FLASHNAME cfi 0x5C00 0x40 2 2 $_TARGETNAME jedec_probe
--
1.7.2.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] (patch) New board config for Embedded Artists LPC2478-32
Hi,
This is a new board support file for the Embedded Artists LPC2478 board with
32-bit SDRAM (V1.2)
Regards,
Rolf
From fd162eff391213c4c3c4ee3194feecb52e442a16 Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 14:03:28 +0100
Subject: [PATCH 3/5] Add board config for Embedded Artists LPC2478-32
---
tcl/board/embedded-artists_lpc2478-32.cfg | 148 +
1 files changed, 148 insertions(+), 0 deletions(-)
create mode 100644 tcl/board/embedded-artists_lpc2478-32.cfg
diff --git a/tcl/board/embedded-artists_lpc2478-32.cfg b/tcl/board/embedded-artists_lpc2478-32.cfg
new file mode 100644
index 000..4939699
--- /dev/null
+++ b/tcl/board/embedded-artists_lpc2478-32.cfg
@@ -0,0 +1,148 @@
+# Embedded Artists eval board for LPC2478
+# http://www.embeddedartists.com/
+
+# Delays on reset lines
+adapter_nsrst_delay 500
+jtag_ntrst_delay 1
+
+# Adaptive JTAG clocking through RTCK.
+#
+jtag_rclk 20
+
+# Target device: LPC2478
+set CCLK 72000
+source [find target/lpc2478.cfg]
+
+# A working area will help speeding the flash programming
+$_TARGETNAME configure -work-area-phys 0x4200 -work-area-size [expr 0x1-0x200-0x20] -work-area-backup 0
+
+# External 16-bit flash at chip select CS0 (SST39VF3201-70, 4 MiB)
+flash bank $_CHIPNAME.extflash cfi 0x8000 0x40 2 2 $_TARGETNAME jedec_probe
+
+# Helper
+#
+proc read_register {register} {
+set result
+mem2array result 32 $register 1
+return $result(0)
+}
+
+
+# Enable the PLL.
+# Generate maximum CPU clock (72 MHz) Run from internal RC oscillator.
+# Note: The PLL output runs at a frequency N times the desired CPU clock.
+# It in unavoidable that the CPU clock drops down to (4 MHz/N) during
+# the initialization!
+# Here: N=4
+# Note that if the PLL is already active at the time this script is
+# called, the effective value of N is the value of CCLKCFG at that time!
+#
+proc enable_pll {} {
+# Disconnect PLL in case it is already connected
+if {[expr [read_register 0xE01FC080] 0x03] == 3} {
+# Disconnect it, but leave it enabled
+# (This MUST be done in two steps)
+mww 0xE01FC080 0x0001 # PLLCON: disconnect PLL
+mww 0xE01FC08C 0x00AA # PLLFEED
+mww 0xE01FC08C 0x0055 # PLLFEED
+}
+# Disable PLL (as it might already be enabled at this time!)
+mww 0xE01FC080 0x # PLLCON: disable PLL
+mww 0xE01FC08C 0x00AA # PLLFEED
+mww 0xE01FC08C 0x0055 # PLLFEED
+
+# Setup PLL to generate 288 MHz from internal RC oscillator
+mww 0xE01FC10C 0x # CLKSRCSEL: IRC
+mww 0xE01FC084 0x0023 # PLLCFG: N=1, M=36
+mww 0xE01FC08C 0x00AA # PLLFEED
+mww 0xE01FC08C 0x0055 # PLLFEED
+mww 0xE01FC080 0x0001 # PLLCON: enable PLL
+mww 0xE01FC08C 0x00AA # PLLFEED
+mww 0xE01FC08C 0x0055 # PLLFEED
+sleep 100
+mww 0xE01FC104 0x0003 # CCLKCFG: divide by 4 (72 MHz)
+mww 0xE01FC080 0x0003 # PLLCON: connect PLL
+mww 0xE01FC08C 0x00AA # PLLFEED
+mww 0xE01FC08C 0x0055 # PLLFEED
+}
+
+
+# Event handlers
+#
+$_TARGETNAME configure -event reset-start {
+# Back to the slow JTAG clock
+jtag_rclk 20
+}
+
+
+$_TARGETNAME configure -event reset-init {
+
+arm core_state arm
+arm7_9 dcc_downloads enable # Speed up downloads by using DCC transfer
+arm7_9 fast_memory_access enable
+
+# Peripheral clocks
+mww 0xE01FC0C4 0x04280FFE # PCONP: (reset value)
+
+# Map the user flash to the vector table area (0x00...0x3F)
+mww 0xE01FC040 0x0001 # MEMMAP: User flash
+
+# Memory accelerator module
+mww 0xE01FC004 0x0003 # MAMTIM: 3 clock cycles
+mww 0xE01FC000 0x0002 # MAMCR: fully enabled
+
+# Enable external memory bus (32-bit SDRAM at DYCS0, 16-bit flash at CS0)
+mww 0xE002C014 0x55010115 # PINSEL5: P2.16=CAS, P2.17=RAS, P2.18=CLKOUT0,
+# P2.20=DYCS0, P2.24=CKEOUT0, P2.28=DQMOUT0,
+# P2.29=DQMOUT1, P2.30=DQMOUT2, P2.31=DQMOUT3
+mww 0xE002C018 0x # PINSEL6: P3.0...P3.15=D0...D15
+mww 0xE002C01C 0x # PINSEL7: P3.16...P3.31=D16...D31
+mww 0xE002C020 0x # PINSEL8: P4.0...P4.15=A0...A15
+mww 0xE002C024 0x50051555 # PINSEL9: P4.16...P4.22=A16...A22, P4.24=OE,
+# P4.25=WE, P4.30=CS0, P4.31=CS1
+mww 0xFFE08000 0x0001 # EMCControl: Enable EMC
+
+# Start PLL, then use faster JTAG clock
+enable_pll
+jtag_rclk 3000
+
+# 16-bit flash @ CS0 (SST39VF3201-70)
+mww 0xFFE08200 0x00080081 # EMCStaticConfig0: 16 bit, PB=1, buffers on
+mww 0xFFE08204 0x # EMCStaticWaitWen0
+mww 0xFFE08208 0x
[Openocd-development] (patch) Change target script for LPC2478
Hi,
This patch allows a board script to specify the CPU clock of the LPC2478 target.
The clock frequency used to be fixed to 4 MHz. However, there is no default
frequency for this CPU. You mustn't assume prior knowledge of the clock
frequency, but rather demand that the user (board script) specifies it.
This clock frequency is the CPU clock at the time of flash programming! Usually
board scripts will enable the PLL to speed up debugging/programming. This MUST
be the correct frequency, or flash programming will fail or produce unreliable
results.
This will break all LPC2478 board or user scripts. Users must add the intended
operating clock frequency before they include the target script:
set CCLK 72000
source [find target/lpc2478.cfg]
Regards,
Rolf
From 0b314d0bcbdedfc3ef8ec8dacf97e1f8ad2d5ac8 Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 14:10:40 +0100
Subject: [PATCH 5/5] lpc2478 target config: CCLK as (mandatory) parameter
---
tcl/target/lpc2478.cfg | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index df46c10..1e11d9e 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -12,6 +12,12 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
+if { [info exists CCLK ] } {
+ set _CCLK $CCLK
+} else {
+error You must specify the CCLK that will be used for flash programming!
+}
+
#delays on reset lines
adapter_nsrst_delay 100
jtag_ntrst_delay 100
@@ -35,10 +41,7 @@ $_TARGETNAME configure -event reset-init {
}
# LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.
-# After reset the chip uses its internal 4MHz RC oscillator.
# flash bank name lpc2000 base size 0 0 target# variant clock [calc checksum]
set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x7D000 0 0 $_TARGETNAME lpc2000_v2 4000 calc_checksum
+flash bank $_FLASHNAME lpc2000 0x0 0x7E000 0 0 $_TARGETNAME lpc2000_v2 $_CCLK calc_checksum
-# Try to use RCLK, if RCLK is not available use normal mode. 4MHz / 6 = 666kHz, so use 500.
-jtag_rclk 500
--
1.7.2.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Hi Freddie, On 12/03/2010 08:09 PM, Freddie Chopin wrote: First of all, the chip frequency after reset actually is 4MHz due to internal RC oscillator, so this default frequency assumption seems pretty correct (actually it was probably me who added that script to OpenOCD). Incorrect. Yes, the chip starts from its 4 MHz oscillator, but what the clock frequency actually is by the time OpenOCD gets access is unpredictable. If for instance the flash is empty, the device will enter ISP mode automatically. It will activate the PLL, and from then on run with 14.748 MHz. When in this situation you program the flash with the clock parameter set to 4 MHz, the programming pulse will have a width of less than 30% of the required time. Might work, usually will, but is unreliable. The clock parameter is vital for correct and reliable flash programming. It must be possible for the user to select the frequency that he is using. Debugging is negligibly faster when using high clock, flash programming duration gain is probably also negligible (what's the difference between waiting for 20 seconds to waiting for 10 seconds?). 10 seconds? 100% (as seen by the the lucky 10s user)? And by the way this is unrealistic. The penalty is much higher! At 72 MHz I can program the LPC2478 (504 KiB) in 14s with a simple JTAG interface. I feel no urge to wait longer than that. Anyway - I never enable PLL before flash programming, I bet that most regular users also don't. A classical chicken and egg case. We don't have good board scripts especially for the LPC devices. That's why people don't use it. But most of all - this makes running OpenOCD with just command line arguments impossible (openocd -f interface/sth.cfg -f target/sth_else.cfg), as now you have to have your board config file. Please - don't go this way. Why would that be impossible? Who prevents you to use a script that sets *your* clock frequency and includes the target script? Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Hi Freddie, On 12/03/2010 11:11 PM, Freddie Chopin wrote: How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz internal clock. Doing reset halt sets that clock and prevents any code from changing that (let's not talk about broken cases, because a broken case can be found everywhere), so what's wrong with this approach? This is a misconception. When OpenOCD tries to take control after a reset, the CPU is already running. ISP mode or existing user firmware may or may not have changed the clock tree. Like it or not, but there is no a priori knowledge of CPU clock. With LPC23xx you are in the same situation as with older LPC2000 which required an external crystal. The operating frequency is *not* a target parameter, it is a board/application parameter. What's the purpose of using a 512KiB flash micro if you only need 50K? Lots of applications *will* use big parts of the flash, and yes, programming times *do* matter in my development cycle, especially if we are talking 10s vs. 20s (and for no good reason!). Why use big chip? LPC2478 has an LCD driver, and there is no chip with LCD driver that has less flash. Because for developement of the project you take big chip just-in-case, and choose right one (regarding flash size) for production when the code is ready. Anyway - we should be talking about the average size of the upload, and that's never 512kB - the code has to grow from 0 to this size during developement. BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based JTAG)? I'm asking because if waiting 10s is worth breaking configurations of OpenOCD's regular users, then I hope you use the fastest library for the process. C'mon! 10s?! Don't read mailing lists and that will save you much more time (; I'm afraid but professional embedded development is different. Speed matters. Why would I renounce the comfort of a fast download when I can get it for free? I want OpenOCD to be as efficient as possible. If you don't like that, you may always run at a slower clock, and help yourself with a cup of tea. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! That's the whole point of OpenOCD's layered config file approach. Do you refuse to work with an LPC2138 device just because its target config file cannot include a clock frequency? There is no way to avoid a board file here. And at the risk of repeating myself, the situation for LPC23xx is the same. So what is the problem? Right now, you are using the LPC2478 target config file. You could use some kind of lpc2478_std config file instead - same amount of typing, same user experience, but those people working with more complex boards will have the benefit of running at the right clock speed. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not getting it. We're talking about a three-liner: 1. your interface, 2. your clock frequency, 3. your target. That's clearly a no-brainer! I have a crazy idea - I think it is possible to measure frequency of the external crystal (and check for it's existence) with simple code using one timer. This way OpenOCD would work without specifying this frequency. It could then - before programming - measure it (backup-ing all settings of timer), switch PLL to max value (using external crystal or internal resonator, also backup-ing all settings of clock and PLL), flash, revert all changes made to clock, PLL and timer and voila [; Problem gone Nice idea. However, that goes way beyond what is required right now to get reliable programming at the maximum possible speed. Also, will this work without a reset init to get the system into a known state? I was thinking about embedding that within OpenOCD's flash handling code specific for LPC, not in config files. Right now you have to supply that speed, with such wise flashing algorithm this parameter would be useless (could be provided, could be omitted - freq would be measured then). Deep inside I have a feeling that this proposal is on a head-on collision course with your wish for simplicity... Technically, I do not know
[Openocd-development] git submodule failure behind HTTP-only proxy
Hi, I have a problem updating the git submodules when doing this from behind a HTTP-only proxy. Cloning (git clone http://repo.or.cz/r/openocd.git) works fine. Next step (./bootstrap) is also ok. However, the following step shows that a mixture of http and git protocol is used: git submodule init Submodule 'jimtcl' (http://repo.or.cz/r/jimtcl.git) registered for path jimtcl' Submodule 'tools/git2cl' (git://repo.or.cz/git2cl.git) registered for path 'tools/git2cl' The next step (git submodule update) fails on the git2cl submodule. Cloning into tools/git2cl... fatal: Unable to look up repo.or.cz (port 9418) (Name or service not known) Clone of 'git://repo.or.cz/git2cl.git' into submodule path 'tools/git2cl' failed My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC2919 segmentation fault
Hi Mirda, --- MIroslav Dušek mirda.d...@gmail.com schrieb am Fr, 26.11.2010: mdw 0xE100 16 0xe100: Ooops, that's a broken device! Looks like it hasn't seen the final production test before shipping... I'll follow up on this by private email. Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC2919 segmentation fault
Hi Mirda, --- mirda.d...@gmail.com mirda.d...@gmail.com schrieb am Do, 25.11.2010: When I put flash probe 0 for first time I get Unknown LPC29xx derivative Can you send us a memory dump of 16 bytes at address 0xE100 of the LPC2919? (0xE100...0xE10F) Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] mem2array command fails in event handler
Hi, I hope that somebody can help with this problem: A target script defines a reset-end handler. In this handler I need to read a few words from target memory. When I try to use ocd_mem2array, the command fails with Error: 357 1442 target.c:3106 jim_mem2array(): mem2array: no command context The same command works fine on the telnet prompt. Is this command supposed to work in the reset-end event handler? If not, is there an alternative? I've tried mdw, but this seems to just print the values, not return them as a result. Recently there has been a similar complaint from Alexei about the mcr/mrc commands, but I haven't seen a solution for it. Those commands are jim_handler commands just like mem2array. Regards, Rolf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC29xx and scan chain topolgy
Hi Todd, --- Todd Krein todd.kr...@ooma.com schrieb am Mi, 10.2.2010: I’m trying to understand the relationship between the scan chain in the ARM968E core and the rest of the system scan chains in the NXP LPC29xx family. I’ve found documentation, from ARM, on the scan chain/TAP controller for the ARM9E core family, and then from NXP there is information on the internal scan chains required to access FLASH and other systems peripherals. What I don’t understand is the relationship between the two. Are the internal scan chains all sitting off of one of the ARM’s unused chains? There are two independent TAP controllers on the LPC29xx. One TAP is for access to the ARM968E core, the other is for boundary scan and direct flash access. The access to both is mutually exclusive, and is controlled by the JTAGSEL pin of the device. The first TAP is the normal one, and the one you use with debug tools like OpenOCD. There's access to the CPU, the system peripherals and the flash through this TAP. Flash access is CPU controlled: A piece of code downloaded to RAM does the job. The second TAP is mainly useful for board production. During final board test you select this TAP through JTAGSEL. You can do boundary scan to verify your PCB function, and you can use direct flash register access independent of the CPU for a fast initial flash programming. The second TAP isn't useful for debugging, since you cannot access the CPU through it. You'd rather use the first TAP, and do flash programming under CPU control. Without any JTAG connection, JTAGSEL is usually left at its default (second TAP!). This is because it also influences which oscillator is used for system startup. I hope this is at least close to what you've asked for. :-) Regards, Rolf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding support for SST 39VF6401B external flash
Hi Flemming,
--- Flemming Futtrup f...@deif.com schrieb am Mi, 30.12.2009:
I have run into trouble with a new board holding the SST
39VF6401B external flash.
TAP: lpc2468.cpu (enabled)
Make sure the buffering is disabled in EMCStaticConfig0 of the LPC2468 (board
config file?).
If enabled, the target algorithm cannot detect the end of the program cycle,
and will wait in an endless loop until a timeout occurs.
At this point I assumed that the concerned Flash device is
a NON_CFI device.
The reason to declare this device as NON-CFI is that it doesn't work with the
DQ5 polling mode. This mode is standard for CFI devices in cfi.c. Probably it
would be cleaner to define a new fixup function in cfi.c, but the approach with
non_cfi.c should work fine for your device.
First of all there was no support for this flash in the
non_cfi.c so I added this:
{
.mfr = CFI_MFR_SST,
.id = 0x236d,
/* SST39VF6401B */
.pri_id = 0x02,
.dev_size = 8*MB,
.interface_desc = 0x2, /* x8 or x16 device
with BYTE */
.max_buf_write_size = 0x0,
.status_poll_mask = CFI_STATUS_POLL_MASK_DQ6_DQ7,
.num_erase_regions = 1,
.erase_region_info =
{
ERASE_REGION(2048, 4*KB)
}
},
That's ok.
Then I added this line to the cfi.c cfi_0002_fixups array:
{CFI_MFR_SST, 0x236d, cfi_fixup_0002_unlock_addresses,
cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
Looks ok, but probably this is already the default, so your fixup won't change
anything.
If the buffer bit is not the problem, it will help to see the debug output
('-d' switch).
Regards,
Rolf
__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding support for SST 39VF6401B external flash
Hi Flemming, --- Flemming Futtrup f...@deif.com schrieb am Mi, 30.12.2009: Including this: mww 0xFFE08200 0x0081 Which I believe to be what you mention? Yes. And it's ok! (The buffer is disabled) flash bank cfi 0x8000 0x80 2 2 $_TARGETNAME jedec_probe I'm surprised that this works! :-) As far as I understand, the jedec_probe option selects the wrong unlock addresses for this flash. The option is required for the non-B versions of the SST flash (SST39VF6401), but not the SST39VF6401B. However, probing works fine for you, so I'm not sure... Maybe it's worth trying without the jedec_probe option anyway. Regards, Rolf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
Hi Dirk, --- Dirk Behme dirk.be...@googlemail.com schrieb am Mo, 5.10.2009: Rolf, could you try if git clone http://git.gitorious.org/u-boot-omap3/mainline.git works for you? Yes, that works for me! I can successfully clone this very small project on github, too: http://github.com/tekkub/addontemplate.git Most probably you have to set export http_proxy=http://username:password@proxy_ip:proxy_port for this. This seems to be the only required setting to make it work. I run Squid on my local machine, and I have http_proxy=http://localhost:8080 set here. GIT honors that setting, and I don't have to configure it explicitly with 'git config http.proxy'. My vote is for a server that supports http for read-only access :-) Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RE: new lpc2xxx cfg files layout
Hi Freddie, - Ursprüngliche Mail How would you write a board file for a board with two LPC2103 in the chain? A simple source [find target/lpc2103.cfg] source [find target/lpc2103.cfg] wouldn't work because it would try to declare two targets with the same name (lpc2103.cpu). Previously it was possible to write: set CHIPNAME chip1 source [find target/lpc2103.cfg] set CHIPNAME chip2 source [find target/lpc2103.cfg] It gave you two targets chip1.cpu and chip2.cpu. You should not source lpc2103.cfg twice, but lpc2xxx_internals.tcl twice - with all necessary defines. A little more text unfortunately. Yes, this is how it could be done. However, for the first instance you would use the existing lpc2103.cfg, while for the second instance you had to copy the content of that file into your board config. It's possible, but I don't think it would be really straightforward. If I understand your latest proposal correctly, CHIPNAME is just for info (for naming the target). It's no longer being used in lpc2xxx_internals.tcl to determine the defaults for a specific chip. This is now done in (for instance) lpc2103.cfg. Why not just remove the CHIPNAME from the specific files, and just use an overridable default (lpc2000) in lpc2xxx_internals.tcl? This would solve the multiple instantiation problem. The target would be named lpc2000.cpu by default. Do you suggest renaming CRYSTAL_FREQ to (for example) CCLK_FREQ or some other changes? No, it's fine as it is. Just has to be explained in the manual. The reset init script must be available to the user, because he needs it to add the PLL initialization. Where would I enable the PLL when a default reset init script is already defined in the target script? From what I have noticed all LPC2xxx have exactly the same PLL configuration scheme, so that's more like target related in my opinion. The PLL setup code will work (when written right) on all LPC2xxx chips. The only concen is the difference between the chips with / without internal RC. PLL blocks in LPC23xx and LPC21xx are different. I admit that I don't have a good idea yet how this can be done properly. The working area should start at 0x4200. This makes sure that there is no conflict with possible temporary storage of IAP code (has been a problem in the past, although the 0x4000--0x41FF area should have been used by ISP code only). A strict requirement is to not touch the upper 32 bytes of the internal SRAM. This RAM area is definitely used by the IAP routines internally! Sounds reasonable, but in my experience I haven't noticed any problems with using exactly whole RAM. Currently the upper 32 bytes will not be used by the flash driver, but just by chance. A future version of the driver might want to use that part of the working area, and then we would be in trouble. So I suggest to limit the working area to 0x4200--(SRAM end - 32). There are devices with external memory bus. A user might want to use an external RAM for the working area instead of the internal SRAM. Therefore I think the working area declaration is board specific and doesn't belong to the target declaration. The start of working area can be made overridable with default being 0x4000. I had a quick look at the sources, and it looks like that you can have multiple working area declarations. Only the last one will be used, so it's fine to have a default working area. If a user wants to utiize the external RAM of an LPC2468, he can just declare a new working area. What do you think about modifying the LPC2000 flash driver to adapt itself to the various devices? It can read the part id and auto-configure itself. You could keep the FLASH_SIZE and RAM_SIZE variables to override any automatic detection. I feel it would make life a lot easier! I've noticed that ideas of auto-whatever are not liked here : For me that's cool, but beyond my knowledge. I saw that, too :-) I would volunteer to make the necessary changes to the lpc2000 driver. This is my idea: - Autodetect the device, and configure flash size and sector layout (variant) automatically. - Only use the autodetected values if the user has passed 0 in the corresponding field of the flash bank declaration. - Issue a warning if overridden values do not match autodetected values. - Should there be new devices not yet supported by the driver, you may specify everything manually. - Doesn't break existing config files. - Register the driver as lpc2000 and lpc1700. Allows to use real family names, although (up to now) everything can be handled with one driver. In the future, there could be a specific driver for each family without breaking config files that we write now. Also allows to add new command handlers that are specific for LPC1700. Consequence: You do not have to set the FLASH_SIZE anywhere. There is now only one reason left to have chip specific
Re: [Openocd-development] new lpc2xxx cfg files layout
Hi Freddie,
I didn't find the time yet to write a few comments. But here they are:
They are all meant to be constructive and friendly! :-)
How would you write a board file for a board with two LPC2103 in the chain?
A simple
source [find target/lpc2103.cfg]
source [find target/lpc2103.cfg]
wouldn't work because it would try to declare two targets with the same name
(lpc2103.cpu).
Previously it was possible to write:
set CHIPNAME chip1
source [find target/lpc2103.cfg]
set CHIPNAME chip2
source [find target/lpc2103.cfg]
It gave you two targets chip1.cpu and chip2.cpu.
Regarding the clock speed: What you call CRYSTAL_FREQ is the frequency that is
in use when you do the flash programming. In order to be able to maximize the
download speed, I want to enable the PLL in the reset init script. This
operating frequency isn't really related to the crystal frequency, and I think
the name CRYSTAL_FREQ is misleading.
Many people in the past had problems with flash programming because they
specified the crystal frequency where they should have used the real CCLK!
This clock frequency is something that the user should specify in a board file.
The reset init script must be available to the user, because he needs it to add
the PLL initialization. Where would I enable the PLL when a default reset init
script is already defined in the target script?
The working area should start at 0x4200. This makes sure that there is no
conflict with possible temporary storage of IAP code (has been a problem in the
past, although the 0x4000--0x41FF area should have been used by ISP
code only).
A strict requirement is to not touch the upper 32 bytes of the internal SRAM.
This RAM area is definitely used by the IAP routines internally!
There are devices with external memory bus. A user might want to use an
external RAM for the working area instead of the internal SRAM. Therefore I
think the working area declaration is board specific and doesn't belong to the
target declaration.
What do you think about modifying the LPC2000 flash driver to adapt itself to
the various devices? It can read the part id and auto-configure itself. You
could keep the FLASH_SIZE and RAM_SIZE variables to override any automatic
detection. I feel it would make life a lot easier!
Regards,
Rolf
--- Freddie Chopin freddie_cho...@op.pl schrieb am So, 27.9.2009:
Von: Freddie Chopin freddie_cho...@op.pl
Betreff: Re: [Openocd-development] new lpc2xxx cfg files layout
An: openocd-development openocd-development@lists.berlios.de
Datum: Sonntag, 27. September 2009, 21:05
Be it your way...
4\/3!!
-Integrierter Anhang folgt-
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision
2744)
+++ tcl/target/lpc2103.cfg (working
copy)
@@ -1,38 +1,19 @@
-# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM,
clocked with 12MHz crystal
+# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM
+#
-
+# do not use this file directly! the caller has to specify
CRYSTAL_FREQ with:
+# set CRYSTAL_FREQ frequency in Hz
+#
-
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2103
-}
+set CHIPNAME lpc2103
+set FLASH_SIZE 0x8000
+set RAM_SIZE 0x2000
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
+set VARIANT lpc2000_v2
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- set _CPUTAPID 0x4f1f0f0f
-}
+set CPUTAPID 0x4f1f0f0f
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+set JTAG_FREQ 100
-# reset delays
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
+set RESET_CONFIG trst_and_srst
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask
0xf -expected-id $_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi -endian $_ENDIAN
-chain-position $_TARGETNAME -variant arm7tdmi-s_r4
-
-# 8kB of internal SRAM
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys
0x4000 -work-area-size 0x2000 -work-area-backup 0
-
-# 32kB of internal Flash, core clocked with 12MHz crystal
-# flash bank lpc2000 base size 0 0
target# variant clock
[calc_checksum]
-flash bank lpc2000 0x0 0x8000 0 0 0 lpc2000_v2 12000
calc_checksum
+source [find target/lpc2xxx_internals.tcl]
Index: tcl/target/lpc2124.cfg
===
--- tcl/target/lpc2124.cfg (revision
2744)
+++ tcl/target/lpc2124.cfg (working
copy)
@@ -1,42 +1,19 @@
-#LPC-2124 CPU
+# NXP LPC2124 ARM7TDMI-S with 256kB Flash and 16kB SRAM
+#
-
+# do not use this file directly! the caller has
Re: [Openocd-development] problems with FASTDATA bulk write and spansion flash
Hi Stephan, Thanks! I just saw that you are using a MIPS processor. The cfi_spansion_write_block() function supports ARM targets only. Currently this executes ARM opcodes on your machine, so you can be lucky that it returned at all :-) There is no checking the architecture yet. I believe your only choice at the moment is to not define a working area (or one that has a ~300 bytes maximum). That would ensure that the ARM code doesn't get executed because of low resources. Or maybe you want to fix it? :-) Regards, Rolf Anyone: How can I detect most efficiently that a target supports ARM code? --- Stephan Winokur m...@swinokur.com schrieb am Mo, 21.9.2009: Von: Stephan Winokur m...@swinokur.com Betreff: Re: AW: [Openocd-development] problems with FASTDATA bulk write and spansion flash An: Rolf Meeser rolfm_...@yahoo.de, openocd-development@lists.berlios.de Datum: Montag, 21. September 2009, 7:47 Hi Rolf, The device is a Spansion S29GL512P11TFI01. flash info 0 says: flash info 0 #0 : cfi at 0x4800, size 0x0400, buswidth 2, chipwidth 2 # 0: 0x (0x2 128kB) protection state unknown # 1: 0x0002 (0x2 128kB) protection state unknown # 2: 0x0004 (0x2 128kB) protection state unknown # 3: 0x0006 (0x2 128kB) protection state unknown # 4: 0x0008 (0x2 128kB) protection state unknown # 5: 0x000a (0x2 128kB) protection state unknown # 6: 0x000c (0x2 128kB) protection state unknown # 7: 0x000e (0x2 128kB) protection state unknown # 8: 0x0010 (0x2 128kB) protection state unknown [...] #510: 0x03fc (0x2 128kB) protection state unknown #511: 0x03fe (0x2 128kB) protection state unknown cfi information: mfr: 0x0001, id:0x227e qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id: 0x, alt_addr: 0x Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0 typ. word write timeout: 64, typ. buf write timeout: 64, typ. block erase timeout: 512, typ. chip erase timeout: 524288 max. word write timeout: 512, max. buf write timeout: 2048, max. block erase timeout: 4096, max. chip erase timeout: 2097152 size: 0x400, interface desc: 2, max buffer write size: 40 Spansion primary algorithm extend information: pri: 'PRI', version: 1.3 Silicon Rev.: 0x5, Address Sensitive unlock: 0x0 Erase Suspend: 0x2, Sector Protect: 0x1 VppMin: 11.5, VppMax: 12.5 At 10:40 PM 9/20/2009, Rolf Meeser wrote: Hi Stephan, What is the exact type number of the flash device? Regards, Rolf --- Stephan Winokur m...@swinokur.com schrieb am Mo, 21.9.2009: Von: Stephan Winokur m...@swinokur.com Betreff: [Openocd-development] problems with FASTDATA bulk write and spansion flash An: openocd-development@lists.berlios.de Datum: Montag, 21. September 2009, 4:45 Hi all, I'm trying to make faster flash writes happen on a mips based platform -- because this is crazy: wrote 524288 byte from file /root/flashme.bin in 45807.718750s (0.011177 kb/s). I've downloaded the svn snapshot (2734), applied the FASTDATA bulk write optimization, and made the necessary changes in my target to add a working area. (mww and mdw show me able to modify values, read them back, etc.) (the target line is: target create $_TARGETNAME mips_m4k -endian $_ENDIAN -variant ejtag_srst -chain- position $_TARGETNAME -work-area-phys 0xb010 -work-area-size 0x1000) When I try to write flash, I get this error: Debug: 260 36117 target.c:1108 target_write_buffer(): writing buffer of 2048 byte at 0xb0100060 Debug: 261 36117 mips_m4k.c:990 mips_m4k_bulk_write_memory(): address: 0xb0100060, count: 0x0200 Debug: 262 36117 target.c:962 target_alloc_working_area(): allocating new working area Info : 266 37460 mips32_pracc.c:858 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xb0100860 for write handler Debug: 267 37504 cfi.c:1562 cfi_spansion_write_block(): status: 0xb7fac190 Error: 268 37504 flash.c:100 flash_driver_write(): error writing to flash at address 0x4800 at offset 0x (-902) When I try to use load_image, I get this error: load_image /root/small.bin 0xb020 mips32_pracc_fastdata_xfer using 0xb010 for write handler User : 134 6572 mips32.c:269 mips32_arch_state(): target halted due to debug-request, pc: 0xbfc0 Debug: 136 10713 command.c:68 script_debug(): command - load_image Debug: 137 10713 command.c:77 script_debug(): load_image - argv[0]=ocd_load_image Debug: 138 10713 command.c:77 script_debug(): load_image - argv[1]=/root/small.bin Debug: 139 10713 command.c:77 script_debug(): load_image - argv[2]=0xb020 Debug: 140
Re: [Openocd-development] 0.3 anyone?
Hi,
I had problems with the reset init on LPC2478, too. I didn't analyze it
deeply, but I noticed this problem:
OpenOCD reported that it couldn't halt the target. With debug on, I got the
impression that the EmbeddedICE had been programmed for a break before the
final SRST/TRST happened. There was an attempt to reprogram it afterwards, but
that didn't seem to be complete.
I've added a call to jtag_add_tlr(), and that solved it for me.
All relevant EmbeddedICE registers are now reprogrammed.
It looks like there's some internal state which didn't notice that the target
hardware got a reset. Seems reasonable to me to have the TAP reset call here,
but I'm not an expert...
Regards,
Rolf
Index: src/target/arm7_9_common.c
===
--- src/target/arm7_9_common.c (revision 2731)
+++ src/target/arm7_9_common.c (working copy)
@@ -1105,6 +1105,9 @@
if (target-reset_halt (jtag_reset_config RESET_SRST_PULLS_TRST)
!= 0)
{
LOG_WARNING(srst pulls trst - can not reset into halted mode.
Issuing halt after reset.);
+
+ jtag_add_tlr();
+
/* set up embedded ice registers again */
if ((retval = target_examine_one(target)) != ERROR_OK)
return retval;
--- Freddie Chopin freddie_cho...@op.pl schrieb am Mo, 21.9.2009:
Von: Freddie Chopin freddie_cho...@op.pl
Betreff: Re: [Openocd-development] 0.3 anyone?
An: Øyvind Harboe oyvind.har...@zylin.com
CC: openocd-development@lists.berlios.de
Datum: Montag, 21. September 2009, 19:04
Øyvind Harboe pisze:
Does anyone have a bunch of stuff that will be
completed in the near future?
How about that new LPC2xxx cfg files layout?
With a bit of investigation the reset init should be
working, or that
can be left for future, as now this script is not fully
functional either...
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase
Hi Johnny,
it should be
+if ( first last ) {
not
+if ( first = last ) {
With first=last you can erase a single sector.
Regards,
Rolf
--- Johnny Halfmoon jhalfm...@milksnot.com schrieb am Mo, 21.9.2009:
Von: Johnny Halfmoon jhalfm...@milksnot.com
Betreff: Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last
sector for protection and erase
An: David Brownell davi...@pacbell.net
CC: openocd-development@lists.berlios.de
Datum: Montag, 21. September 2009, 21:33
David Brownell wrote:
On Sunday 20 September 2009, Johnny Halfmoon wrote:
+
if ((retval =
flash_check_sector_parameters(cmd_ctx, first, last,
p-num_sectors)) !
I had in mind more like
uint32_t value;
Okay. Like this then:
= = = = = = = = = = = =
doc/openocd.texi | 6 ++-
src/flash/flash.c | 97
+++---
2 files changed, 67 insertions(+), 36 deletions(-)
Index: src/flash/flash.c
===
--- src/flash/flash.c (revision 2736)
+++ src/flash/flash.c (working copy)
@@ -559,40 +559,62 @@
return ERROR_OK;
}
+int flash_check_sector_parameters(struct command_context_s
*cmd_ctx, uint32_t first, uint32_t last, uint num_sectors)
+{
+ if ( first = last ) {
+
command_print(cmd_ctx, ERROR: last sector must be
first sector);
+ return ERROR_FAIL;
+ }
+
+ if ( last (num_sectors - 1)) {
+
command_print(cmd_ctx, ERROR: last sector must be =
%d, num_sectors - 1);
+ return ERROR_FAIL;
+ }
+
+ return ERROR_OK;
+}
+
static int handle_flash_erase_command(struct
command_context_s *cmd_ctx, char *cmd, char **args, int
argc)
{
if (argc 2)
{
- int first =
strtoul(args[1], NULL, 0);
- int last =
strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
int retval;
- flash_bank_t *p =
get_flash_bank_by_num(strtoul(args[0], NULL, 0));
+
+ if ((retval =
parse_u32(args[0], bank_nr)) != ERROR_OK)
+
return retval;
+
+ flash_bank_t *p =
get_flash_bank_by_num(bank_nr);
+ if (!p)
+
return ERROR_OK;
+
+ if ((retval =
parse_u32(args[1], first)) != ERROR_OK)
+
return retval;
+ if (strcmp(args[2],
last) == 0)
+
last = p-num_sectors - 1;
+ else
+
if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+
return retval;
+
+ if ((retval =
flash_check_sector_parameters(cmd_ctx, first, last,
p-num_sectors)) != ERROR_OK)
+
return retval;
+
duration_t
duration;
char
*duration_text;
-
duration_start_measure(duration);
- if (!p)
- {
-
return ERROR_COMMAND_SYNTAX_ERROR;
- }
-
- if ((retval =
flash_driver_erase(p, first, last)) == ERROR_OK)
- {
+ if ((retval =
flash_driver_erase(p, first, last)) == ERROR_OK) {
if ((retval = duration_stop_measure(duration,
duration_text)) != ERROR_OK)
-
{
return retval;
-
}
-
-
command_print(cmd_ctx, erased sectors %i through %i on
flash bank %li in %s,
-
first, last, strtoul(args[0], 0, 0),
duration_text);
+
command_print(cmd_ctx, erased sectors %i through %i on
flash bank %i in %s,
+
first, last, bank_nr, duration_text);
free(duration_text);
}
}
else
- {
return
ERROR_COMMAND_SYNTAX_ERROR;
- }
return ERROR_OK;
}
@@ -601,40 +623,47 @@
{
if (argc 3)
{
- int first =
strtoul(args[1], NULL, 0);
- int last =
strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
+ int retval;
int set;
- int retval;
- flash_bank_t *p =
get_flash_bank_by_num(strtoul(args[0], NULL, 0));
+
+ if ((retval =
parse_u32(args[0], bank_nr)) != ERROR_OK)
+
return retval;
+
+ flash_bank_t *p =
get_flash_bank_by_num(bank_nr);
if (!p)
- {
-
command_print(cmd_ctx, flash bank '#%s' is out of bounds,
args[0]);
return ERROR_OK;
- }
+ if ((retval =
parse_u32(args[1], first)) != ERROR_OK)
+
return retval;
+ if (strcmp(args[2],
last) == 0)
+
last = p-num_sectors - 1;
+ else
+
if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+
return retval;
+
if (strcmp(args[3],
on) == 0)
set = 1;
else if
(strcmp(args[3], off) == 0)
set = 0;
else
- {
return ERROR_COMMAND_SYNTAX_ERROR;
- }
+ if ((retval =
[Openocd-development] Re: [PATCH] debug message
Hi Øyvind, --- Øyvind Harboe oyvind.har...@zylin.com schrieb am Mi, 16.9.2009: This patch needs work. OpenOCD lacks the exception concept of a try-catch. There are other cases where we *do* want error messages. I agree that we need a message when it *finally* fails. However, when a tentative call to alloc() can't be fulfilled, only the caller knows what that means. It may retry the allocation a few times with a smaller size, then give up after a while. If this is fatal, it should issue a LOG_ERROR. If it can fall back to another option, it may just silently drop the info. If that other option slows things noticeably down, it may issue a LOG_INFO/LOG_WARNING. I've just checked all calls to target_alloc_working_area(). With two exceptions, all modules do one of the following: a) LOG_ERROR (ok) b) LOG_WARNING (ok) c) LOG_WARNING + fallback (ok) d) LOG_INFO + fallback (ok) e) no message, just fallback (ok) f) LOG_DEBUG (arm_nandio,c) (a LOG_WARNING would be better) Only target/armv7m.c and target/arm7_9_common.c just pass the error to the caller. This is for the checksum and blank check algorithms. I would suggest to add LOG_WARNING here. I'm still convinced that the warning in target_alloc_working_area() is misplaced. With the current situation, a bunch of warning may be issued, but the software runs perfectly. Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PATCH: cfi.c: Improved support for some flash devices
Hi,
This patch adds target algorithm support for those flash devices that do not
support DQ5 polling. So far they could only be programmed with host algorithm,
but this was way too slow.
I added support for 16-bit devices only (I have an SST39VF3201). I didn't want
to add support for 8 and 32 bit without being able to test the assembler code.
The different assembler code fragments can now be of arbitrary size (fixed a
hard coded value).
All working areas are now freed at the end of cfi_spansion_write_block(). This
fixes a bug (cfi_info-write_algorithm wasn't freed before, and caused a crash
when the write function was called again). It also prevents the working_area
from becoming fragmented in two halfes.
Regards,
Rolf
Index: src/flash/cfi.c
===
--- src/flash/cfi.c (revision 2681)
+++ src/flash/cfi.c (working copy)
@@ -1384,6 +1384,31 @@
0xeafe /* b 81ac sp_16_done */
};
+ static const uint32_t word_16_code_dq7only[] = {
+/* sp_16_code: */
+ 0xe0d050b2, /* ldrh r5, [r0], #2 */
+ 0xe1c890b0, /* strh r9, [r8] */
+ 0xe1cab0b0, /* strh r11, [r10]*/
+ 0xe1c830b0, /* strh r3, [r8]*/
+ 0xe1c150b0, /* strh r5, [r1] */
+ 0xe1a0, /* nop (mov r0,r0)*/
+/* */
+/* sp_16_busy: */
+ 0xe1d160b0, /* ldrh r6, [r1] */
+ 0xe0257006, /* eor r7, r5, r6 */
+ 0xe2177080, /* ands r7, #0x80 */
+ 0x1afb, /* bne 8168 sp_16_busy */
+/* */
+ 0xe2522001, /* subs r2, r2, #1 ; 0x1 */
+ 0x03a05080, /* moveq r5, #128 ; 0x80 */
+ 0x0a01, /* beq 81ac sp_16_done */
+ 0xe2811002, /* add r1, r1, #2 ; 0x2 */
+ 0xeaf0, /* b 8158 sp_16_code */
+/* */
+/* 81ac sp_16_done: */
+ 0xeafe /* b 81ac sp_16_done */
+ };
+
static const uint32_t word_8_code[] = {
/* 81b0 sp_16_code_end: */
0xe4d05001, /* ldrb r5, [r0], #1 */
@@ -1423,10 +1448,10 @@
armv4_5_info.core_state = ARMV4_5_STATE_ARM;
/* flash write code */
+ int target_code_size;
if (!cfi_info-write_algorithm)
{
uint8_t *target_code;
- int target_code_size;
const uint32_t *src;
/* convert bus-width dependent algorithm code to correct endiannes */
@@ -1437,8 +1462,18 @@
target_code_size = sizeof(word_8_code);
break;
case 2:
- src = word_16_code;
- target_code_size = sizeof(word_16_code);
+ /* Check for DQ5 support */
+ if( cfi_info-status_poll_mask (1 5) )
+ {
+src = word_16_code;
+target_code_size = sizeof(word_16_code);
+ }
+ else
+ {
+/* No DQ5 support. Use DQ7 DATA# polling only. */
+src = word_16_code_dq7only;
+target_code_size = sizeof(word_16_code_dq7only);
+ }
break;
case 4:
src = word_32_code;
@@ -1515,7 +1550,7 @@
retval = target_run_algorithm(target, 0, NULL, 10, reg_params,
cfi_info-write_algorithm-address,
- cfi_info-write_algorithm-address + ((24 * 4) - 4),
+ cfi_info-write_algorithm-address + ((target_code_size) - 4),
1, armv4_5_info);
status = buf_get_u32(reg_params[5].value, 0, 32);
@@ -1532,7 +1567,7 @@
count -= thisrun_count;
}
- target_free_working_area(target, source);
+ target_free_all_working_areas(target);
destroy_reg_param(reg_params[0]);
destroy_reg_param(reg_params[1]);
Index: src/flash/non_cfi.c
===
--- src/flash/non_cfi.c (revision 2681)
+++ src/flash/non_cfi.c (working copy)
@@ -140,7 +140,10 @@
/* SST 39VF* do not support DQ5 status polling - this currently is
only supported by the host algorithm, not by the target code using
- the work area. */
+ the work area.
+ Only true for 8-bit and 32-bit wide memories. 16-bit wide memories
+ without DQ5 status polling are supported by the target code.
+*/
{
.mfr = CFI_MFR_SST,
.id = 0x2782,/* SST39xF160 */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add LPC1700 suport
--- Spencer Oliver s...@spen-soft.co.uk schrieb am Mi, 12.8.2009: Von: Spencer Oliver s...@spen-soft.co.uk Betreff: Re: [Openocd-development] [PATCH] Add LPC1700 suport An: 'Audrius Urmanavičius' didele.d...@gmail.com, 'openocd-devel' openocd-development@lists.berlios.de Datum: Mittwoch, 12. August 2009, 21:13 Hello List, Finally my MCB1760 dev board from Keil arrived and I programmed the support of LPC1768 with excitement. Attached is a patch against trunk of R2578. LPC1700 flash support is made as an extension of LPC2000 driver with several tweaks. Also created tcl config files for Keil MCB1760 board and LPC1768 target and updated openocd.texi to reflect changes to lpc2000 driver. Comments and criticisms are welcome. Looks good thanks, Can someone test this does not break the other lpc variants, then i will commit. Cheers Spen Hi Spen, I've just completed tests on LPC2478 (variant v2) and LPC2194 (variant v1). Everything works fine. As expected. it's working now on an LPC1768. The patch also fixes the handling of return values, and therefore the part_id sub-command is now working. Thanks Audrius! Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
