Re: [Openocd-development] Getting rid of default jtag clock rate
1MHz is just as bad as as default as 30MHz. It may work in more cases, but it is still broken in some. As I said before the 1Mhz startup frequency could be 10kHz. The important is not the value of the startup frequency, the important is to know we have a startup frequency !!! IMHO, there are two possibilities: - we find a method to auto-configure a default that works in *every* case That's the best to do at the end. - or we require a configuration value that works (that may be chip- or board-specific). Will be never good. A JTAG frequency is not only board specific, but wire (cable length) dependent, buffer dependend, dongle dependent Too many parameters !!! Having a default that works most of the time, but causes strange effects in some cases, is really bad useability. The question is what is 'most of time' 80% 90% 99% Fixing at a default 10KHz frequency will help user to auto-detect their JTAG chain ... and this is REALLY ever a GOOD thing to know the JTAG chain is auto-detected - my JTAG Chain is working, the JTAG transport layer is working, user are already happy ;-) Next, is to find the max. safe frequency :-) / THE SAFE CORRECT ROBUST frequency can never be known as static ! A // good JTAG software has to find this frequency by itself // (auto-detecting the max safe JTAG frequency );-) /Then how do you propose to implement such an auto-detection? Work on 10KHz startup frequency. READ the TAPID_old (the first TAP ID is enough) READ the TAPID_new (the first TAP ID is enough) WHILE TAPID_old = TAPID_new old up/scale the frequency TAPID_old = TAPID_new; READ the TAPID_new (the first TAP ID is enough) DO max safe frequency is TAPID_old / The default frequency could be 10KHz instead 1MHZ ... /Until some new really-low-power chip comes along that starts at an even lower internal clock - this does not sound robust. I am almost sure at 10KHz it will be 99% robust - not enough ! Laurent Amontec JTAGkey-2 Hi-SPEED USB JTAG CABLE http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
All device vendors should provide BSDL files for their devices which specify the maximum TCK speed the device can support. This can be used to create an auto-configuration that is fairly easy to use and robust. An example of this is the Xilinx programming tools. They do an initial shift at a low speed to find the JTAG ID's of each device. Once the device IDs are found a search is done against the BSDL files to find a matching description. Once that is complete the lowest maximum JTAG speed is used as an initial configuration based on the BSDL information. As an added benefit the JTAG instruction lengths are also defined in the BSDL so it does not need to be configured manually. If you see failures then you have the option of manually lowering the maximum JTAG frequency which overrides the BSDL files. -Karl BSDL give some informations as max JTAG frequency. The bad things are : - not all devices come with BSDL (in general the device not supporting the boundary scan, do not provide BSDL files - low cost LPC parts ...) - Amontec has found that the frequency notified in the BSDL file is not really the maximum frequency but sometimes absolute max frequency - 50%! The BSDL are not really a good thing for the major work of openocd user doing on-chip debug - and not on-board debug (boundary scan) Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail
The patch doesn't actually do anything other than add propagation of error, which needs to be in place at some point down the line. It's basically a big no-op patch so that the next patch that *does* something will be that much smaller. Your patch seems more orthogonal to this one. -- Ø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] jtag: getting the JTAG speed can fail
-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
Sent: Monday, December 06, 2010 10:30 PM
To: openocd-development@lists.berlios.de
Subject: [Openocd-development] [PATCH] jtag: getting the JTAG speed can
fail
If the JTAG speed has not been set, then it has no defined value, add code to
propagate the error.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/jtag/core.c | 27 +--
src/jtag/drivers/amt_jtagaccel.c | 19 ---
src/jtag/drivers/ft2232.c|6 +-
src/jtag/drivers/gw16012.c |6 +-
src/jtag/drivers/jlink.c |6 +-
src/jtag/drivers/parport.c |8 ++--
src/jtag/drivers/presto.c|6 +-
src/jtag/drivers/rlink.c |6 +-
src/jtag/drivers/usb_blaster.c |6 +-
src/jtag/jtag.h |2 +-
src/jtag/zy1000/zy1000.c |6 +-
11 files changed, 71 insertions(+), 27 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c index c1b64bb..ceb89b9 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -1384,9 +1384,13 @@ int adapter_init(struct command_context
*cmd_ctx)
int requested_khz = jtag_get_speed_khz();
int actual_khz = requested_khz;
- int retval = jtag_get_speed_readable(actual_khz);
+ int jtag_speed_t;
+ int retval = jtag_get_speed(jtag_speed_t);
+ if (retval != ERROR_OK)
+ return retval;
+ retval = jtag_get_speed_readable(actual_khz);
if (ERROR_OK != retval)
- LOG_INFO(adapter-specific clock speed value %d,
jtag_get_speed());
+ LOG_INFO(adapter-specific clock speed value %d,
jtag_speed_t);
else if (actual_khz)
{
/* Adaptive clocking -- JTAG-specific */ @@ -1632,30
+1636,33 @@ int jtag_config_rclk(unsigned fallback_speed_khz)
return (ERROR_OK != retval) ? retval : jtag_set_speed(speed); }
-int jtag_get_speed(void)
+int jtag_get_speed(int *speed)
{
- int speed = 0; /* avoid -O3 warning */
switch(clock_mode)
{
case CLOCK_MODE_SPEED:
- speed = jtag_speed;
+ *speed = jtag_speed;
break;
case CLOCK_MODE_KHZ:
- adapter_khz_to_speed(jtag_get_speed_khz(),
speed);
+ adapter_khz_to_speed(jtag_get_speed_khz(),
speed);
break;
case CLOCK_MODE_RCLK:
- jtag_rclk_to_speed(rclk_fallback_speed_khz,
speed);
+ jtag_rclk_to_speed(rclk_fallback_speed_khz,
speed);
break;
default:
LOG_ERROR(BUG: unknown jtag clock mode);
- break;
+ return ERROR_FAIL;
}
- return speed;
+ return ERROR_OK;
}
int jtag_get_speed_readable(int *khz)
{
- return jtag ? jtag-speed_div(jtag_get_speed(), khz) : ERROR_OK;
+ int jtag_speed_t;
+ int retval = jtag_get_speed(jtag_speed_t);
+ if (retval != ERROR_OK)
+ return retval;
+ return jtag ? jtag-speed_div(jtag_speed_t, khz) : ERROR_OK;
}
void jtag_set_verify(bool enable)
diff --git a/src/jtag/drivers/amt_jtagaccel.c
b/src/jtag/drivers/amt_jtagaccel.c
index fca8cfe..6d77410 100644
--- a/src/jtag/drivers/amt_jtagaccel.c
+++ b/src/jtag/drivers/amt_jtagaccel.c
@@ -191,7 +191,8 @@ static void amt_jtagaccel_state_move(void)
aw_scan_tms_5 = 0x40 | (tms_scan[0] 0x1f);
AMT_AW(aw_scan_tms_5);
- int jtag_speed = jtag_get_speed();
+ int retval = jtag_get_speed(jtag_speed);
+ assert(retval == ERROR_OK);
if (jtag_speed 3 || rtck_enabled)
amt_wait_scan_busy();
@@ -249,7 +250,9 @@ static void amt_jtagaccel_scan(bool ir_scan, enum
scan_type type, uint8_t *buffe
uint8_t dr_tdo;
uint8_t aw_tms_scan;
uint8_t tms_scan[2];
- int jtag_speed = jtag_get_speed();
+ int jtag_speed_t;
+ int retval = jtag_get_speed(jtag_speed_t);
+ assert(retval == ERROR_OK);
if (ir_scan)
amt_jtagaccel_end_state(TAP_IRSHIFT);
@@ -267,7 +270,7 @@ static void amt_jtagaccel_scan(bool ir_scan, enum
scan_type type, uint8_t *buffe
dw_tdi_scan = buf_get_u32(buffer, bit_count, (scan_size - 1)
% 8) 0xff;
AMT_DW(dw_tdi_scan);
- if (jtag_speed 3 || rtck_enabled)
+ if (jtag_speed_t 3 || rtck_enabled)
amt_wait_scan_busy();
if ((type == SCAN_IN) || (type == SCAN_IO)) @@ -285,7
+288,7 @@ static void amt_jtagaccel_scan(bool ir_scan, enum scan_type
type, uint8_t *buffe
{
dw_tdi_scan = buf_get_u32(buffer, bit_count, 8) 0xff;
[Openocd-development] How to reflash OMAP35x on a beagleboard.
Hi. I'm interesting in reading into a PC and then re-flashing the OMAP3530 POP NAND on a beagleboard rev C3. Can somebody help me with is the correct procedure? I am a little wary of ruining the board, and the search I did on the web so far was less than conclusive on the matter. I saw somewhat similar examples using openocd commands. But I don't see how they tell openocd to init the debug chain (call the omap3_deg_init.cfg first) I would welcome any help on this matter, Gabi Voiculescu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] The patch doesn't actually do anything other than add propagation of error, which needs to be in place at some point down the line. It's basically a big no-op patch so that the next patch that *does* something will be that much smaller. The error is propogated to the point that openocd exits with the error message. So, if I have not missunderstand something, I think the desired end effect is already reached. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problems stepping in GDB on the luminary lm3s6965.
Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and I've noticed some major problems with stepping in GDB. If it's of any help, I am using the Codesourcery arm-2009q3 toolchain. I'd appreciate any help. Ian Lambert Every time I try to step one line of code or to step into a function, I end up breaking in an ISR. Has anyone experienced similar problems? (I've attached my configuration for the perusal of anyone interested) source [find interface/olimex-jtag-tiny.cfg] telnet_port gdb_port tcl_port #Target #source [find local_lm3s6965.cfg] source [find target/lm3s6965.cfg] ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.
On Fri, Dec 3, 2010 at 11:27 PM, Ian Lambert ilamb...@breakawaysystems.com wrote: Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and I've noticed some major problems with stepping in GDB. If it's of any help, I am using the Codesourcery arm-2009q3 toolchain. I do not think that this has any influence on the issue. Every time I try to step one line of code or to step into a function, I end up breaking in an ISR. This is a bit strange, that every time you have same erroneous behavior. Would suggest to a (buggy ?) feature. Has anyone experienced similar problems? Yes, me. Try this : 1) Try using hardware breakpoints (put HW break on next instruction and continue, delete it, put on next, and so on). This should work even with caches turned on. 2) Turn off the caches, most of all D$ and try then. Hack around FreeRTOS start-up not to turn on caches. Try software breakpoints. Stepping uses SW breakpoint instruction, i.e. it substitutes actual code on this address with bkpt assembly instruction. If it is not written to the memory but is left hanging in the cache you can have problems. If this works (HW breaks with caches and stepping without caches), then OpenOCD wrongly handles caches for your CPU/board. Look around mailing lists for my previous posts about ARM946E and the way that I solved it (patch contributed). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Spen, I'm happy that i'm not the only one !!! Is it possible to send or put somewhere a windows version that works ? I have never compiled openocd so, if you can provide the binary file i'll be happy. If not I can try to compiled it too. Regards Jonathan Spencer Oliver wrote: On 06/12/2010 14:42, Jonathan dumaresq wrote: Have you fond some time to test this ? I have run a quick test and it fails for me also. As a quick test i commented out block writes (cfi_write_words) and it works as expected - albeit even slower. Also found this patch where they have disabled buffer writes for the M29W128. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif f;h=504a3e72208fc6a65924426ff5693982590bccdc Investigating there seems to be stack corruption within openocd when using block writes - the timeout param of cfi_spansion_wait_status_busy gets clobbered somewhere. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
On 06/12/2010 14:42, Jonathan dumaresq wrote: Have you fond some time to test this ? I have run a quick test and it fails for me also. As a quick test i commented out block writes (cfi_write_words) and it works as expected - albeit even slower. Also found this patch where they have disabled buffer writes for the M29W128. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=504a3e72208fc6a65924426ff5693982590bccdc Investigating there seems to be stack corruption within openocd when using block writes - the timeout param of cfi_spansion_wait_status_busy gets clobbered somewhere. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Bug in core.c::jtag_unregister_event_callback()
Hi,
I believe I've found a bug or two in jtag_unregister_event_callback().
273
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l273
int jtag_register_event_callback(jtag_event_handler_t callback, void *priv)
274
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l274
{
...
311
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l311
next = ((*callbacks_p)-next);
...
316
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l316
if ((*callbacks_p)-callback == callback)
317
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l317
{
318
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l318
free(*callbacks_p);
319
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l319
*callbacks_p = *next;
320
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l320
}
The assignment after the free() call is accessing the callback structure
that has just been freed. Also, the assignment on line 319 doesn't
account for the next increment in the for statement.
307
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l307
for (callbacks_p = jtag_event_callbacks;
308
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l308
*callbacks_p != NULL;
309
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/core.c;h=c1b64bba41b040ae8bdbea7d3dde302cdea6ffa5;hb=HEAD#l309
callbacks_p = next)
I have fixed and verified on my build but am unfamiliar with submission
procedures. I'm happy to contribute with a little guidance.
Regards,
Paul
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.
On Tue, Dec 7, 2010 at 5:13 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-12-03 23:27, Ian Lambert wrote: Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and I've noticed some major problems with stepping in GDB. If it's of any help, I am using the Codesourcery arm-2009q3 toolchain. I'd appreciate any help. Ian Lambert Every time I try to step one line of code or to step into a function, I end up breaking in an ISR. Has anyone experienced similar problems? (I've attached my configuration for the perusal of anyone interested) IMO this is perfectly normal and I experience similar behaviour on STM32, especially with timers or UART. When the core is halted, some peripherals actually work normally (timers) or almost normally(UART), so for example a timer match interrupt is reported, new chars in the UART are waiting etc. On STM32 timers (and some peripherals) can be stopped in halt mode (using DBGMCU registers) and that's the only solution... IMO it's almost impossible to debug code that heavily uses such interrupts (when the peripherals are running when the core is halted). Only breakpoints solve this issue partially. Then I guess you can mask the INTs to check if this is the case, or error in OpenOCD. If OpenOCD is working correctly (most probably), maybe by masking one by one line you can localize INT that is giving you headache... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Bug in core.c::jtag_unregister_event_callback()
Looks like bugs indeed... How did you come across them? I have fixed and verified on my build but am unfamiliar with submission procedures. I'm happy to contribute with a little guidance. 1. Get the latest version from git 2. checkout the master branch git checkout origin/master 2. Modify the files that need modifying 3. Commit changes: git add . git commit --author=Paul Richards paulr...@gmail.com 3b. if you need to add some more changes to the same commit, you can amend the commit git add . git commit --amend 4. create patch and post file to list git format-patch HEAD^ -- Ø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/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] Getting rid of default jtag clock rate
On 12/07/2010 10:39 AM, Laurent Gauch wrote: Will be never good. A JTAG frequency is not only board specific, but wire (cable length) dependent, buffer dependend, dongle dependent Too many parameters !!! Chip, dongle, board configs could supply max values (and OpenOCD would have to select the lowest of them) - however, the user will have to select the frequency he wants to use, the config values can only limit the user's choice in case he sets a frequency that is too hight for some component. Having a default that works most of the time, but causes strange effects in some cases, is really bad useability. The question is what is 'most of time' 80% 90% 99% Fixing at a default 10KHz frequency will help user to auto-detect their JTAG chain ... and this is REALLY ever a GOOD thing to know the JTAG chain is auto-detected - my JTAG Chain is working, the JTAG transport layer is working, user are already happy ;-) I am not sure 10kHz is good. On a core where the max. JTAG frequency is cpu_clk / 6, with a 32.768kHz crystal, 10kHz is already too high. /Then how do you propose to implement such an auto-detection? Work on 10KHz startup frequency. READ the TAPID_old (the first TAP ID is enough) READ the TAPID_new (the first TAP ID is enough) WHILE TAPID_old = TAPID_new old up/scale the frequency TAPID_old = TAPID_new; READ the TAPID_new (the first TAP ID is enough) DO max safe frequency is TAPID_old Probably not. On cores where the JTAG frequency is limited to some fraction of the core frequency due to internal synchronization, you may get a broad area where probing works some of the times, so you would choose a frequency that fails from time to time. cu Michael ___ 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] Problems stepping in GDB on the luminary lm3s6965.
you mentioned using an RTOS. Stepping on Cortex-M works poorly with a common OS feature: Use of the WFI (or WFE) instruction stops the core so that you can't get at it using JTAG.(It saves power, but in a way that complicates debugging.) My baby Cortex-M RTOS has a build/coonfig option for whether it uses WFI/WFE or not, otherwise it would have been impossible to debug/step or even just halt the software to see where it got to. ___ 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] Bug in core.c::jtag_unregister_event_callback()
Paul Richards wrote:
307 for (callbacks_p = jtag_event_callbacks;
308 *callbacks_p != NULL;
309 callbacks_p = next)
..
311 next = ((*callbacks_p)-next);
...
316 if ((*callbacks_p)-callback == callback)
317 {
318 free(*callbacks_p);
319 *callbacks_p = *next;
320 }
**next seems excessive. *next would work..
The assignment after the free() call is accessing the callback
structure that has just been freed.
..and there would actually not be a problem then. Hopefully easy fix.
I guess someone wanted to use a lot of pointers. For modifying lists
I strongly prefer keeping a pointer direct to the previous entry,
rather than a **.
Also, the assignment on line 319 doesn't account for the next
increment in the for statement.
Should it? I don't think the following callback should be skipped
just because the current one is removed.
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail
Øyvind Harboe wrote: If the JTAG speed has not been set, then it has no defined value, add code to propagate the error. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com .. +++ b/src/jtag/core.c @@ -1384,9 +1384,13 @@ int adapter_init(struct command_context *cmd_ctx) int requested_khz = jtag_get_speed_khz(); int actual_khz = requested_khz; - int retval = jtag_get_speed_readable(actual_khz); + int jtag_speed_t; I'm not very happy with _t at the end of a variable name; that's usually for types. + int retval = jtag_get_speed(jtag_speed_t); + if (retval != ERROR_OK) + return retval; + retval = jtag_get_speed_readable(actual_khz); if (ERROR_OK != retval) - LOG_INFO(adapter-specific clock speed value %d, jtag_get_speed()); + LOG_INFO(adapter-specific clock speed value %d, jtag_speed_t); Why not also print actual_khz here? Otherwise: 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] Bug in core.c::jtag_unregister_event_callback()
Hi Peter, I just saw your mail after submitting a patch. I kept the double pointer usage for consistency but simplified the logic. On 2010/12/08 15:35, Peter Stuge wrote: Should it? I don't think the following callback should be skipped just because the current one is removed. I believe you're correct, must have been getting late. My patch doesn't advance the pointer and iterates once again with the updated value. Regards, Paul ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail
Merged(+ some changes, see below). On Wed, Dec 8, 2010 at 7:55 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: If the JTAG speed has not been set, then it has no defined value, add code to propagate the error. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com .. +++ b/src/jtag/core.c @@ -1384,9 +1384,13 @@ int adapter_init(struct command_context *cmd_ctx) int requested_khz = jtag_get_speed_khz(); int actual_khz = requested_khz; - int retval = jtag_get_speed_readable(actual_khz); + int jtag_speed_t; I'm not very happy with _t at the end of a variable name; that's usually for types. I've switched to jtag_speed_var. + int retval = jtag_get_speed(jtag_speed_t); + if (retval != ERROR_OK) + return retval; + retval = jtag_get_speed_readable(actual_khz); if (ERROR_OK != retval) - LOG_INFO(adapter-specific clock speed value %d, jtag_get_speed()); + LOG_INFO(adapter-specific clock speed value %d, jtag_speed_t); Why not also print actual_khz here? Perhaps, but that would be another patch. -- Ø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
