Re: [Openocd-development] Serial Wire Debug experiment
The main motivation for choosing it over jtag is probably using less pins, as simple as that. There's no gain in debug functionality. Well, if you're not counting the serial wire viewer, which I'm not sure is a part of swd. But I believe it's often using a pin otherwise allocated the jtag interface. 2008/11/25 Øyvind Harboe [EMAIL PROTECTED] What, in your opinion, is the advantage of the SWI? Does it have some genuine merit over JTAG or is it just different? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 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] fix ancient bug SEGFAULT in irscan
On Tue, May 12, 2009 at 8:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I couldn't believe my eyes when I saw what the bug was. irscan has *always* been broken. I checked as far back as svn 345. A couple of possible explanations: - irscan has never really been used - events have somehow conspired to hide the bugs - I'm missing something Known problems in irscan: - does not support 32 bit fields(?). This maybe a problem for omap devices(?) - why not reuse the new drscan code? I may be stupid and/or tired, but what does this mean? int num_fields= num_fields; --Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] thumb2 disassembly for Load halfword
I noticed there are a few checks for (rt == 0xf) even though that case is handled with an early return at the top of the function. Maybe those checks should just go? /Andreas Index: src/target/arm_disassembler.c === --- src/target/arm_disassembler.c (revision 2561) +++ src/target/arm_disassembler.c (working copy) @@ -3523,8 +3523,6 @@ if ((opcode (1 23)) == 0) { if (rn == 0xf) { ldrh_literal: - if (rt == 0xf) - return ERROR_INVALID_ARGUMENTS; immed = opcode 0xfff; address = thumb_alignpc4(address); if (opcode (1 23)) @@ -3535,8 +3533,6 @@ sign, rt, address); return ERROR_OK; } - if (rt == 0xf) - return ERROR_INVALID_ARGUMENTS; if (op2 == 0) { int rm = opcode 0xf; @@ -3574,12 +3570,11 @@ } else { if (rn == 0xf) goto ldrh_literal; - if (rt != 0x0f) { - immed = opcode 0xfff; - sprintf(cp, LDR%sH.W\tr%d, [r%d, #%d]\t; %#6.6x, - sign, rt, rn, immed, immed); - return ERROR_OK; - } + + immed = opcode 0xfff; + sprintf(cp, LDR%sH.W\tr%d, [r%d, #%d]\t; %#6.6x, + sign, rt, rn, immed, immed); + return ERROR_OK; } return ERROR_INVALID_ARGUMENTS; ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Slowly moving from 8 to 32 bit words in jtag_add_xxx API
On Thu, Nov 19, 2009 at 1:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Was this for the list? Yeah it was, that Reply-to-all button seems to be hard to find sometimes. On Thu, Nov 19, 2009 at 12:34 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Nov 18, 2009 at 9:40 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Wed, Nov 18, 2009 at 9:38 AM, Laurent Gauch laurent.ga...@amontec.com wrote: I'm pondering how we could gently in a series of non-breaking patches prepare the ground for switching from 8 to 32 bit words in the jtag_add_xxx API. The attached patch gets rid of buf_set_u32() when setting the value of a byte. This achieves two things: the code is less obtuse and it is more evident how we could introduce a new type that is *currently* uint8_t and later on could be increased to uint32_t or wider, for the out_value/in_value bit vectors. Comments? Protests? JTAG serial link itself has a notion of bits and not bytes nor dwords ... I do not understand what is the advantage to work on 32bit buffers instead 8bit buffers for out_value and in_value. Why the code will be less obtuse use 32bit buffer instead 8 bit buffers ? Look at all the buf_set_u32()'s sprinkled around the code. They are essentially unnecessary. The drivers probably wouldn't change. I don't see the point in deciding on a specific width of the storage unit. The JTAG layer (should?) handle bit strings of arbitrary lenghts, so why not abstract away how the bit strings are stored internally? Some time ago someone (David?) suggested we borrow/build on the bitmap facility from Linux. I remember someone had strong opinions against it, don't remember why. I myself think it's a good idea to migrate towards a similar solution rather than switching from one arbitrary, fixed width to another. As a side note, the Linux' bitmap implementation actually uses 'unsigned long' as storage, so if using 32 bits is your design requirement you'll get it on at least some platforms. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/3] improve default script search path
This series improves the default script search path to include $HOME/.openocd. It also updates the search path on Windows to match what appears to be the result of a standard 'configure make make install' in one particular MSYS environment. Other environments have not been tested, but the current path seems wrong regardless. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/3] update win32 script search path
The default script search path on Windows seems to be out of date with the current layout, causing the standard scripts not to be found after a conventional './configure make make install' under msys/MinGW. The same should hold true for cygwin native builds although not verified. Update the search path to ../share/openocd/scripts instead of ../lib/openocd, relative the openocd executable. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/options.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/helper/options.c b/src/helper/options.c index 874196e..5792e11 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -74,21 +74,21 @@ static void add_default_dirs(void) add_script_search_dir(strExePath); } /* -* Add support for the default (as of 20080121) layout when -* using autotools and cygwin to build native MinGW binary. +* Add support for the default (as of 20091118) layout when +* using autotools and cygwin/MinGW to build native binary. * Path separator is converted to UNIX style so that MinGW is * pleased. * * bin/openocd.exe -* lib/openocd/event/at91eb40a_reset.cfg -* lib/openocd/target/at91eb40a.cfg +* share/openocd/scripts/interface/dummy.cfg +* share/openocd/scripts/target/at91eb40a.cfg */ { char strExePath [MAX_PATH]; char *p; GetModuleFileName (NULL, strExePath, MAX_PATH); *strrchr(strExePath, '\\') = 0; - strcat(strExePath, /../lib/PACKAGE); + strcat(strExePath, /../share/PACKAGE/scripts); for (p = strExePath; *p; p++) { if (*p == '\\') *p = '/'; -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
Add $HOME/.openocd as the first default script search directory, allowing the user to override the standard scripts. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/options.c | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/src/helper/options.c b/src/helper/options.c index 5792e11..2187ff7 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -29,6 +29,7 @@ #include server.h #include getopt.h +#include stdlib.h static int help_flag, version_flag; @@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context *context, const char* li static void add_default_dirs(void) { +#ifndef MAX_PATH +#define MAX_PATH 1024 +#endif + #ifdef _WIN32 /* Add the parent of the directory where openocd.exe resides to the * config script search path. @@ -101,7 +106,16 @@ static void add_default_dirs(void) * listed last in the built-in search order, so the user can * override these scripts with site-specific customizations. */ - /// @todo Implement @c add_script_search_dir(${HOME}/.openocd). + + char *home = getenv(HOME); + + if (home) { + char path[MAX_PATH]; + + if (snprintf(path, MAX_PATH, %s/.openocd, home) MAX_PATH) + add_script_search_dir(path); + } + add_script_search_dir(PKGDATADIR /site); add_script_search_dir(PKGDATADIR /scripts); #endif -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] show script search dirs in debug log
Add this to ease debugging why the standard scripts aren't found on the default script search path in some build/install enviroments. Especially on Windows it's not straight forward where openocd actually looks for the scripts. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/configuration.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/helper/configuration.c b/src/helper/configuration.c index 74bcc9b..2ea5da4 100644 --- a/src/helper/configuration.c +++ b/src/helper/configuration.c @@ -41,6 +41,8 @@ void add_script_search_dir (const char *dir) script_search_dirs[num_script_dirs-1] = strdup(dir); script_search_dirs[num_script_dirs] = NULL; + + LOG_DEBUG(adding %s, dir); } void add_config_command (const char *cfg) -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote: On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote: Add $HOME/.openocd as the first default script search directory, allowing the user to override the standard scripts. Comments are in-line and at the end. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/options.c | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/src/helper/options.c b/src/helper/options.c index 5792e11..2187ff7 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -29,6 +29,7 @@ #include server.h #include getopt.h +#include stdlib.h static int help_flag, version_flag; @@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context *context, const char* li static void add_default_dirs(void) { +#ifndef MAX_PATH +#define MAX_PATH 1024 +#endif + PATH_MAX should be defined and available (in limits.h). Use it. I did some research on the matter, and it seems that PATH_MAX is only defined if there actually is a limit, which apparently is not always the case. Even if defined, the value is often arbitrary or unsuitably large. So the #ifndef would have to stay, albeit with another name. Since MAX_PATH was already used in the WIN32 specific section, I decided to reuse that to avoid confusion with two different names. Of course, should PATH_MAX be equally valid on WIN32 even though it's an extension, that section could be changed to use it too if available. I can verify if that's the case earliest on Monday, since I have no Windows machine at home, and submit a clean-up patch after that. In the meantime, this should work perfectly, even if users with a 1K long home directory might be disappointed. :) #ifdef _WIN32 /* Add the parent of the directory where openocd.exe resides to the * config script search path. @@ -101,7 +106,16 @@ static void add_default_dirs(void) * listed last in the built-in search order, so the user can * override these scripts with site-specific customizations. */ - /// @todo Implement @c add_script_search_dir(${HOME}/.openocd). As the one who added that @todo item, thanks for doing this! :) + + char *home = getenv(HOME); + + if (home) { + char path[MAX_PATH]; + + if (snprintf(path, MAX_PATH, %s/.openocd, home) MAX_PATH) + add_script_search_dir(path); + } + add_script_search_dir(PKGDATADIR /site); add_script_search_dir(PKGDATADIR /scripts); #endif As others note, this deserves mention in doc/openocd.texi and NEWS. I'll look into a patch for those soon-ish. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote: PATH_MAX should be defined and available (in limits.h). Use it. Why not just allocate dynamically and avoid the problem at the root? That sounds like the best solution, I'll prepare an updated patch. Ehm... The question is... how do i do it?? This was more or less my first git experience and I found it rather easy to develop and commit this on a separate branch, prepare the patch series with git-format-patch and even send it with git-send-email. But when there's feedback on one of the patches, like in this case, how do I revise that patch and send an updated version? I find myself in the dark here... I've read some tutorials, but most speak in rather general terms. This ought to be a very common scenario. Step-by-step guide, anyone? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote: Checkout your branch and run 'git rebase master'. That will update your branch against the current master. Then, do the same thing with '-i'. Select the patches to change and mark them with 'e', change the files, add them and --amend the comment, then --continue the rebase. Rinse and repeat for all marked files. Great, that was easy, thanks! Here's an updated patch, this time using C99 variable length arrays. I'm using the unbounded string functions here, guessing we can trust getenv() to return a piece of memory that won't change on the fly. Btw, is it suitable to attach an updated patch as an attachment like this? I thought git-send-email was fancy, but I hardly think it can figure out to send the new patch as a reply in the old thread? /Andreas From 4fb41a4855e58448070f5d4e3434878aa1c8c72f Mon Sep 17 00:00:00 2001 From: Andreas Fritiofson andreas.fritiof...@gmail.com Date: Thu, 19 Nov 2009 23:58:15 +0100 Subject: [PATCH 2/2] support for scripts in $HOME/.openocd Add $HOME/.openocd as the first default script search directory, allowing the user to override the standard scripts. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/options.c | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/src/helper/options.c b/src/helper/options.c index 5792e11..84e391b 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -101,7 +101,18 @@ static void add_default_dirs(void) * listed last in the built-in search order, so the user can * override these scripts with site-specific customizations. */ - /// @todo Implement @c add_script_search_dir(${HOME}/.openocd). + + const char *home = getenv(HOME); + const char *suffix = /.openocd; + + if (home) { + char path[strlen(home) + strlen(suffix) + 1]; + + strcpy(path, home); + strcat(path, suffix); + add_script_search_dir(path); + } + add_script_search_dir(PKGDATADIR /site); add_script_search_dir(PKGDATADIR /scripts); #endif -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] support for scripts in $HOME/.openocd
Add $HOME/.openocd as the first default script search directory, allowing the user to override the standard scripts. Update the user guide with information on where OpenOCD expects to find configuration files and scripts. Also fixed some minor formatting issues. Add entry to NEWS as well. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- NEWS |1 + doc/openocd.texi | 22 ++ src/helper/options.c | 13 - 3 files changed, 27 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 1a024e4..0dcc4bc 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,7 @@ Flash Layer: Board, Target, and Interface Configuration Scripts: ARM9 - ETM and ETB hookup for iMX2* targets + Add $HOME/.openocd to the search path. Documentation: Build and Release: diff --git a/doc/openocd.texi b/doc/openocd.texi index 9659e92..f895cc3 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -483,14 +483,24 @@ bash$ openocd --help --pipe | -p use pipes when talking to gdb @end verbatim -By default OpenOCD reads the file configuration file @file{openocd.cfg} -in the current directory. To specify a different (or multiple) -configuration file, you can use the ``-f'' option. For example: +By default OpenOCD reads the configuration file @file{openocd.cfg}. +To specify a different (or multiple) +configuration file, you can use the @option{-f} option. For example: @example openocd -f config1.cfg -f config2.cfg -f config3.cfg @end example +Configuration files and scripts are searched for in +...@enumerate +...@item the current directory, +...@item any search dir specified on the command line using the @option{-s} option, +...@item @file{$HOME/.openocd} (not on Windows), +...@item the site wide script library @file{$pkgdatadir/site} and +...@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}. +...@end enumerate +The first found file with a matching file name will be used. + OpenOCD starts by processing the configuration commands provided on the command line or in @file{openocd.cfg}. @xref{Configuration Stage}. @@ -507,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands issued through those channels. If you are having problems, you can enable internal debug messages via -the ``-d'' option. +the @option{-d} option. Also it is possible to interleave JIM-Tcl commands w/config scripts using the @option{-c} command line switch. @@ -523,10 +533,6 @@ setting from within a telnet or gdb session using @command{debug_level You can redirect all output from the daemon to a file using the @option{-l logfile} switch. -Search paths for config/script files can be added to OpenOCD by using -the @option{-s search} switch. The current directory and the OpenOCD -target library is in the search path by default. - For details on the @option{-p} option. @xref{Connecting to GDB}. Note! OpenOCD will launch the GDB telnet server even if it can not diff --git a/src/helper/options.c b/src/helper/options.c index 5792e11..438fb94 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -101,7 +101,18 @@ static void add_default_dirs(void) * listed last in the built-in search order, so the user can * override these scripts with site-specific customizations. */ - /// @todo Implement @c add_script_search_dir(${HOME}/.openocd). + + const char *home = getenv(HOME); + + if (home) { + const char *suffix = /.openocd; + char path[strlen(home) + strlen(suffix) + 1]; + + strcpy(path, home); + strcat(path, suffix); + add_script_search_dir(path); + } + add_script_search_dir(PKGDATADIR /site); add_script_search_dir(PKGDATADIR /scripts); #endif -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Document build broken when src != build
On Sun, Nov 22, 2009 at 10:17 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I can no longer build docs when src != build. I believe this is trivially reproducible and that the breakage is relatively recent(a month or so). Or... perhaps I'm missing some tool on my laptop? make docs make doxygen = both fail make doxygen/latex/refman.pdf make[1]: Entering directory `/home/oyvind/workspace/build' make[1]: *** No rule to make target `doxygen/latex/refman.pdf'. Stop. I saw this error warning fly by doxygen Doxyfile 21 | perl ../zy1000/openocd/tools/logger.pl doxygen.log Warning: tag INPUT: input source `../zy1000/openocd/config.h' does not exist Warning: source ../zy1000/openocd/config.h is not a readable file or directory... skipping. Same problem here, automatic git bisect revealed 0091e59d2a18c293fd952a9d707e609afdd6b17f to be the culprit. The warning message is unrelated. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? Yes. Other programmers will copy and paste your code. We've got the code clean of dynamic arrays on the stack and we should keep it that way. Since C99 has been accepted as the project's language standard, I think it is reasonable to expect that valid language constructs that are still *not* acceptable by the project be clearly stated in the Style Guide. Likewise if being optimized for embedded hosts is a priority for the project as a whole. Rejecting even trivial patches on the grounds of previously unspoken goals does not encourage developers to contribute. With that said, I'll happily resign in this case. Actually, my first draft was using asprintf() but I rejected it for not being standard. Seeing there's an equivalent already in the code, I'll update the patch using that. However, alloc_vprintf() seems to have a rather cumbersome implementation. Is there a reason why it is looping, trying with increasingly larger allocations? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/3] support for scripts in $HOME/.openocd
Add $HOME/.openocd as the first default script search directory, allowing the user to override the standard scripts. Update the user guide with information on where OpenOCD expects to find configuration files and scripts. Also fixed some minor formatting issues. Add entry to NEWS as well. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- NEWS |1 + doc/openocd.texi | 22 ++ src/helper/options.c | 15 ++- 3 files changed, 29 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 1a024e4..0dcc4bc 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,7 @@ Flash Layer: Board, Target, and Interface Configuration Scripts: ARM9 - ETM and ETB hookup for iMX2* targets + Add $HOME/.openocd to the search path. Documentation: Build and Release: diff --git a/doc/openocd.texi b/doc/openocd.texi index cff7fc5..e94c9d0 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -483,14 +483,24 @@ bash$ openocd --help --pipe | -p use pipes when talking to gdb @end verbatim -By default OpenOCD reads the file configuration file @file{openocd.cfg} -in the current directory. To specify a different (or multiple) -configuration file, you can use the ``-f'' option. For example: +By default OpenOCD reads the configuration file @file{openocd.cfg}. +To specify a different (or multiple) +configuration file, you can use the @option{-f} option. For example: @example openocd -f config1.cfg -f config2.cfg -f config3.cfg @end example +Configuration files and scripts are searched for in +...@enumerate +...@item the current directory, +...@item any search dir specified on the command line using the @option{-s} option, +...@item @file{$HOME/.openocd} (not on Windows), +...@item the site wide script library @file{$pkgdatadir/site} and +...@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}. +...@end enumerate +The first found file with a matching file name will be used. + OpenOCD starts by processing the configuration commands provided on the command line or in @file{openocd.cfg}. @xref{Configuration Stage}. @@ -507,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands issued through those channels. If you are having problems, you can enable internal debug messages via -the ``-d'' option. +the @option{-d} option. Also it is possible to interleave JIM-Tcl commands w/config scripts using the @option{-c} command line switch. @@ -523,10 +533,6 @@ setting from within a telnet or gdb session using @command{debug_level You can redirect all output from the daemon to a file using the @option{-l logfile} switch. -Search paths for config/script files can be added to OpenOCD by using -the @option{-s search} switch. The current directory and the OpenOCD -target library is in the search path by default. - For details on the @option{-p} option. @xref{Connecting to GDB}. Note! OpenOCD will launch the GDB telnet server even if it can not diff --git a/src/helper/options.c b/src/helper/options.c index 5792e11..e036d61 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -101,7 +101,20 @@ static void add_default_dirs(void) * listed last in the built-in search order, so the user can * override these scripts with site-specific customizations. */ - /// @todo Implement @c add_script_search_dir(${HOME}/.openocd). + + const char *home = getenv(HOME); + + if (home) { + char *path; + + path = alloc_printf(%s/.openocd, home); + + if (path) { + add_script_search_dir(path); + free(path); + } + } + add_script_search_dir(PKGDATADIR /site); add_script_search_dir(PKGDATADIR /scripts); #endif -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] improve alloc_vprintf
The previous implementation was unnecessarily complex. Get rid of the loops, let vsnprintf() tell us directly how much storage we need and allocate that. A second pass writes the actual string. Also add a va_end() that was missing. This should be much faster for large strings and less wasteful for small ones. A quirk that has been retained is that some callers patch in a newline at the end of the returned string and depend on alloc_vprintf to allocate at least one byte extra. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/log.c | 43 --- 1 files changed, 16 insertions(+), 27 deletions(-) diff --git a/src/helper/log.c b/src/helper/log.c index caaed42..6869d2e 100644 --- a/src/helper/log.c +++ b/src/helper/log.c @@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv) /* return allocated string w/printf() result */ char *alloc_vprintf(const char *fmt, va_list ap) { - /* no buffer at the beginning, force realloc to do the job */ - char *string = NULL; - - /* start with buffer size suitable for typical messages */ - int size = 128; - - for (;;) - { - char *t = string; - va_list ap_copy; - int ret; - string = realloc(string, size); - if (string == NULL) - { - if (t != NULL) - free(t); - return NULL; - } + va_list ap_copy; + int len; + char *string; - va_copy(ap_copy, ap); + /* determine the length of the buffer needed */ + va_copy(ap_copy, ap); + len = vsnprintf(NULL, 0, fmt, ap_copy); + va_end(ap_copy); - ret = vsnprintf(string, size, fmt, ap_copy); - /* NB! The result of the vsnprintf() might be an *EMPTY* string! */ - if ((ret = 0) ((ret + 1) size)) - break; + /* allocate and make room for terminating zero. */ + /* FIXME: The old version always allocated at least one byte extra and +* other code depend on that. They should be probably be fixed, but for +* now reserve the extra byte. */ + string = malloc(len + 2); + if (string == NULL) + return NULL; - /* there was just enough or not enough space, allocate more in the next round */ - size *= 2; /* double the buffer size */ - } + /* do the real work */ + vsnprintf(string, len + 1, fmt, ap_copy); - /* the returned buffer is by principle guaranteed to be at least one character longer */ return string; } -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] improve alloc_vprintf
The previous implementation was unnecessarily complex. Get rid of the loops, let vsnprintf() tell us directly how much storage we need and allocate that. A second pass writes the actual string. Also add a va_end() that was missing. This should be much faster for large strings and less wasteful for small ones. A quirk that has been retained is that some callers patch in a newline at the end of the returned string and depend on alloc_vprintf to allocate at least one byte extra. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- This time without the copy/paste error. Thanks Zach for spotting it. --- src/helper/log.c | 43 --- 1 files changed, 16 insertions(+), 27 deletions(-) diff --git a/src/helper/log.c b/src/helper/log.c index caaed42..2dcf7bb 100644 --- a/src/helper/log.c +++ b/src/helper/log.c @@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv) /* return allocated string w/printf() result */ char *alloc_vprintf(const char *fmt, va_list ap) { - /* no buffer at the beginning, force realloc to do the job */ - char *string = NULL; - - /* start with buffer size suitable for typical messages */ - int size = 128; - - for (;;) - { - char *t = string; - va_list ap_copy; - int ret; - string = realloc(string, size); - if (string == NULL) - { - if (t != NULL) - free(t); - return NULL; - } + va_list ap_copy; + int len; + char *string; - va_copy(ap_copy, ap); + /* determine the length of the buffer needed */ + va_copy(ap_copy, ap); + len = vsnprintf(NULL, 0, fmt, ap_copy); + va_end(ap_copy); - ret = vsnprintf(string, size, fmt, ap_copy); - /* NB! The result of the vsnprintf() might be an *EMPTY* string! */ - if ((ret = 0) ((ret + 1) size)) - break; + /* allocate and make room for terminating zero. */ + /* FIXME: The old version always allocated at least one byte extra and +* other code depend on that. They should be probably be fixed, but for +* now reserve the extra byte. */ + string = malloc(len + 2); + if (string == NULL) + return NULL; - /* there was just enough or not enough space, allocate more in the next round */ - size *= 2; /* double the buffer size */ - } + /* do the real work */ + vsnprintf(string, len + 1, fmt, ap); - /* the returned buffer is by principle guaranteed to be at least one character longer */ return string; } -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this was added, it should not create any dependencies or do anything remotely exotic. How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then... Seriously... you've never had a Heisenbug either? Am I the only one that gets segfaults and doesn't _want_ to have to debug them? Really? Isn't running with core dumps enabled a far simpler method to catch those one-off crashes than keeping (and maintaining!) a bunch of code in-tree to do essentially the same, but less? It's less awkward than launching openocd within gdb, for sure. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this was added, it should not create any dependencies or do anything remotely exotic. How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then... Seriously... you've never had a Heisenbug either? Am I the only one that gets segfaults and doesn't _want_ to have to debug them? Really? Isn't running with core dumps enabled a far simpler method to catch those one-off crashes than keeping (and maintaining!) a bunch of code in-tree to do essentially the same, but less? It's less awkward than launching openocd within gdb, for sure. Again, core dumps are great -- when you have the presence of mind to set yourself up to produce them. It has been my impression (for some time) that most folks run in environments where that is disabled by default, so we are again talking about performing precognitive steps if you want to capture unpredictable bugs (while not producing unwanted core files). Something like this simple patch would fix that in most (linux) users' environments. At least on my ubuntu the hard limit is unlimited, probably on most other dists as well. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this was added, it should not create any dependencies or do anything remotely exotic. How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then... Seriously... you've never had a Heisenbug either? Am I the only one that gets segfaults and doesn't _want_ to have to debug them? Really? Isn't running with core dumps enabled a far simpler method to catch those one-off crashes than keeping (and maintaining!) a bunch of code in-tree to do essentially the same, but less? It's less awkward than launching openocd within gdb, for sure. Again, core dumps are great -- when you have the presence of mind to set yourself up to produce them. It has been my impression (for some time) that most folks run in environments where that is disabled by default, so we are again talking about performing precognitive steps if you want to capture unpredictable bugs (while not producing unwanted core files). Something like this simple patch would fix that in most (linux) users' environments. At least on my ubuntu the hard limit is unlimited, probably on most other dists as well. /Andreas D'oh... diff --git a/src/main.c b/src/main.c index a71977d..b580c8b 100644 --- a/src/main.c +++ b/src/main.c @@ -23,6 +23,7 @@ #include config.h #endif #include openocd.h +#include sys/resource.h /* This is the main entry for developer PC hosted OpenOCD. * @@ -35,5 +36,12 @@ int main(int argc, char *argv[]) { + struct rlimit rlim; + + if (getrlimit(RLIMIT_CORE, rlim) == 0) { + rlim.rlim_cur = rlim.rlim_max; + setrlimit(RLIMIT_CORE, rlim); + } + return openocd_main(argc, argv); } ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this was added, it should not create any dependencies or do anything remotely exotic. How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then... Seriously... you've never had a Heisenbug either? Am I the only one that gets segfaults and doesn't _want_ to have to debug them? Really? Isn't running with core dumps enabled a far simpler method to catch those one-off crashes than keeping (and maintaining!) a bunch of code in-tree to do essentially the same, but less? It's less awkward than launching openocd within gdb, for sure. Again, core dumps are great -- when you have the presence of mind to set yourself up to produce them. It has been my impression (for some time) that most folks run in environments where that is disabled by default, so we are again talking about performing precognitive steps if you want to capture unpredictable bugs (while not producing unwanted core files). Something like this simple patch would fix that in most (linux) users' environments. At least on my ubuntu the hard limit is unlimited, probably on most other dists as well. I like it, except I think it needs to be disabled in the default case. We will get complaints if OpenOCD produces core dumps without asking, so this precludes the possibility of turning it on by default. Our program needs to respect the fact that the user could have configured their environment to let the program dump its core, so it seems like bad policy to override that default without the user's explicit authority. I don't follow. If a user has no clue what a core file is but wants to report a crash, he'll be pleased to find that the file we request is already there, ready to submit in a bug report. If a user knows about core files and _wants_ them, he surely has them enabled anyway (ulimit -c unlimited). If that user _doesn't_ want any core files from openocd, he'll have set the hard limit to 0 (ulimit -c 0), in which case openocd cannot change that. Tough luck. The default policy, which the user may override, is don't dump core unless the process wants to. We could allow it to be turned on with OPENOCD_DUMPS_CORES set in the environment or via a script command (e.g. 'core dumps (on|off)'). This modified suggestion sounds like a reasonable feature to add, once more work has been done to manage portability. Right now, it's a rat's nest. Finally, I am not sure your suggestion would improve the assert() macro, as the last patch that I posted demonstrates. Does that macro produce core files with the stack trace at the point of assertion? Yes. Unless, of course, your mentioned patch is applied... :) It also dumps on some other signals (SIGILL, SIGFPE and SIGQUIT). The fact is that the most recent crash I had with OpenOCD (log_print_lf adding a newline beyond the end of the cheaply allocated string) wouldn't have been caught with your stack trace, since it did not SIGSEGV, it was aborted by a later free(). It would have dumped core though. Of course, your solution could have been trivially improved to catch SIGABRT as well. I still want my stack tracing, because I cannot tell the future. It's also the least invasive to the user experience, when compared to GDB or core dumps. I am not kidding when I say that I do not want to do _any_ extra post-processing steps. I fail to see how core files meet this added requirement any better than GDB, when my code nearly does To be fair, I added a small perl script to my series that runs addr2line to translate the existing traces that the code produces, but this still has the clear advantage of not needing to predict your crashes. What kind of post-processing steps do you mean and why don't you want them? Given an executable and its
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
Any comments on this? I had hoped to get this functional in 0.4 so I could drop the -s from the command line at work. Windows builders/packagers, does this look OK from your point of view or do you still install scripts in ../lib? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
It seems this never reached the list... So in conclusion, the (soon to be official?) windows packages from Freddie Chopin installs config files so they are found by the first default search path (in $installroot). In a unix-like environment, including cygwin/msys, the build system by default installs them in $installroot/share/openocd/scripts, not yet covered by any default search path when building for Windows. I take the silence to mean that nobody wants the files under $installroot/lib/openocd so that search path could go (or possibly kept as a third option). Any objections to merge this? Regards, Andreas 2010/1/16 Andreas Fritiofson andreas.fritiof...@gmail.com: 2010/1/15 freddie_cho...@op.pl: Użytkownik oyvind.har...@zylin.com napisał: I find it odd that none has. Personally I don't know what is the point of that patch. I don't use OpenOCD via tree of MinGW/MSYS and I don't think anyone does, so what's the point of that patch? I use MinGW/MSYS to compile OpenOCD, and it compiles fine, because that process does not require cfg files. In windows there is only one place for installing software - C:\Program Files\. Personally I package OpenOCD the same way as Michael Fisher has done that in the past: /bin/ (exe + dll), /interface/ (cfg), /target/ (cfg), /board/ (cfg) and that works as a charm. Well, I do. Otherwise I wouldn't need it patched. So does everybody else that uses a MSYS environment and wants to build/install openocd with a customary configure make make install. This is the environment we use at work, hence my wish to get it fixed. For my personal use I don't really care since I don't use Windows. The reason I want packagers to comment is to avoid breakage if they install scripts in ../lib relative to the openocd binary. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] post 0.4 memory map features
On Wed, Jan 20, 2010 at 8:40 AM, David Brownell davi...@pacbell.net wrote: On Tuesday 19 January 2010, Øyvind Harboe wrote: New thread on new features to gdb memory maps. Not sure what you mean by caching ... if the CPU is running, we can't assume it's not going to touch such areas. We can tell GDB to read data from an area(e.g. disassembly) from the elf file rather than the target memory, I think. That'd be reasonable for flash and ROM type regions. Not for RAM, which as a rule can be trivially overwritten. When that happens, people driving a debugger will want the current status. Though: I looked at the GDB protocol spec and it says that undefined areas are presumed to be RAM. So I'm a bit puzzled about just what that current code is there for... If you have *any* memory map, then, as I recall, it would be defined as invalid memory if it wasn't ram. If you have *no* memory map, then it's all assumed to be RAM. I'm going by: http://sourceware.org/gdb/current/onlinedocs/gdb/Memory-Map-Format.html which says (among other things): GDB assumes that areas of memory not covered by the memory map are RAM. I don't know if older versions assumed otherwise, though. When I played with it some time ago, it behaved as Øyvind described. There is an option, i think it's called 'mem inaccessible-by-default', that selects the other behavior. The default value may have changed recently. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Other compilers
This would help to avoid picking a magic value for true. #define false 0 #define true (!false) // this will actually evaluate to 1 On the other hand, code that relies on specific values for true is IMHO buggy or at least error prone (especially if true == -1!!), which implies that the define shouldn't be used at all in comparisons. That includes pointless constructs like if ((a == b) == true) ... except with real boolean types (and if there's a bool type there's certainly a built-in true as well). It could perhaps be useful in assignments, though. - Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Other compilers
On Fri, Jan 29, 2010 at 7:11 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Andreas Fritiofson wrote: This would help to avoid picking a magic value for true. #define false 0 #define true (!false) // this will actually evaluate to 1 IMHO, this is unnecessary obfuscation. The C standard guarantees that this will evaluate to 1, so why not write 1 directly? To signal to less knowledgeable people, who might be reading/altering the code, that it is *not* an arbitrary value. You are probably less likely to change the definition of true from not false than from 1 to another non-zero value which might seem just as valid but which isn't, such as -1. Just my 0.14772 SEK... A bit more on-topic: Doesn't clang have stdbool.h? It should provide these constants already. For systems lacking stdbool.h, OpenOCD already contains the necessary compatibility defines in types.h, isn't that getting included? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] stm32x: allow flash probe on a running target
If the flash has not yet been probed and GDB connects while the target is running, the flash probe triggered by GDB's memory map read will fail. In that case the returned memory map will be empty, causing a subsequent load from within GDB to fail. There's not much you can do from GDB to recover, other than a restart; a 'mon reset init' and manual 'mon flash probe' won't help since GDB has already made up its mind about the memory map. It seems there's no reason to require the target to be halted when probing the flash. Remove the check to let a valid memory map be provided to GDB even when connecting to a running target. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/flash/nor/stm32x.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c index 845d589..818c474 100644 --- a/src/flash/nor/stm32x.c +++ b/src/flash/nor/stm32x.c @@ -676,12 +676,6 @@ static int stm32x_probe(struct flash_bank *bank) uint32_t device_id; int page_size; - if (bank-target-state != TARGET_HALTED) - { - LOG_ERROR(Target not halted); - return ERROR_TARGET_NOT_HALTED; - } - stm32x_info-probed = 0; /* read stm32 device id register */ -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On Sat, Apr 17, 2010 at 9:40 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: You have found an interesting case here indeed. As a principle it should be possible to connect via GDB regardless of the target state. Since that state, in general, can include a case where the target's flash is not probable and we need the flash layout upon connection, I think we need a more general solution than the one you have below. Also, I think it is good, in general, to require the target to be halted before the flash is probed GDB aside. Well, many targets DO need to be halted to be able to probe the flash and I agree that it would be nice with a solution to the GDB connect problem in the general case. However, I don't see how it helps to impose artificial restrictions to targets/flash drivers that are free from such limitations. I believe such restrictions should be removed, regardless of any general solution. Besides, if we for some reason would want the target to always be halted before a flash probe, shouldn't that be enforced in the generic flash layer instead of in each individual driver? I would like a robust and simple solution. This is not a common problem, it is the first time that it has been spotted. A solution that made the general case harder would not be desirable. I don't know, I somehow recall previous reports of this kind of problem, earlier than Freddie's. And I suspect there's a vast number of problems like this that never get reported, since people are historically used to having random glitches and occasional malfunction. Restarting GDB/OpenOCD is easier than reporting the bug. For sure it's been a long-standing major annoyance at work with those once-in-a-while failed loads. I just haven't found a cause until now (there may be other as well). Did you consider adding target config script code to a pre connect GDB event? Such an event could reset init the target if the flash is not probe-able. I did consider, but refrained for three reasons: 1. I couldn't find a reference to the available hooks in the documentation, and I don't know them by heart. I'm sure I just didn't look hard enough. 2. That would be somewhat of a workaround and I'd much rather see a fix for the underlying problem. 3. It would probably make it impossible to connect to a running target without stopping it, for the cases where it is desired. This may be a good solution for targets which are impossible to probe in the running state. Other targets shouldn't need it. -- Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
On Tue, Apr 20, 2010 at 2:22 AM, JY Koh ko...@uni-inc.co.kr wrote: Hi All, I have a STM32F103ZE custom board. I have been using OpenOCD with Amontec JTAGkey2 for debugging. It works fine when I use internal SRAM (64K) as workspace. In order to run a little big program I add external SRAM (1M bytes) on FSMC (CS1) So I’d like to use this external SRAM as workspace. What should I change in target configuration ? I change workspace from 0x200 to 0x600. It doesn’t work. Please let me know if there are something to change. Regards, JY Koh OpenOCD won't set up the FSMC for you so you have to do that somewhere, preferrably in the reset init handler. But I'm not convinced that there are any benefits over having it in internal SRAM. What is the problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On Tue, Apr 20, 2010 at 9:08 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I've updated the documentation on the gdb-attach event to provide an alternate way to solve this issue. Great! And there's the target event list that I was briefly searching for. Good to know there is one. Freddie, have you checked if the patch resolves your problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
On Tue, Apr 20, 2010 at 1:10 PM, JY Koh ko...@uni-inc.co.kr wrote: Hi Andreas Thanks a lot. My board has Ethernet and LCD interface so that my program is too big to be accommodated into internal SRAM. For this reason, I added external SRAM (1M Bytes) and I'd like to run my program here. The working area (which I suspect you are talking about when you say workspace) has nothing to do with where your program runs from. It is an area for OpenOCD's internal use, for example for downloading flash algorithms for execution on the target and as buffer space for data during flashing. Best leave it at its default location. If you want to load and debug your program running from external SRAM, simply tell the linker to place your code there. You still have to set up the FSMC in the reset init handler for GDB to be able to load the executable into external memory. Another solution is to run (and debug) your program from internal flash. The hardware breakpoints are often sufficient, and the STM32 is notoriously slow at executing code from external memory. Besides, you still have to make the code fit in flash if you want it to run without the debugger. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Bugfix for flash write_image
On Thu, Apr 29, 2010 at 3:59 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Why hasn't anybody complained yet that flash write_image erase will fail for elf images that are not aligned to sectors??? Unlocking is automatically aligned to sectors in this case... I'll be committing this soonish if I don't hear any protests or insights... ISTR quite some discussion over this a few months ago resulting in the change TO the current behaviour. The rationale being that it's unexpected/rude/dangerous to silently alter memory outside the range being loaded. I seem to agree with that. The REVISIT comment suggests a better solution: let the user force padding to erase sectors with an additional 'pad' argument, or fail with a helpful error message otherwise. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir gla...@hotmail.de wrote: Hi Guys, I have the following problem.. Each time I try to Debug I got this Error Message it is out of my logfile.. Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfff8, count 0x1 At a first glance, it seems fairly normal. The failed accesses to 0xfffX are because GDB tries to backtrace through the stack frames as far as it goes. Sooner or later it will reach one with the special exception return value and stop because it can't read memory there. I assume debugging isn't working for you (and not just the phony error message nagging you)? What are the symptoms? Any other error messages? I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse, OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd 0.4.0 You should be aware of a bug in 0.4.0 causing the first debug session, after OpenOCD has been started, to fail if the target is running when GDB connects. It is fixed in recent git and can be worked around in 0.4.0 by either doing 'reset init' in a gdb-attach event handler, or adding -c init -c 'reset init' to the command line when starting OpenOCD. here are my GDB commands: target remote localhost: monitor reset halt monitor stm32x mass_erase 0 monitor stm32x options_read 0 monitor stm32x unlock 0 monitor reset monitor flash write_image main.bin 0x800 bin file main.out load main.out break main This looks a bit strange. Nowadays, 'reset init' seems to be preferred over 'reset halt'. I don't really know the difference but feel it works better. The 'flash write_image' is superfluous since you later tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB handle the flash programming. Also, I believe a second 'reset init' is needed right after the load in order to update the initial SP and PC from the newly loaded image. The 'mass_erase' is not needed, unless you want to clear unused areas of flash, since the GDB load will erase flash on a page by page basis. The 'unlock' is of course only necessary if you have previously activated the readout protection. You could make a separate script to unlock protected chips instead of doing it each debug session. My GDB initialization looks something like this (out of my head): target remote localhost: monitor reset init load (if GDB has been told on the command line which executable to debug, there's no need to specify a file here) monitor reset init tbreak main continue /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-05-31 21:59, Andreas Fritiofson wrote: Also, I believe a second 'reset init' is needed right after the load in order to update the initial SP and PC from the newly loaded image. It's not. Then what sets it? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, May 31, 2010 at 10:43 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-05-31 21:59, Andreas Fritiofson wrote: Also, I believe a second 'reset init' is needed right after the load in order to update the initial SP and PC from the newly loaded image. It's not. Then what sets it? Just tried it: oocd: stm32x mass_erase 0 reset init gdb: (gbd) tar rem : (gbd) load (gbd) mon gdb_sync (gbd) stepi (gbd) info reg ... sp 0xfffc 0xfffc lr 0x 4294967295 pc 0x80002dd0x80002dd Reset_Handler So the PC is set up by GDB (assuming the entry point has been set correctly in the elf-file) but nothing touches the stack pointer. And sure enough: (gdb) stepi - target is off to infinity and beyond (first instruction pushes some registers) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Tue, Jun 1, 2010 at 5:01 PM, Kenan Özdemir gla...@hotmail.de wrote: This is only a part of the logfile.. I got more error messages like that, and each time I got also a SIGINT signal while debugging.. So how would you recommend me to solve that problem? Is it maybe the linker script where I have to do some changes? Thx for your help Start by fixing your gdbinit oddities. Then post the complete log file, from a minimal debug session to reduce the noise, together with a more detailed description of actual behavior. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32 : improve unlock procedure for mass_erase
On Tue, Jun 1, 2010 at 1:56 PM, gcembed gcem...@gmail.com wrote: Hello, I have added a new command for stm32x : mass_erase_unlock This function combine stm32x unlock 0 + reset to apply unlock + stm32x mass_erase 0 In this way, it is more easier to handle the unlock sequence and makes the (annoying) reset procedure transparent. After calling mass_erase_unlock, flash write_image can immediately called. Here is an example of my flashing procedure : init jtag_khz 1000 reset_config trst_and_srst halt flash probe 0 flash protect 0 0 last off stm32x mass_erase_unlock 0 flash write_bank 0 file.bin 0 flash protect 0 0 last on verify_image file.bin 0 Thanks Gaëtan I like the idea, it would be very convenient to have a single command to always put the chip in a well defined, cleared state. Perfect for programming scripts, which today need to assume that the flash is locked. However... If the flash is locked, the unlock procedure will perform a mass erase, so the second mass erase will just waste time and flash erase cycles. Plus, the SP and PC could have different values after the procedure depending on whether the protection was active or not (see the test I posted yesterday). I would prefer something like the following pseudo code to get a consistent state with minimum number of operations. read option byte; if (readout protection active) unlock; else mass_erase; reset; Then one starts to think why we need this new command in addition to the separate unlock and mass_erase commands. Unlock already implies mass_erase. And is there ever a reason to (try to) do a mass_erase on a locked flash without wanting to unlock it? Or to mass_erase or unlock without resetting the core afterwards (how about when running from ram?). The operations seem to go hand in hand. Maybe we only need one command to do it all. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, Jun 7, 2010 at 5:21 PM, Kenan Özdemir gla...@hotmail.de wrote: I figured out, that the SIGINT signal was caused by an string function. There is a memset in the tskTCB *prvAllocateTCBAndStack(...) function in task.c and if I comment it the problem is solved.. till the next SIGINT is caused by strncpy in void prvInitialiseTCBVariables(...) also in task.c It looks like that there is something missing in my configurations.. :) but what?! User : 823 58626 armv7m.c:489 armv7m_arch_state(): target halted due to debug-request, current mode: Thread xPSR: pc: 0x2040 msp: 0x08002e90 This looks really wrong just after a reset. Executing from RAM with stack pointer in flash... Check your vector table. It should have the stack pointer in the first slot (0x0800) and the reset vector in the second (0x0804). /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] -Wshadow fixes
On Tue, Jun 15, 2010 at 11:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: As you have noticed I'm pushing a number of -Wshadow warning fixes. Most of these should be trivial, but there is of course a chance that I screw this up as I have only done compile tests for most. This is a bit roughshod way of cleaning up the -Wshadow fixes, but I've also fixed *real* bugs along the way here and I need -Wshadow to be enabled by default and get testing done by the community on this one. Obviously not the way to do things when release is close. A backup file sneaked in: src/helper/#jim.c# ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] don't print Jim stacktrace
On Thu, Jun 17, 2010 at 12:30 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Wed, Jun 16, 2010 at 11:40 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: The stack trace provides no valuable information to the user for interactive commands. What about nested proc's? You mean when calling user defined tcl procedures calling other tcl procedures that fails? My guess is the *user* doesn't particularly care about the chain of events leading up to the fault. It's probably due to either misuse of the first procedure, in which case the user is fully aware of what the called procedure was, or a bug in one of the following. If it's a bug it calls for debugging, a job for a *developer* (might of course be the same person with another hat). The developer could flip the debug level switch and see the stack trace as previously. Then on the other hand I don't get a stack trace when a shell script in multiple nesting levels fails, and I'm not very bothered about that. I think the current error messages do more harm than good in the majority of cases. If there's a better solution I'm open to suggestions. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] don't print Jim stacktrace
On Thu, Jun 17, 2010 at 7:24 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Thu, Jun 17, 2010 at 2:05 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Thu, Jun 17, 2010 at 12:30 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Wed, Jun 16, 2010 at 11:40 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: The stack trace provides no valuable information to the user for interactive commands. What about nested proc's? You mean when calling user defined tcl procedures calling other tcl procedures that fails? My guess is the *user* doesn't particularly care about the chain of events leading up to the fault. It's probably due to either misuse of the first procedure, in which case the user is fully aware of what the called procedure was, or a bug in one of the following. If it's a bug it calls for debugging, a job for a *developer* (might of course be the same person with another hat). The developer could flip the debug level switch and see the stack trace as previously. Then on the other hand I don't get a stack trace when a shell script in multiple nesting levels fails, and I'm not very bothered about that. I think the current error messages do more harm than good in the majority of cases. If there's a better solution I'm open to suggestions. I agree that the current error messages are ugly, but I don't agree that we should not print file and line # of e.g. syntax error. The problem is that the file and line# printed is the same for all syntax errors and failed builtins and has no relevance to the actual error. A useful trace is only produced when a nested tcl procedure fails on a lower level. I haven't actually noticed that feature before but now when I've played around with it a bit I agree that we want to keep it. However, we may be able to address this in a more fine grained fashion than simply turning the stack traces on and off. Perhaps you could post some examples and show what parts of the stack trace that is useful and what's just (debug) noise? For example, misspelling a subcommand: flash prob 0 flash prob 0: command requires more arguments -- 1) in procedure 'flash' called at file command.c, line 654 -- 2) called at file command.c, line 365 -- 3) 1) This is nonsense, but not really related to the stack trace. 2) I didn't call the flash command from command.c, i called it from an interactive telnet session. Nothing flash related can be found at line 654. 3) Same as 2, but worse. What was called at line 365?? In short, there's no useful part of this stack trace. A more interesting example, a nested command that fails: $ openocd -f bitsbytes.tcl -c normalize_bitfield 1 2 q ... Runtime error, file bitsbytes.tcl, line 31: -- 4) Syntax error in expression in procedure 'normalize_bitfield' called at file command.c, line 654 -- 5) in procedure 'extract_bitfield' called at file bitsbytes.tcl, line 50 -- 6) in procedure 'create_mask' called at file bitsbytes.tcl, line 39 This is where I start to see the point of the stack trace. However, it's not correct. 4) there's no normalize_bitfield at line 31 as it's suggested. 5) same problem as 2, I called it from the command line. 6) extract_bitfield is really called at line 50, but NOT in procedure create_mask. Line 50 is in normalize_bitfield. It struck me that the stack trace would make much more sense if it was written in the reverse order! Let's see: Runtime error, file bitsbytes.tcl, line 31: Syntax error in expression in procedure 'create_mask' called at file bitsbytes.tcl, line 39 in procedure 'extract_bitfield' called at file bitsbytes.tcl, line 50 in procedure 'normalize_bitfield' called at file command.c, line 654 Apart from the command.c reference this looks quite alright! I attach two patches. One to remove the command.c references and one to rearrange the stack trace output. Any takers? /Andreas From 9ebd0e62a8112ec227d11f0633fc7a897217b8b8 Mon Sep 17 00:00:00 2001 From: Andreas Fritiofson andreas.fritiof...@gmail.com Date: Fri, 18 Jun 2010 00:48:47 +0200 Subject: [PATCH 1/2] don't add confusing source info to Jim When an interactive command fails, the Jim stack trace prints references to the line in command.c where the interpreter was invoked. Since that location has no relation to the actual command that failed, the information serves only to add confusion. By not adding the useless source info to Jim the noise can be reduced, while still printing a useful trace for nested commands. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/helper/command.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/helper/command.c b/src/helper/command.c index be262f2..ea768b2 100644 --- a/src/helper/command.c +++ b/src/helper/command.c @@ -362,7 +362,7 @@ static int register_command_handler(struct command_context *cmd_ctx, if (NULL == override_name) return JIM_ERR; - retval = Jim_Eval_Named(interp, override_name
[Openocd-development] [PATCH] arm-jtag-ew: -Wshadow fix
declaration of ‘index’ shadows a global declaration in /usr/include/string.h Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- I'm not convinced of the benefit of the warning in this case. A whole bunch of other warnings or error would catch the bug if the local variable index had been used in place of the system header declared _function_ index. I had expected the warning to be emitted only for shadowing of compatible types. --- src/jtag/drivers/arm-jtag-ew.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/jtag/drivers/arm-jtag-ew.c b/src/jtag/drivers/arm-jtag-ew.c index 7a6c178..72c756e 100644 --- a/src/jtag/drivers/arm-jtag-ew.c +++ b/src/jtag/drivers/arm-jtag-ew.c @@ -568,29 +568,29 @@ static void armjtagew_tap_ensure_space(int scans, int bits) static void armjtagew_tap_append_step(int tms, int tdi) { last_tms = tms; - int index = tap_length / 8; + int index_local = tap_length / 8; - if (index ARMJTAGEW_TAP_BUFFER_SIZE) + if (index_local ARMJTAGEW_TAP_BUFFER_SIZE) { int bit_index = tap_length % 8; uint8_t bit = 1 bit_index; if (tms) { - tms_buffer[index] |= bit; + tms_buffer[index_local] |= bit; } else { - tms_buffer[index] = ~bit; + tms_buffer[index_local] = ~bit; } if (tdi) { - tdi_buffer[index] |= bit; + tdi_buffer[index_local] |= bit; } else { - tdi_buffer[index] = ~bit; + tdi_buffer[index_local] = ~bit; } tap_length++; -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] debug: debug entry error propagation
Considering the huge number of identical if (retval != ERROR_OK) return retval; added in this and your other patches, maybe we should reuse the CHECK_RETVAL macro from arm11.h as a general mechanism to reduce the clutter? It may not be the best of practices to return from a macro, but rules are made to be broken, right? -- Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error while debugging PXA271
On Wed, Sep 1, 2010 at 10:17 AM, Nived nive...@gmail.com wrote: Hi, We have been trying to debug a .Net Microframework Port onto an IntelMote2 device running a PXA271 processor using openocd-ftd2xx.exe( Version: Open On-Chip Debugger 1.0 (2008-10-04-10:00)). I am able to step through the code well, but a strange error keeps popping at the most undesirable of times. Failed to receiving data from debug handler after 1000 attempts time out writing RX register time out writing RX register Remote connection closed Any idea why this may be happening ? No, but I'm guessing that using an ancient OpenOCD version doesn't help. I have no idea how much attention the PXA271 target has gotten recently but quite a lot could have happened over the last two years. Try with a recent build and see if it works better. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Fri, Sep 3, 2010 at 9:29 PM, John Hartman (NoICE) j...@noicedebugger.com wrote: The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c places the Flash there regardless of the address used in the flash command in the cfg file. The chips have two pins that can be jumpered to specify what appears at address 0: Flash, RAM, or the boot loader. For embedded work, I think Flash will be the most common case. But if I link my program at zero, it is a pain to burn my program, because OpenOCD tells gdb there is only RAM at 0, with Flash at 800. One solution is to re-link my program to 800, and rely on aliasing of the vector table to 0. This works, but is a little annoying. Annoying how? The flash IS at 0x0800. Why would you want to link your program to 0? That if anything would be relying on the aliasing. Of course it works, otherwise the chip couldn't start, but does it alias the entire flash and not just enough to cover the vectors? Two years ago, the ST folks I asked didn't know the answer to that. Perhaps it's clarified in the docs today. I would like to propose the following changes to allow Flash at zero: 1) In the file flash/stm32x.c, function stm32x_probe, remove or comment out the explicit setting of bank-base: // Don't fill in the base: get it from the cfg file // bank-base = 0x0800; bank-size = (num_pages * page_size); (etc.) 2) In the stm32.cfg, change flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME to flash bank $_FLASHNAME.1 stm32x 0x 0 0 0 $_TARGETNAME flash bank $_FLASHNAME.2 stm32x 0x0800 0 0 0 $_TARGETNAME This claims that there are TWO Flash banks, one at 0 and one at 800. By having two banks, users can locate their code at either location, as they prefer, without needing to modify the cfg file. Note that this would break existing cfg files, moving the Flash from 800 to 0. This could be remedied by using a non-zero value for one of the other parameters (bus width etc) to mean new style, and only using the specified base address in that case. (Or more formally, one might add a new algorithm instead of stm32x that does this) What do people think? Breaking existing config files and/or adding confusing nonexistent banks for no apparent benefit? I don't like it. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Sat, Sep 4, 2010 at 2:57 PM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: Perhaps this is a thing that *should* be a bit hard? Perhaps embedded users *should* learn about the load offset for GDB? Do you know if gdb always sends an offset in the (binary?) command to OpenOCD? If yes, I think gdb should be changed to make 'load' easier to use. This is not a problem with gdb. When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. Yes, you can fix the error by telling gdb to load the image with an offset. That won't change the fact that the image is not linked correctly and gdb can hardly be blamed for providing the possibility of a workaround. Nor is it an OpenOCD problem. We just provide the knowledge to gdb about the memory layout of the target and then receive the memory writes. We can't guess the user's intentions and try to remap the writes behind gdb's (and the user's) back. Can OpenOCD return a (textual?) error message? If yes, then OpenOCD could return a very informative error in case someone tries to load to an address not backed by flash. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. And what would the message look like? It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. Do you want me to try to fix the script for you? That would be neat. Why not take it a step further? I notice you try to load an image that has been compiled for another architecture than the one you're working on. Do you want me to install the correct cross compiler and recompile it for you? Based on your recent usage pattern I've come to the conclusion that you're getting desperate to find that nasty bug you introduced two weeks ago, before your deadline tomorrow morning. It's really late, so why don't you go home and get some sleep and I'll fix the bug for you. It looks like you're writing a letter. Would you like help? Aaargh! Ok maybe not such a great idea. Ok I got a little carried away there, sorry :). But my point is: We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. But ideally this knowledge should be up in gdb too, so that gdb, or whatever tool is controlling it, can provide more information and faster response to the user. OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Sat, Sep 4, 2010 at 7:31 PM, Peter Stuge pe...@stuge.se wrote: Andreas Fritiofson wrote: When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. Thanks! Sorry I'm a bit of a gdb noob. I've never used it in-depth in spite of using it a little, over lots of years. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. I disagree; gdb can certainly discover this and do something more useful (error message, whatever) than trying to send stuff to OpenOCD *even though* it can not work. GDB cannot know that it cannot work. The user has, and must have, the power here. If the user tells gdb to load some data to address 0, gdb must try its best to do so, using the information provided (directly or indirectly) by the user to determine _how_ to do it. I know I would hate if gdb tried to outsmart me by disallowing a load of a not-quite-standard configuration just because it doesn't work in other cases. Yes, you can fix the error by telling gdb to load the image with an offset. What happens then, exactly? Does gdb relocate all sections or does it just send a single offset parameter to OpenOCD? I really don't know since I've never used the offset. It's probably mainly useful when you load a binary file without location information encoded in the file. When you load an elf-file, all information gdb needs is already available from the file. Under normal circumstances, load is a fire-and-forget command, it just does the right thing. Very usable. That won't change the fact that the image is not linked correctly Agreed. and gdb can hardly be blamed for providing the possibility of a workaround. If anything I'm blaming gdb for not being smarter about when to automatically add the workaround - or at the *very least* providing relevant and useful error messages. THE workaround you're talking about is not some universal fix for problems related to linking. It may help in some very specific situation with some link script that's broken in a very specific way. It can never be made automatic. Consider if my target actually HAS some memory at address zero that I want to load and gdb has been patched as a result of this discussion to automatically add 0x800 to the load address if it equals zero. It would break my system. Can you find another method of altering gdb that would resolve this issue while not breaking any conceivable valid configuration and not producing nonsense error messages? Nor is it an OpenOCD problem. .. We can't guess the user's intentions And we shouldn't. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. There is not enough information for OpenOCD to accurately determine if it is an error or not. Remember that is very different from there is no error. Even in gdb there may not be enough information, since the load command is so generic. It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. A message similar to this would be a significant and real improvement if it could be generated with zero false positives. It cannot. Do you want me to try to fix the script for you? Silly. At most, whoever is generating the error (gdb IMO) could at this point list known memory areas. That would be neat. Why not take it a step further? .. We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. Let me make another point, which I think is partially parallell partially orthogonal: There should be adequate error messages for all error cases. All error cases must be detected without heuristics and without ambiguity. A bit too ambitious goal, don't you think, especially when you consider errors that are not errors in the realm of gdb, but outside of it. It's like a blender that would refuse to mix ingredients that are not normally used together. But ideally this knowledge should be up in gdb too, OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). Good stuff. The problem is all in gdb then. No, the problem is still in the faulty linker script/build system shipped by Olimex(?). Use a Blinky LED example from another source and the issue is gone. Freddie Chopin wrote: Both OpenOCD and GDB work perfectly well with correct files (standard OpenOCD .cfgs, correctly linked .elf file) so I really don't see any problem you're trying to fix... Usability
Re: [Openocd-development] Message script openocd 0.4.0 windows for In Board flash programming.
flash write_binary 0 BootLoader_108.bin 0x0 0: command requires more arguments There is no command with the name 'flash write_binary'. Perhaps you mean 'flash write_bank'? In that case, the extra zero on the end shouldn't be there. The error message is nonsense. help flash write_bank flash write_bank bank_id filename offset Write binary data from file to flash bank, starting at specified byte offset from the beginning of the bank. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Is this STM32F100x errata sheet discovery the cause of my problems?
On Mon, Oct 4, 2010 at 6:36 PM, n...@bike-nomad.com wrote: I've been trying to use OpenOCD with the STM32F100C4T6B, one of the new low density value line processors from STMicroelectronics. I haven't had too much success using it (not stopping at breakpoints, not noticing when it has stopped at breakpoints, not working well with gdb, not stepping once at a breakpoint, etc.) and I was thinking that this information from the errata sheet might have something to do with my problems. Could anyone tell me whether this silicon bug will affect OpenOCD, and, if so, how? 2.5 Boundary scan TAP: wrong pattern sent out after the “capture IR” state The errata mentions the boundary scan TAP only. It's not likely that the core debug TAP is affected. But I have not read the whole errata sheet. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 flash write speed
On Mon, Oct 18, 2010 at 7:15 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! When I flash some big image (~128kB) on STM32 without any tricks: reset halt stm32x mass_erase flash write_image c:\\stm32.hex I achieve speeds of 12kB. JTAG frequency is 1MHz. When I use my reset init script which sets the flash latency to 2 cycles, starts the PLL with internal RC oscillator (final chip frequency 64MHz) and sets JTAG frequency to 6MHz I achieve speeds of... 13.5kB/s... I've verified that this script works fine (the values in registers are fine), so why there is almost none increase in the loading speed? This test was caused by curiosity which started after reading one forum post in which someone describes that in CrossWorks when using the same JTAG he achieved almost 150kB/s, over 14x faster than OpenOCD. Well, that's BS. The STM32 flash has a nominal programming time of 52.5µs per 16 bits. So the theoretical max speed anyone can achieve is roughly 37.2 KiBytes/s. If you see claims of speeds way above that they're either lies, load-to-ram figures or a mixup in units. That said, I think it should be possible to crank up the STM32 flash programming speed in OpenOCD by at least a factor of two. I don't know what the bottleneck is, but like you I have concluded that JTAG frequency is not the major issue here. My guess is that the programming algorithm we use might be quite inefficient. USB latency might play a role but with double buffering and other tricks in the algorithm the latency shouldn't be a limiting factor. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Eclipse Helios GDB settings (was: STM32 flashwrite speed)
On Mon, Oct 18, 2010 at 9:30 PM, Bernard Mentink bernard.ment...@trimble.co.nz wrote: On 2010-10-18 20:54, Bernard Mentink wrote: Well I have tried that, but I get this error from the GDB (DSF)Hardware debugger plugin for Eclipse: You need to select Standard GDB Hardware Debugging Launcher and instead of load command - use the available options below Load Image and Symbols - for flashing select both checkboxes, for debugging of previously flashed image select Symbols only. Hmm, I have tried that and can indeed use the load command with the Standard GDB debugger, but I don't like that debugger as mach as the DSF version. I also have to use custom commands to get the init sequence I want, the tick box options don't give me what I need. I have got decent results in Helios using the GDB (DSF) Hardware Debugging Launcher with the following, pretty straight-forward, configuration. Main tab: Select project and binary as usual Debugger tab: GDB Command: arm-none-eabi-gdb Check Use remote target JTAG Device: OpenOCD (via pipe) (GDB Connection String: | openocd --pipe) Startup tab: Uncheck Reset and delay... and Halt Check Load image, use project binary Check Load symbols, use project binary Check Set breakpoint at: main Check Resume No run or init commands specified In the project root, create a file openocd.cfg: --- source interface.cfg source [find target/stm32.cfg] source [find chip/st/stm32/stm32.tcl] stm32.cpu configure -event gdb-flash-write-end { reset init } stm32.cpu configure -event gdb-flash-erase-start { reset init } --- interface.cfg is an unversioned file sourcing my adapter config file (interface/jtagkey.cfg in my case). Does this work for you as well? Of course you need to change the stm32-specifics if you have the LPC part. Oh, by the way, this is on Linux. Also I'd like to work out how to attach to a running target nicely without specifying init commands manually. Unchecking Load and setting the init commands to mon gdb_sync and stepi probably does it but I'd rather not need to have to have any commands in the launch file. All, in all, I get the same speed with the GDB load command or the target flash command .. I guess it maybe a limitation of the FT2232D based JTAG module I am using ... It would be good if someone else can confirm that with the same hardware. Both speeds should be more or less identical. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Eclipse Helios GDB settings (was: STM32flashwrite speed)
On Tue, Oct 19, 2010 at 11:28 PM, Bernard Mentink bernard.ment...@trimble.co.nz wrote: Hi again Andreas, An update to this: The error below was because I had several instances of gdb running, they were not closed off correctly in eclipse. Hm, yeah I've seen that too sometimes. Perhaps more often or with different error messages when running with the --pipe option. Now when I run it, the program downloades and I get to main correctly However, when I hit continue, I end up in the g_pfnVectors() at 0x00, and I can not continue .. Also, in the Console window, I get this error: lpc1766.cpu -- clearing lockup after double fault I am way out of my depth here .. I don't have this issue when I run my init script as described earlier ... Instead of this method. This is indicative of an actual bug in your code. I can't explain why it only shows with my method. If you can get to main you should be able to step instead of continue. Does that work? Can you step forward until you hit the place where it crashes? The clearing lockup after double fault says that the core was in a lockup state which means a fault occurred (bad memory access, invalid instruction and such, probably due to a software bug) and, in addition, there was an error while fetching or executing the exception vector (no fault handler installed?). Common bugs that can cause this is invalid pointer dereferencing, buffer overflows or enabled interrupts for which no handler is installed. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM). After some time I've come to conclusion that the problem was caused by incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With std cfg files flashing the device resulted in: Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : Block write error address 0x20002000, wcount 0xc The flashing actually works, but is extremely slow (rate 200B/s). Changing the workareasize to 2kB helps - everything works normally then. We should probably change it to the least common denominator within the family, which is 8kB (maybe even 6?). Definitely, if you don't see any significant reduction in flashing speed after reducing the workareasize (8kB vs 2kB). That's likely dependent on the adapter in use, of course. However, I've always thought that OpenOCD somehow finds the amount of RAM that is available on the chip and will not allocate more than is possible? Am I wrong? Yes. Early silicon had a SRAM size register in factory programmed ROM but it was later removed for some reason. I don't think OpenOCD used it even when it existed. We could probably determine the size indirectly, maybe from a chip id database, but I think it's just as good to simply provide a minimum safe workareasize and let the user override it if he wishes. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones ch...@martin-jones.com wrote: Hi all, I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6, and the JTAG dongle is an Amontec JTAGKey. By and large it works: I can program the flash, halt, use gdb, all the things I'd expect from OpenOCD. But there's a way of breaking it semi-permanently. The application on the STM32 is one which spends most of its time with the CPU in Stop mode, waking up periodically (about every 12ms) via an RTC interrupt to do some processing. If I attempt to start OpenOCD while the microcontroller is stopping and running like this, I get messages which say, Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG hardware is clearly working to some extent. The whole JTAG system appears to be then stuck in this state. Restarting OpenOCD, doing a hardware system reset on the microcontroller, unplugging everything including the JTAG dongle and its USB interface, all make no difference. I've even tried exercising the JTAG port using another application (XJTAG) though this only does boundary scan testing and doesn't play with the ARM debug TAP. Though boundary scan works fine. The only thing which fixes the problem is power-cycling the STM32 chip itself. I note from its documentation and the ARM Cortex-M3 TRM that some parts of the core debug unit are only reset at power up, not in response to a system reset. The device has no TRST pin. However, this board is going to be permanently moulded into a plastic lump with a battery, so power cycling it is *not* an option. Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? The debug unit is clocked by the core clock. So, naturally, when you stop the core clock you'll lose all debug access. There's nothing OpenOCD can do about it. As Kyle said, you can flip some bits in DBGMCU_CR to keep the debug unit clocked even in sleep modes. That will enable you to debug but of course it will also drain your battery. One can also ponder why you need debug access to something molded in plastic... Wouldn't it be better to debug your application on a more lab-friendly setup? //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
2010/10/31 Michel Catudal michelcatu...@gmail.com: Le 2010-10-29 19:15, Andreas Fritiofson a écrit : One can also ponder why you need debug access to something molded in plastic... Wouldn't it be better to debug your application on a more lab-friendly setup? A production unit that is to be protected from the environment must be molded into something. We would never use plastic in most application but the end result would be the same. I do agree that molded in plastic is strange but what difference would it make as for software is concerned? It's not the plastic mold that's strange, it's the desire to _debug_ software on a production unit, permanently sealed or not. Debugging is software development, which is more comfortably done on a lab unit which can be probed and measured (and, in the best of worlds, preferably _before_ production even starts). Most designs nowadays require reflashing at one time or another. Most of us in the industry no long use mask rom. Why do you think that we would want simulated mask rom? I didn't say that. You're talking about in-system programming, not debugging. ISP (or reflashing) is often possible over the debug access port, but it's not always the only option and seldom the most practical one. A better alternative, especially for a sealed product, is to use a preprogrammed boot loader operating over some other communication channel present in the product. I'm guessing that would have been Chris' first choice, had this particular boot loader of his not been broken. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
On Wed, Nov 3, 2010 at 10:01 AM, Chris Jones ch...@martin-jones.com wrote: I tried the IAR software but don't have a JTAG dongle directly compatible with it. I tried to get it to talk to OpenOCD via GDB but attempting to download the code to the STM32 that way just resulted in streams of errors. I didn't spend any more time on this because I don't think it would help to isolate the issue into or out of OpenOCD. There seem to be some circumstances in which attempting to start OpenOCD connected to an STM32 in stop mode, or switching rapidly into and out of stop mode, breaks the STM32's debug unit. It's consistently repeatable. For now we can work around it by being extremely careful when we try to connect OpenOCD, but I'd like to try and help prevent the problem. I agree with Michel that the first step towards that is probably to determine whether the problem has a reasonable chance of being fixable in OpenOCD. Otherwise it's a waste of time trying to. We could try completely different tools to see if they have the same problem. We can also ask ST (having tried different tools would help here, too). Maybe someone on the list has the tools and the time required. Unfortunately, I have neither right now. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Stm32 load elf file with gdb
On Thu, Nov 4, 2010 at 2:46 PM, Jonathan dumaresq jdumar...@cimeq.qc.ca wrote: Hi all, I try to get my stm32 environnement working with gdb. I'm unable to get my elf file loaded with gdb. Here my setup: Openocd.cfg / source [find interface/olimex-arm-usb-ocd.cfg] source [find target/stm32.cfg] stm32.cpu configure -event gdb-flash-write-end { reset init } stm32.cpu configure -event gdb-flash-erase-start { reset init } /// All include file are default. Here how i lunch gdb Arm-none-eabi-gdb rtosdemo.elf (gdb)target remote | openocd --pipe (gdb)load rtosdemo.elf (gdb) load Loading section .text, size 0xa7d8 lma 0x0 Debug: 408 139609 gdb_server.c:2145 gdb_input_inner(): received packet: 'X0,3fb0 :binary-data' Debug: 409 139609 gdb_server.c:1388 gdb_write_memory_binary_packet(): addr: 0x00 00, len: 0x3fb0 Debug: 410 139609 target.c:1251 target_write_buffer(): writing buffer of 16304 b yte at 0x 0x is most certainly the wrong place to be writing stuff... Warn : 419 139828 arm_adi_v5.c:720 mem_ap_write_buf_u32(): Block write error add ress 0x0, wcount 0xfec Error: 420 139828 gdb_server.c:1211 gdb_error(): unexpected error -107 Load failed (gdb) I have to admit that i'm a little bit lost there. Do i have something else to do to get this work ? Yes, you need to fix your broken linker script (in case of GNU ld) to place your code in flash, which is located at 0x0800, not 0x0. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've doubts about this commit http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5 Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Do you think this patch should be reverted? Are there any important reasons to not have reset_config in stm32.cfg as in many other target cfg files? I don't think this specific patch is the problem. I've run with 'reset_config none' for a long time without any trouble. Before this patch there were a bunch of reset issues. Please don't revert it. Besides, having reset signals wired is optional and a board/adapter level decision, and should not be specified in the target file. If the peripherals are not getting reset I suspect some other patch has sneaked in that changed the soft reset behavior from a real reset to a core only reset. Perhaps to fix issues with other Cortex-M3 implementations. I haven't run HEAD for a while, but if I find some time I'll try to confirm and locate the problem. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've doubts about this commit http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5 Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Do you think this patch should be reverted? Are there any important reasons to not have reset_config in stm32.cfg as in many other target cfg files? I don't think this specific patch is the problem. I've run with 'reset_config none' for a long time without any trouble. Before this patch there were a bunch of reset issues. Please don't revert it. Besides, having reset signals wired is optional and a board/adapter level decision, and should not be specified in the target file. If the peripherals are not getting reset I suspect some other patch has sneaked in that changed the soft reset behavior from a real reset to a core only reset. Perhaps to fix issues with other Cortex-M3 implementations. I haven't run HEAD for a while, but if I find some time I'll try to confirm and locate the problem. Without having tested it, commit 3c69eee9 seems to be the problem. While it's good that the reset type is now configurable, changing the default behavior wasn't perhaps the best idea. It would have been better to keep SYSRESETREQ as the default and change it in the configs for cores that haven't wired it up to the master reset. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 10:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Spencer Oliver s...@spen-soft.co.uk wrote: The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. I believe STM32 does what it is supposed to, I've never had issues with it. Code comments mentions some Stellaris parts only. Regardless, I feel that having a working SYSRESETREQ should be norm, and broken silicon worked around in the respective config file. I think it would be good for openocd to have knowledge of what core can handle certain reset modes. We have already gone down this path with success on Cortex A8 where there is a hack for an iMX51 part for the debug offset. This target specific code could either be in OpenOCD or perhaps better in the config files? In this case, one line of tcl overrides the default setting, so it's perfectly suited for the config files. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] httpd: fix build error with new Jim
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/server/httpd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/server/httpd.c b/src/server/httpd.c index af8c3c8..42bba5b 100644 --- a/src/server/httpd.c +++ b/src/server/httpd.c @@ -84,7 +84,7 @@ static const char *httpd_exec_cgi_tcl_error(Jim_Interp *interp) t = appendf(t, Runtime error, file \%s\, line %d:br, interp-errorFileName, interp-errorLine); t = appendf(t, %s br, Jim_GetString(interp-result, NULL)); - Jim_ListLength(interp, interp-stackTrace, len); + len = Jim_ListLength(interp, interp-stackTrace); for (i = 0; i len; i += 3) { Jim_Obj *objPtr; -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] httpd: fix build error with new Jim
On Wed, Nov 10, 2010 at 11:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I was actually pondering removing the httpd stuff from OpenOCD as we have the tcl server which is a good enough interface. I don't think the httpd server was ever used and OpenOCD's role seems to be more low level. Any thoughts on that? Fine with me, I'm not really using it. I just have it configured in to build-test it. Maybe we should just deprecate it in 0.5.0 and remove it after that, though. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell davi...@pacbell.net wrote: Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Not all SoCs reset peripherals like that; don't assume they do. Likewise, not all boards. - Dave It's not an assumption, it's in the manual. Do you have an example of a microcontroller which doesn't reset the bulk of the peripherals on a NRST or equivalent? This is somewhat of a regression, since in 0.4.0, the STM32 (and likely other cortex-m3) peripherals were being reset when a (soft or hard) reset was issued from OpenOCD. Now they're suddenly not when the default configs are used. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()
On Fri, Dec 10, 2010 at 4:16 PM, Paul Richards paulr...@gmail.com wrote: On 2010/12/10 18:46, Spencer Oliver wrote: Not looked into it but why do we not just duplicate the existing unregister event/timer functions - or are they broken aswell? They (the target versions) don't appear to have the same problem. The only difference I can see is that the jtag_unregister_event_callback() continues to look for further events to unregister. I'm not familiar enough with the code to know why that might be possible. Easy enough to continue iterating if it is required. Now there's 3 versions to choose from :-) I would have copied these had I known they were there. It's not too late. The target versions seems nice and readable. And correct, as far as I can see this late hour. I think the jtag version should follow the behavior of these and only remove the first matching handler. That would be the correct thing to do, if there was a point in having the same handler registered more than once. The only issue I have with copying the target version is that having the same code duplicated in three places probably warrants refactoring it into a helper function instead. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()
On Fri, Dec 10, 2010 at 11:39 PM, Peter Stuge pe...@stuge.se wrote: Andreas Fritiofson wrote: Now there's 3 versions to choose from :-) It's not too late. The target versions seems nice and readable. And correct, as far as I can see this late hour. I think the jtag version should follow the behavior of these and only remove the first matching handler. That would be the correct thing to do, if there was a point in having the same handler registered more than once. Really? How are the callbacks being used? I don't know. But, generally, if I _can_ register the same handler twice, I'd expect each registration to require a separate unregister call. The actual call sites would have to be inspected before changing this behavior, of course. There shouldn't be many of them, since the bug has gone unnoticed for so long. The only issue I have with copying the target version is that having the same code duplicated in three places probably warrants refactoring it into a helper function instead. Which is difficult for something simple as a linked list, unless the list entries are identical, and of the same type. Are they? Two of them differ only in the callback signature, the third is very different. There are several imaginable solutions. You could have the list functions operate on a generic next pointer, included as the first element of all specialized list types. Or the actual data could be stored outside the list structure, with just a void pointer in it. Both require some nasty casts. Neither is likely to be more clear and concise than the duplicated code. Maybe if it was used in _ten_ places... /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On Sun, Dec 12, 2010 at 5:22 PM, Manuel Borchers man...@matronix.de wrote: Hi all, I'm a bit lost with a problem concerning OpenOCD, eCos and my STM32 board. I'm running with a ftdi2232-based usb2jtag adapter. I'm already using this adapter for quite a long time for my ARM9-based projects, so the hardware should be fine. I'm currently porting eCos to a STM32 MINI board, which John announced a while ago. The port is based on the STM3210E board port. A simple demo program which prints out some lines on the serial channel is being flashed into the chip's on-chip flash. When I let the processor run it directly without debugger, it works fine. But when I'm stepping through the code and want to step over a thread-delay routine OpenOCD or the CPU gets somewhat confused and I'm unable to continue debugging. That's what I'm doing in gdb (arm-eabi-gdbtui actually): target remote : mon reset init load b simple_prog c b serial.c:99 [the line before the thread delay function] c n And that's what I'm getting in GDB then: -- snip -- JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 Polling target failed, GDB will be halted. Polling again in 100ms Program received signal 0, Signal 0. cyg_thread_delay (delay=0) at /home/manuel/Arbeit/netX-ACCOS/netx_accos/trunk/src/ecos/ecos-cvs/packages/kernel/current/src/common/kapi.cxx:292 Current language: auto; currently c++ -- snip -- OpenOCD seems to lose the connection to the target as I get the following lines repeatedly on the shell: -- snip -- Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0 Polling target failed, GDB will be halted. Polling again in 6300ms -- snip -- The CPU seems to continue running, as I get the output from the program correctly. The parameter delay = 0 seems to be bogus, because the function is called with delay=1000 (which is 10s delay with the default config) from the application thread. My openocd config is attached. I'm running the git version pulled an hour ago, but had no luck with stable 0.4.0 either before. I'm quite new to the STM32 / Cortex-M3 familiy, but already did a lot work on ARM9 before. I also tried lowering the JTAG speed to 100kHz which did not help. The thread delay is doing a 10 sec delay, but signal 0 is hit immediately after stepping. I tried with a cyg_thread_delay(1) et voila: stepping suddenly works! So what's goind on here? Has anyone worked with openocd on an STM32? I'm not sure if the problem lies in openocd or the STM32 eCos port... I came to the problem because I'm writing and debugging a SPI-Flash driver (based on the M25Pxx driver) for the on-board flash (SST25VFxxxB) which uses the cyg_thread_delay function when kernel support is available. But I reduced it to a simple serial example, which is delaying between outputting lines... Any help appreciated. Regards, Manuel It may be that the scheduler or the idle thread puts the core in low power mode if no thread is ready to run. That will break the debugger connection. See if anything executes a WFI or WFE instruction, and disable it. There's likely a configuration setting for it. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32, openocd and eCos
On Mon, Dec 13, 2010 at 10:16 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 13/12/2010 08:47, Manuel Borchers wrote: Hi Andreas, hi list, On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote: It may be that the scheduler or the idle thread puts the core in low power mode if no thread is ready to run. That will break the debugger connection. See if anything executes a WFI or WFE instruction, and disable it. There's likely a configuration setting for it. Yes, thanks for hint, I already got a hint on the eCos list about the idle thread executing 'wfi'. I suspected something like that but didn't find it myself in the sources. I also got a hint how to keep the clock for JTAG active when the CPU goes to wfi. I'll try that tonight and report back if it didn't solve my problem. Thanks again! Cheers, Manuel Look for the define HAL_IDLE_THREAD_ACTION in packages/hal/cortexm/arch/current/include/hal_arch.h - i comment that out while debugging. However it does work ok if slow the jtag clock to about 1kHz aswell. Are you sure? I can't see why that would work. Unless you have a high frequency interrupt running that happens to match with the jtag transitions. Removing WFI/WFE in debug builds, or setting DBGMCU_CR to keep clocks running solves most cases, anyway. //Andreas ___ 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 Tue, Dec 14, 2010 at 7:26 PM, Jonathan dumaresq jdumar...@cimeq.qc.ca wrote: Hi, I have pull the head branch of openocd and now I can write to the cfi at a slow speed. I want to modify openocd to use the asm code for the cortex. I have used the sample contrib file as starting point for the cortex. I have been able to translate (a little effort there) the code. Now the question: 1- I have modifer the cfi.c to use my new opcodes in the word_16_code array. 2- I have change armv4_5_info.common_magic for ARMV7M_COMMON_MAGIC Up to now, I get to the point that my new code is loaded to ram and executed. The problem, is that I always exit of the armv7m_run_algorithm with an timeout. The target is never halt. BUT, when I look at the PC I'm at the exit point of the code, and the value of R5 is 0x80. So From what I see, The flash have been writed correctly. When I double check with mdw 0x6400 all the data is well written. I have no idea why or How the target will be halted. Does any one here can point me to the righ direction ? I attach the asm file for the spansion 16 bin interface with the cortex m3 Regards Jonathan Dumaresq IIRC, all armv7-m algorithms must end with a BKPT instruction. That should probably be documented somewhere. Which sample contrib file are you talking about? Regards, Andreas ___ 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 Fri, Dec 17, 2010 at 4:36 PM, Jonathan dumaresq jdumar...@cimeq.qc.ca wrote: Hi all, Here my first patches to be able to use the CFI driver on cortex M3 with the helper code on target. This is probably not the better way of doing it, but at least it's work. This have been tested on real hardware. The default cfg that enable the fsmc can be used. Right now only the 16 bit interface has been tested. I can add the 8 and 32 bit if the patch is correct. From my testing, I got 17KB/sec I'll apreciate a feedback for thoses patches. Since this is nearly my first git pacthes... Regards Jonathan Dumaresq Just drop patch #3 and replace 'b done' with 'bkpt #0' in patch #1 (and the corresponding opcode in patch #2). No need to add a breakpoint programmatically. Look at the other armv7-m algorithms. Otherwise it looks good to me, but I'm no expert on the cfi-code. Maybe the armv4_5_info naming is a bit odd if it now contains armv7-related stuff, though. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Help needed for SAM3S4C
On Fri, Dec 17, 2010 at 6:27 PM, Kenan Özdemir gla...@hotmail.de wrote: Hi, i start working with the SAM3S4C, but having trouble with openOCD. When I start debugging, the very first instructions are working fine, but after the 3rd instruction, its jumping acrross the code. This is my main.cpp int main(void) { int a, i = 0; a = 5; for(i = 0; i 10; i++) a = a+5; } the first instructions (int a, i = 0; and a = 5;) are working. At the begining when the curser is at int a... the PC is pointing to 400107 (the next instruction a = 5). When I press step into, the curser goes to a = 5 and the PC is pointing to the next instruction (for(i...)), but when i press step into again, it jumps into the adress 400d50. I suspect that you're wrongly assuming that the execution flow follows line-by-line in source code order. That's not the case for any but possibly the lowest compiler optimization settings. The compiler will reorder and remove your statements at will, as long as semantics, according to the C standard, are unchanged. In your case the entire loop will be removed since it doesn't DO anything. The jump to 400d50 is probably where your main() returns to. In fact, your main() is semantically equivalent to int main(void) { } It's sometimes very hard to debug strongly optimized code, so you might want to turn optimization off if you need to step around a lot. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] segfault in cortex_m3_assert_reset
Hi all, Has anyone else problem with segfaults on current git? As soon as I issue a reset, openocd dies. This is with a STM32 target. Same result with both rlink and a jtagkey interface. Bisection was successful and pointed to commit '8f93c0a3... target: do not expose error numbers to users' by Øyvind. Unfortunately, that patch seems very much unrelated. I suspect it's a 64-bit issue, because I've traced it to rbx (containing a pointer) getting trashed (some of the high 32 bits set) during the call to mem_ap_read_atomic_u32 in cortex_m3_assert_reset (cortex_m3.c:932), which causes the segfault later when it dereferences the pointer. My setup is as follows: $ uname -srvm Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 $ gcc -v gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) I attach the git bisect test script that gave the following log: git bisect start # good: [c24087d33ec75144ec5f579142152d8eb5ce50c9] config: fix luminary jtag config git bisect good c24087d33ec75144ec5f579142152d8eb5ce50c9 # bad: [a72741818431d693e48b0f016258be0fec1f79da] stellaris: automatically generate and update device IDs git bisect bad a72741818431d693e48b0f016258be0fec1f79da # good: [56d9ee779d5d744822e5957c98c0d61ce3fc44a9] flash: print flash bank name on flash info cmd git bisect good 56d9ee779d5d744822e5957c98c0d61ce3fc44a9 # bad: [d356034f03eb60fd4e8b3537bd979d9e7e5e25f8] svf: implement sleep for RUNTEST min_time git bisect bad d356034f03eb60fd4e8b3537bd979d9e7e5e25f8 # bad: [21a1c6ec33f87b6285e47ad6597cd49ad89a9485] NAND/TCL: fix segfault on syntax error git bisect bad 21a1c6ec33f87b6285e47ad6597cd49ad89a9485 # bad: [eea91f71f918caa5e4ef571c76f60c579533b0f6] warning: fix warning where GCC didn't catch a doubly declared global structure git bisect bad eea91f71f918caa5e4ef571c76f60c579533b0f6 # good: [7cd2617384f4ac620c468343c1f2009fbfa2fc79] initial SWD transport (SWD infrastructure #2) git bisect good 7cd2617384f4ac620c468343c1f2009fbfa2fc79 # bad: [4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7] warnings: use more 'const' for char * git bisect bad 4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7 # bad: [8f93c0a3fe29313945a63b3f2154baef70acd796] target: do not expose error numbers to users git bisect bad 8f93c0a3fe29313945a63b3f2154baef70acd796 test.sh Description: Bourne shell script ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix segfault from stack corruption in ahbap_debugport_init
ahbap_debugport_init was queueing reads to a local stack variable but didn't execute the queue before returning. Since the result of the reads are not used anyway, it's better to pass NULL as the destination instead of a dummy variable. I changed this throughout the function, even for the reads that were actually executed. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/target/arm_adi_v5.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c index 7df0d4f..7b801b9 100644 --- a/src/target/arm_adi_v5.c +++ b/src/target/arm_adi_v5.c @@ -906,7 +906,6 @@ extern const struct dap_ops jtag_dp_ops; */ int ahbap_debugport_init(struct adiv5_dap *dap) { - uint32_t dummy; uint32_t ctrlstat; int cnt = 0; int retval; @@ -931,7 +930,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap) /* DP initialization */ - retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy); + retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL); if (retval != ERROR_OK) return retval; @@ -939,7 +938,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap) if (retval != ERROR_OK) return retval; - retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy); + retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL); if (retval != ERROR_OK) return retval; @@ -977,7 +976,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap) alive_sleep(10); } - retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy); + retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL); if (retval != ERROR_OK) return retval; /* With debug power on we can activate OVERRUN checking */ @@ -985,7 +984,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap) retval = dap_queue_dp_write(dap, DP_CTRL_STAT, dap-dp_ctrl_stat); if (retval != ERROR_OK) return retval; - retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy); + retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL); if (retval != ERROR_OK) return retval; -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault in cortex_m3_assert_reset
Mathias: I built in a fresh out-of-tree directory, and reran bootstrap every time. See test.sh script. Anyway I found the bug, the patch I posted solves it for me. Since the stack was corrupted, technically, anything could have happened. It was just magically consistent during my bisection. All: Finding the bug got me thinking. All this error propagation code that is all over the place: retval = jtag_queue_foo(bar); if (retval != ERROR_OK) return retval; What happens if a queue operation fails and the function returns without having executed any previously queued reads? Those reads are often to stack allocated variables that goes out of scope if we return. Is the queue discarded if there's an error? Otherwise the will be massive stack corruption when a subsequent operation executes the queue. Also, what are the possible failure modes for the queue operations? Is there any way they can fail other than out-of-memory? Maybe it's not the best solution to error check every individual queue operation. Maybe the queue operations should be transactional, so that either all or none of a set of related operations are added to the queue. Only the transaction as a whole would need to be error checked. Regards, Andreas On Tue, Jan 25, 2011 at 9:11 AM, Mathias K. kes...@freenet.de wrote: Hello, i had the same error a while ago. Try to clean your repository (make distclean) and recompile the source. Regards, Mathias Am 24.01.2011 23:08, schrieb Andreas Fritiofson: Hi all, Has anyone else problem with segfaults on current git? As soon as I issue a reset, openocd dies. This is with a STM32 target. Same result with both rlink and a jtagkey interface. Bisection was successful and pointed to commit '8f93c0a3... target: do not expose error numbers to users' by Øyvind. Unfortunately, that patch seems very much unrelated. I suspect it's a 64-bit issue, because I've traced it to rbx (containing a pointer) getting trashed (some of the high 32 bits set) during the call to mem_ap_read_atomic_u32 in cortex_m3_assert_reset (cortex_m3.c:932), which causes the segfault later when it dereferences the pointer. My setup is as follows: $ uname -srvm Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 $ gcc -v gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) I attach the git bisect test script that gave the following log: git bisect start # good: [c24087d33ec75144ec5f579142152d8eb5ce50c9] config: fix luminary jtag config git bisect good c24087d33ec75144ec5f579142152d8eb5ce50c9 # bad: [a72741818431d693e48b0f016258be0fec1f79da] stellaris: automatically generate and update device IDs git bisect bad a72741818431d693e48b0f016258be0fec1f79da # good: [56d9ee779d5d744822e5957c98c0d61ce3fc44a9] flash: print flash bank name on flash info cmd git bisect good 56d9ee779d5d744822e5957c98c0d61ce3fc44a9 # bad: [d356034f03eb60fd4e8b3537bd979d9e7e5e25f8] svf: implement sleep for RUNTEST min_time git bisect bad d356034f03eb60fd4e8b3537bd979d9e7e5e25f8 # bad: [21a1c6ec33f87b6285e47ad6597cd49ad89a9485] NAND/TCL: fix segfault on syntax error git bisect bad 21a1c6ec33f87b6285e47ad6597cd49ad89a9485 # bad: [eea91f71f918caa5e4ef571c76f60c579533b0f6] warning: fix warning where GCC didn't catch a doubly declared global structure git bisect bad eea91f71f918caa5e4ef571c76f60c579533b0f6 # good: [7cd2617384f4ac620c468343c1f2009fbfa2fc79] initial SWD transport (SWD infrastructure #2) git bisect good 7cd2617384f4ac620c468343c1f2009fbfa2fc79 # bad: [4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7] warnings: use more 'const' for char * git bisect bad 4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7 # bad: [8f93c0a3fe29313945a63b3f2154baef70acd796] target: do not expose error numbers to users git bisect bad 8f93c0a3fe29313945a63b3f2154baef70acd796 ___ 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] mips target
On Mon, May 30, 2011 at 7:10 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, May 30, 2011 at 5:47 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: lead to the NULL pointer dereference in the time of jtag data scan execution (r is a automatic variable, local to the mips_ejtag_fastdata_scan() function) ? Correction, not NULL pointer, but some trash value pointer from the no longer valid stack. No, buf_get_u32 fills r[4]. The initial value does not matter. No, I meant about r array. this array is a local variable allocated on a stack. Where is it referenced again ? Outside of this function ? I do not know very well the OpenOCD architecture, I am afraid that this reference might be used during jtag data scan execute function and that at this moment it will not be valid anymore (although I am obviously wrong, since you confirm that it works and you saw no sigfaults). Drasko is probably right here. This will crash and burn. At least sometimes/somewhere. Getting a segfault or even a consistent failure is not guaranteed. However, a more fundamental problem with this code is that it uses the in_field before the jtag queue is likely to have been executed. Most of the times it would just set *data to whatever garbage that was on the stack where r[] got allocated. The correct way to handle host/target endianness swapping without forcing a queue execution is to add a callback to the queue. See for example adi_jtag_dp_scan_u32() in adi_v5_jtag.c. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.
On Mon, Jun 6, 2011 at 10:11 AM, Yegor Yefremov yegorsli...@googlemail.comwrote: The only question is, what description has jtagkey-tiny Amontec JTAGkey or Amontec JTAGkey-tiny? My JTAGkey Tiny uses the string Amontec JTAGkey and indeed it works with the jtagkey.cfg. Please also note that the means to match devices seems to differ between linux-libftdi and win32-ftd2xx. At work (the latter configuration) we have set our different ft2232 dongles back to the standard FTDI vid/pid to avoid having lots of different drivers installed. It works with the stock openocd config files because openocd-ftd2xx apparently ignores the vid/pid and uses only the description to select the device. At home, on linux-libftdi, both the vid/pid and the description must match. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Configuration file for stm32f2xxx
On Mon, Jun 6, 2011 at 11:10 AM, Laurent Charpentier laurent_p...@yahoo.com wrote: Hi, We would like to add the configuration file for the stm32f2xxx to the GIT repository. Here is the file (should be named openocd/tcl/target/stm32f2xxx.cfg ) Thanks for adding this file. Laurent A patch is generally preferred. # Work-area is a space in RAM used for flash programming # By default use 128kB if { [info exists WORKAREASIZE] } { set _WORKAREASIZE $WORKAREASIZE } else { set _WORKAREASIZE 0x2 } There are at least one STM32F2xx with 64 kB RAM, so the default work area size shouldn't exceed that. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Configuration file for stm32f2xxx
On Mon, Jun 6, 2011 at 11:23 AM, Øyvind Harboe oyvind.har...@zylin.comwrote: To create a patch: git add tcl/tcl/target/stm32f2xxx.cfg Another minor thing I noticed now, why three x in the file name? And in the flash driver too it seems? Shouldn't it be stm32f2xx? (also, to avoid confusion, I'll just point out that the above git snippet has tcl/ duplicated in the path) /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Mon, Jun 6, 2011 at 3:35 PM, Øyvind Harboe oyvind.har...@zylin.comwrote: Is this patch ready to be committed? Any objections? It doesn't build. Leftover variable no longer used. Apart from that it seems OK from my limited review. I could agree with the others that it looks like a needlessly complex fix for a simple missing free. Maybe there's a bigger picture here but I don't get the open/init deinit/close separation or why it's needed (Why would you want to open without initializing?). Haven't given it much thought though. Is the mentioned followup patch already posted? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Tue, Jun 7, 2011 at 2:37 PM, Laurent Gauch laurent.ga...@amontec.comwrote: Hi Andreas, Thank you for your comment. It doesn't build. Leftover variable no longer used. minor issue Apart from that it seems OK from my limited review. I could agree with the others that it looks like a needlessly complex fix for a simple missing free. Maybe there's a bigger picture here but I don't get the open/init deinit/close separation or why it's needed (Why would you want to open without initializing?). Haven't given it much thought though. Is the mentioned followup patch already posted? The mentioned patches are not posted, but ready to. As asked by maintainer's, we want to have small and precise patches. We only posted the patch 1/5 . https://lists.berlios.de/pipermail/openocd-development/2011-May/019176.htmlWe want to have it merged before to give the 2..5/5. The 2..5/5 will be depending of the acceptation of 1/5 ... That is the problem with this patch. It adresses the problem of a memory leak, while at the same time it tries to sneak in an unrelated refactoring in preparation for some future patches we still haven't seen or discussed. I guess that's why this patch has received so little attention and acceptance. That, plus your threatening attitude towards the community and the maintainers when criticism is raised. I suggest to drop this patch and merge a simpler fix for the problem adressed by this patch. Only a few lines of code would need to change. The refactoring part of this patch should be made part of the upcoming patchset for the apparent open/init/deinit/close-problem. Although I can't see why that separation would be necessary or even desired to fix the problem with leaving the ft2232 in a known state after shutdown. Preparing the ft2232 driver for the SWD work is futile since it's no such work is in place and we can't be sure what will be required in terms of API changes. --- We do not want to open without init, but we want to init or re-init an already opened device handle :-) In the same way, we want to deinit without having to close the device handle ! In an other way, we want to be able to force deinit and close or close only without having to have a interface quit() call from the upper layer, in case something wrong during open init or others. We want to make sure any USB JTAG SWD adapters based ft2232 (as jtagkey) are correctly deinitialized at any shutdown of openocd (as via jtagkey_deinit). (Actually nothing is done during the quit except close the handle ... but we have to make sure deassert JTAG PORT AND TRST SRST IO (and to deassert SWD mode), to reset the MPSSE, to go away the bit-bang mode, and only then close the handle) If we split this to a deinit() close() we will produce a much better code. Having open init deinit close well separated IN the ft2232.c will help us to make the ft2232 interface more robust and more clean. I beg to differ. A layout-deinit() could be added and called from ft22332_quit with minimal changes to the driver. But remember, the open init deinit close ARE NOT ON THE INTERFACE API, That's why they're unnecessary before the API is changed accordingly. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Tue, Jun 7, 2011 at 5:19 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: I suggest to drop this patch and merge a simpler fix for the problem adressed by this patch. Only a few lines of code would need to change. Attached is such a patch. The benefit over Tomek's patch is that it frees not only the allocated buffer but also closes the ftdi handle (as was done in the original patch). Plus I'm not very fond of the infinite-loop-that's-not-actually-a-loop-at-all along with the extra indentation. This patch doesn't use gotos either but another (perhaps even more) neglected construct, like it or not. :) /Andreas From c934a6c697c90fd5b5211f744e6607ae9cb7b848 Mon Sep 17 00:00:00 2001 From: Andreas Fritiofson andreas.fritiof...@gmail.com Date: Wed, 8 Jun 2011 23:58:51 +0200 Subject: [PATCH] ft2232: clean up on error in ft2232_init() Check malloc return value. Close handle and free buffer if init fails late. Reuse ft2232_quit() for this so move it up to avoid a forward declaration. Don't set retval if it's not used. Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/jtag/drivers/ft2232.c | 53 1 files changed, 29 insertions(+), 24 deletions(-) diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c index 8c2382a..a3b87c3 100644 --- a/src/jtag/drivers/ft2232.c +++ b/src/jtag/drivers/ft2232.c @@ -2418,6 +2418,25 @@ static int ft2232_set_data_bits_high_byte( uint8_t value, uint8_t direction ) return ERROR_OK; } +static int ft2232_quit(void) +{ +#if BUILD_FT2232_FTD2XX == 1 + FT_STATUS status; + + status = FT_Close(ftdih); +#elif BUILD_FT2232_LIBFTDI == 1 + ftdi_usb_close(ftdic); + + ftdi_deinit(ftdic); +#endif + + if (ft2232_buffer) + free(ft2232_buffer); + ft2232_buffer = NULL; + + return ERROR_OK; +} + static int ft2232_init(void) { uint8_t buf[1]; @@ -2467,9 +2486,11 @@ static int ft2232_init(void) ft2232_buffer_size = 0; ft2232_buffer = malloc(FT2232_BUFFER_SIZE); + if (!ft2232_buffer) + return ft2232_quit(), ERROR_JTAG_INIT_FAILED; if (layout-init() != ERROR_OK) - return ERROR_JTAG_INIT_FAILED; + return ft2232_quit(), ERROR_JTAG_INIT_FAILED; if (ft2232_device_is_highspeed()) { @@ -2482,21 +2503,23 @@ static int ft2232_init(void) #endif /* make sure the legacy mode is disabled */ if (ft2232h_ft4232h_clk_divide_by_5(false) != ERROR_OK) - return ERROR_JTAG_INIT_FAILED; + return ft2232_quit(), ERROR_JTAG_INIT_FAILED; } buf[0] = 0x85; /* Disconnect TDI/DO to TDO/DI for Loopback */ - if ((retval = ft2232_write(buf, 1, bytes_written)) != ERROR_OK) + if (ft2232_write(buf, 1, bytes_written) != ERROR_OK) { LOG_ERROR(couldn't write to FT2232 to disable loopback); - return ERROR_JTAG_INIT_FAILED; + return ft2232_quit(), ERROR_JTAG_INIT_FAILED; } #if BUILD_FT2232_FTD2XX == 1 - return ft2232_purge_ftd2xx(); + retval = ft2232_purge_ftd2xx(); #elif BUILD_FT2232_LIBFTDI == 1 - return ft2232_purge_libftdi(); + retval = ft2232_purge_libftdi(); #endif + if (retval != ERROR_OK) + return ft2232_quit(), ERROR_JTAG_INIT_FAILED; return ERROR_OK; } @@ -3220,24 +3243,6 @@ static void flossjtag_blink(void) buffer_write(high_direction); } -static int ft2232_quit(void) -{ -#if BUILD_FT2232_FTD2XX == 1 - FT_STATUS status; - - status = FT_Close(ftdih); -#elif BUILD_FT2232_LIBFTDI == 1 - ftdi_usb_close(ftdic); - - ftdi_deinit(ftdic); -#endif - - free(ft2232_buffer); - ft2232_buffer = NULL; - - return ERROR_OK; -} - COMMAND_HANDLER(ft2232_handle_device_desc_command) { char *cp; -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] ft2232: fix memory leak in ft2232_large_scan()
Free the buffer before return. Also check the malloc return value. Perhaps it's not a good idea to exit() on error, but it's in line with the rest of the function. Strange thing with this function is that the allocated buffer doesn't seem to be used for anything. The data read into it doesn't go anywhere. Maybe the entire function is flawed, or is the data really supposed to be discarded? Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com --- src/jtag/drivers/ft2232.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c index a3b87c3..9fb4d48 100644 --- a/src/jtag/drivers/ft2232.c +++ b/src/jtag/drivers/ft2232.c @@ -1142,6 +1142,12 @@ static int ft2232_large_scan(struct scan_command* cmd, enum scan_type type, uint int retval; int thisrun_read = 0; + if (!receive_buffer) + { + LOG_ERROR(failed to allocate memory); + exit(-1); + } + if (cmd-ir_scan) { LOG_ERROR(BUG: large IR scans are not supported); @@ -1341,6 +1347,8 @@ static int ft2232_large_scan(struct scan_command* cmd, enum scan_type type, uint receive_pointer += bytes_read; } + free(receive_buffer); + return ERROR_OK; } -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232: fix memory leak in ft2232_large_scan()
On Thu, Jun 9, 2011 at 8:40 AM, Øyvind Harboe oyvind.har...@zylin.comwrote: Definitely! I'm holding off on this patch in favor of a patch that deletes cruft instead of decorating it :-) I have a soft spot for patches that delete code that nobody understands IF the function is actually used, the allocation is needed to have somewhere to put the data from ft2232_read(). But since the data is discarded and because I can't see how that could be useful (for an in scan), I'm inclined to believe that this ft2232_large_scan() is non-functional and never used. The only call site has a condition that the scan size must be larger than the ft2232 buffer (128KB). Maybe that's never the case in practice? I could try to dig around to see if there's a point in keeping the function around, otherwise post a patch that removes it. I don't know how much time I can spare though so it could be an idea to fix the obvious memory problem right away. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Thu, Jun 9, 2011 at 9:06 AM, Øyvind Harboe oyvind.har...@zylin.comwrote: On Thu, Jun 9, 2011 at 7:29 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: Nit, the construct below is a little bit fancy. I'd prefer splitting it over multiple lines to make it more accessible to the casual reader. That requires adding a lot of brackets. Or just use goto, please, which is clear, simple, well understood, and elegant all at once. :) I think goto is OK sometimes. When it is used to unwind the stack frame and free up resources, in lieu of exceptions and resource tracking it can clean up the code significantly. I'm all for gotos in error handling. In this simple case it wouldn't have made things cleaner and the patch would have grown. Also I didn't want to join the goto-vs-subfunction-flamewar-to-be, so a third option was convenient. :) Main objection is that people are not very used to the comma operator. I don't mind rewriting it using goto if the list feels that would be preferred. The patch uses code duplication and if statements inside the cleanup fn(if (buffer) free(buffer)), which can be avoided using exception handling and resource tracking. In the case of this patch, it looks like the if (ft2232_buffer) free(ft2232_buffer) is a case of conservative programming. I'd much rather have an assert in this case than to have broken code auto-repair and be harder to get right. Duplication? Rather code reuse. Ok, the repeated calls to the cleanup function (or the equivalent gotos, if you want to go that route) would have disappeared using exception handling. But C doesn't have it, so... The if statement was added to make ft2232_quit() a bit more generic so it could be used for all cleanup cases, including the error case where malloc fails. The alternative would have been to add a separate error handling path for that case. And given how often error paths are exercised, it's safer to keep them to a minimum. Note that I'm not holding off committing the patch for the above, as maintainer I'm interested in progress as well as more philosophical coding style discussions. :-) If someone does come forth with an even more cleaner patch, then I'm OK with that. This is now growing into a case-study of how to formulate a patch more than a fix. The openocd community has much to learn about how to formulate patches. As long as there is progress, I don't mind holding off the patch. I'm not in a hurry. There's a lot to do in the ft2232 driver. I have the intention to perform some general cleanup in the near future, will post some thoughts this evening maybe. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] ft2232: Clean up infinite loop condition in ft2232_init()
On Thu, Jun 9, 2011 at 12:12 PM, Peter Stuge pe...@stuge.se wrote: - for (int i = 0; 1; i++) + for (int i = 0; ft2232_vid[i] || ft2232_pid[i]; i++) What's the point? This condition can never become false, or the function would have returned in the previous iteration. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/5] ft2232: Refactor ft2232_init_*() into ft2232_initone()
On Thu, Jun 9, 2011 at 12:25 PM, Peter Stuge pe...@stuge.se wrote: + retval = ft2232_initone(ft2232_vid[i], ft2232_pid[i], more, try_more); This is a good start, but what's with the function name?? How about ft2232_init_{device,interface,ftdilib,hardware,handle,whatever} depending on what the function actually initializes. Another ugliness in my point of view is using the try_more parameter to convey information about the type of success/failure. That's what return values are for. And the more parameter apparently only selects whether the diagnostic should be a warning or an error. Seems the message belongs outside the function, making the parameter useless. This function is supposed to initialize hardware and shouldn't care if the caller wants to retry with another vid/pid or not. I'll put removing those two parameters on my todo-list unless you or someone else pitches in or feels strongly against it. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/5] ft2232: Clean up on ft2232_init() errors after a device has been opened
This together with patch 5/5 is equivalent to my patch, only with gotos. Both patches are perfectly fine with me, although I prefer getting rid of the forward declaration as well. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/5] ft2232: Refactor ft2232_init_*() into ft2232_initone()
On Fri, Jun 10, 2011 at 12:26 AM, Peter Stuge pe...@stuge.se wrote: Andreas Fritiofson wrote: + retval = ft2232_initone(ft2232_vid[i], ft2232_pid[i], more, try_more); This is a good start, but what's with the function name?? Short. And one from one device. As opposed to try to init *all* supported devices, which is what ft2232_init does. ft2232_init really refers to init of the openocd driver, while ft2232_init_{libftdi,ftd2xx} refers to init of the ftdi subsystem including hardware (using either of the libraries). Different inits, hence one and all is not the suitable distinction. How about ft2232_init_ftdi that could be interpreted as initializing the ftdi library, the ftdi chip or the ftdi handle, all of which are true? Another ugliness in my point of view is using the try_more parameter Oh for sure. It was like that when I came here. Maybe small steps is a good idea. Please do send more patches to do further cleanup. Seems the message belongs outside the function, making the parameter useless. Note that I know nothing of the code style in OpenOCD. At least the ft2232 driver seems to consistently output error messages at the lowest level in the call stack, as opposed to letting the highest level (user interface) determine how the error should be handled. I found this quite awkward, but I wanted to make changes that were already some improvements over what was there. I am not saying the patches make things perfect, there's certainly still more to do! The last paragraph was not really a comment on this patch, which is good to go if the name is changed, but rather suggestions for further improvements in the related parts of the code. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Thu, Jun 9, 2011 at 10:17 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello Laurent! :-) On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch laurent.ga...@amontec.com wrote: But before to close the handle we should still be able : -1- to tristate signal High-Z via all the out enable signals used in the specific layout, BUT BUT BUT ONLY if we have entered in the MPSSE mode. The whole driver works in MPSSE mode... (If you have a Amotnec JTAGkey-2 you may verifiy this by checking the external yellow LED. This LED should be OFF after any quit/shutdown) As I explained with the TRST and OMAP in previous message ... I have created simple quit() that sets all port pins high and as input (mpsse command 0x80 0x82) but that did not shut down the yellow led :-( Since the suitable setting depends on the mapping of the GPIOs and the surrounding electronics, the quit function would probably need to be layout specific, as Laurent mentioned. Do you have any other ideas on what should be done on ft2232_quit() except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I can see he is already working out the subject :-) What problem is setting pins to a default state on exit supposed to solve? Are we sure this is what we want? If I make openocd pull the reset line and then quit openocd, I'd expect the target to remain in reset. If I quit openocd while the target is running, I'd expect it to keep on running. How would that work if we make this change? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Fri, Jun 10, 2011 at 1:40 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello Andreas :-) On Thu, Jun 9, 2011 at 11:30 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: I have created simple quit() that sets all port pins high and as input (mpsse command 0x80 0x82) but that did not shut down the yellow led :-( Since the suitable setting depends on the mapping of the GPIOs and the surrounding electronics, the quit function would probably need to be layout specific, as Laurent mentioned. I think setting all pint as input create Hi-Z for them, so his is the safest choice and _should_ produce situation as if the interface was not connected at all... unless interface use some buggy buffer construction where high impedance would cause output to be active. I thought that was what Laurent mentioned... it sounds sensible, but maybe I did some error somewhere... Setting the FTDI pins to Hi-Z is not necessarily the same as setting the pins in the JTAG connector to Hi-Z. There is arbitrary dongle-specific interface logic between the FTDI chip and the connector. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ft2232 layout refactoring plans
Hi all! The recent activity surrounding the ft2232 driver makes it obvious that there are lots of bugfixes and structural improvements that need to be done. Unfortunately, trying to understand the code or even just browsing around in it is complicated by the fact that its cluttered with functions related to the different layouts. I plan to break out all the layout specific code to a separate file, making the remaining core ft2232 code easier to work with. The question is, what's a suitable interface between the layout functions and the core ft2232 functions? As a matter of fact I made the separation one and a half years ago, but never got around to completing the patchset. At the time, everything the layout functions required from the core ft2232 code boiled down to appending to the ft2232 command buffer. Pretty clean and probably a suitable interface, assuming things haven't changed too much. The black sheep, now and then, is the signalyzer layout. Its layout functions uses the ftd2xx API directly, requiring access to the ftdi handle and probably a bunch of other data. Many functions are unimplemented for libftdi. It is also an exercise in code duplication with lots of repetitive snippets of code. Trivial refactoring could reduce the number of lines by half or so. Questions to this list: 1) Since this means moving a lot of code around, it's prudent to ask if anyone have ongoing work that could interfere with a change like this. 2) Any thoughts on the interface between the layout functions and the core ft2232 code? 3) What to do with the signalyzer code? I have no idea what this interface is. Is it used at all? Should we adapt 2) to its requirements or let it remain in ft2232.c? Maybe split it out to a completely separate driver, if it's so different? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Fri, Jun 10, 2011 at 2:18 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Jun 9, 2011 at 11:46 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: Setting the FTDI pins to Hi-Z is not necessarily the same as setting the pins in the JTAG connector to Hi-Z. There is arbitrary dongle-specific interface logic between the FTDI chip and the connector. Not true. Good example here can be KT-LINK SWD+JTAG buffers [1] configuration designed by Krzyszfot Kajstura - all signals can be electrically disconnected from target and they are in default configuration (after powerup). This is really nice design, also the first open SWD+JTAG for FT2232H chip. Interface can also offer additional signals such as various resets and control that also should be disconnected, especially for other transports. Upcoming SWD framework make use of existing ft2232 code, also the ft2232_quit() function, so there is a default possible behavior common to all ft*232-based devices. Thats not that complicated, isn't it? What are you talking about? Not all ftdi dongles are wired like this = there is no universal default setting suitable for all dongles. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 layout refactoring plans
On Fri, Jun 10, 2011 at 2:36 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: Uhm, from what I understand LAYOUT is only used for initialization of specific device based on FT*232 device, maybe other minor stuff, all work is done in fact by queue_flush() and it is common for all devices as it simply translates queued JTAG commands into MPSSE that produces actions on the physical connection between interface and target TAP. Yes they are separate concepts, that's why there's a point in separating them. Having everything in one file is okay for me as there is only one place to look for stuff. Making more files won't increase readability imo its just moving things from one place to another, like women cleanup, then you never know where to look for your stuff ;-P More files won't increase readability, true. Fewer lines of unrelated code will. ft2232.c contains 4434 lines. 2211 of these are layout related, and spread all over the file. 788 of these are for one specific layout, namely signalyzer_h. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] transport selection fix
On Thu, Jun 16, 2011 at 8:02 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Jun 16, 2011 at 5:50 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I take it is just a bugfix? Yes - it changes: retval = allow_transports(CMD_CTX, jtag_interface-transports ? : jtag_only); into: retval = allow_transports(CMD_CTX, jtag_interface-transports ? jtag_interface-transports : jtag_only); Which was obvious mistake or cautious precaution :-) :-) Not true! Your patch doesn't fix a bug, because there is none. a ? : b is equivalent to a ? a : b, unless evaluating a has side-effects or if a is volatile, since it's only evaluated once in the former case and twice in the latter. I don't think jtag_interface-transports is neither volatile nor a macro with side-effects. So, in the name of portability (?: is a GCC extension [1]) and clarity, I'd say this patch is valid, but not for the reasons given in the patch comment. /Andreas [1] http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex M3: Patch for automatic handling of interrupt mask during stepping
Great, but does it really work? There has been discussions about this on this list in the past. I think the conclusion was that there's no way to robustly know GDB's intentions based on the remote commands. When you do a source-level step in GDB, it may send a step command to OpenOCD. Then we can disable interrupts during the step. But it can also place a breakpoint at the next source line and send a continue command. In that case we must leave interrupts enabled. Wouldn't that mean an unpredictable difference in behaviour depending on how GDB chooses to do the step? Note that I haven't yet looked at the patch so this may not be relevant. Regards, Andreas On Sat, Jun 18, 2011 at 4:26 PM, Peter Horn peter.h...@bluewin.ch wrote: Dear all I'm submitting a change to the Cortex-M3 target which improves behavior of single stepping with interrupts. Here's the description of the patch, hope you like it: This patch extends the cortex_m3 maskisr command by a new option 'auto'. The 'auto' option handles interrupts during stepping in a way they are processed but don't disturb the program flow during debugging. Before one had to choose to either enable or disable interrupts. The former steps into interrupt handlers when they trigger. This disturbs the flow during debugging, making it hard to follow some piece of code when interrupts occur often. When interrupts are disabled, the flow isn't disturbed but code relying on interrupt handlers to be processed will stop working. For example a delay function counting the number of timer interrupts will never complete, RTOS task switching will not occur and output I/O queues of interrupt driven I/O will stall or overflow. Using the 'maskisr' command also typically requires gdb hooks to be supplied by the user to switch interrupts off during the step and to enable them again afterward. The new 'auto' option of the 'maskisr' command solves the above problems. When set, the step command allows pending interrupt handlers to be executed before the step, then the step is taken with interrupts disabled and finally interrupts are enabled again. This way interrupt processing stays in the background without disturbing the flow of debugging. No gdb hooks are required. The 'auto' option is the default, since it's believed that handling interrupts in this way is suitable for most users. The principle used for interrupt handling could probably be used for other targets too. Best Regards Peter Horn ___ 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] Cortex M3: Patch for automatic handling of interrupt mask during stepping
Resending, Cc to the list got lost somewhere... On Sat, Jun 18, 2011 at 8:27 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sat, Jun 18, 2011 at 6:38 PM, Peter Horn peter.h...@bluewin.ch wrote: Hi Andreas Am 18.06.2011 17:32, schrieb Andreas Fritiofson: Great, but does it really work? I've tested it with a simple test program containing a main loop and a SysTick_Handler(). I've also tested it with a real application in which UART RX interrupts happen at least once per second (heart beat message of a slave processor coming in). Without the patch, I wasn't able to do stepping, because each step ran into the UART handler. Disabling the interrupts led to blocking because UART output queues overflowed, nothing was received anymore and no RTOS task switching happened. Received data will probably be lost even with your patch, unless you step often enough. With the patch I can do useful work with the debugger again. There has been discussions about this on this list in the past. I think the conclusion was that there's no way to robustly know GDB's intentions based on the remote commands. That's true. You can see what GDB does when you read openocds debug output messages. My comments below are found by observation. When you do a source-level step in GDB, it may send a step command to OpenOCD. Then we can disable interrupts during the step. Step commands are issued by GDB when it doesn't know for sure that the next assembly instruction won't branch. It steps as many times as required until an address is reached which doesn't belong to the current line. Exactly this will happen when a pending interrupt triggers: A branch to the handler and voila, we're on a address that doesn't belong to the line we're stepping, so GDB stops. Only the step command is addressed by my patch: It first lets pending interrupts execute, then disables interrupts, steps over the instruction and finally re-enables the interrupts. I didn't realize you wanted to _execute_ interrupt handlers during step, just not break in them. That's rather brilliant and probably a good default behaviour. But it can also place a breakpoint at the next source line and send a continue command. GDB uses this strategy when it steps over function call, assuming it will return to the next instruction after the call. This is done to speed up things. Instruction stepping takes some milliseconds per step. When GDB uses this method to step, interrupt handlers don't disturb debugging flow because the target isn't stopped before return from the function call. The continue command isn't changed by my patch. In that case we must leave interrupts enabled. Right. Interrupts only get disabled during the step over the next instruction, they are enabled afterward, see above. This is exactly the problem with the GDB hooks to enable and disable the isr masking during stepping. They disable the interrupts in both cases because they act on the GDB step command, not the target step command. My patch acts on the target step command only. The GDB hooks are meant for a different use-case. Sometimes you want to step around and at the same time guarantee that no isr or other code will be run behind your back. Just making sure that the debugger breaks on the expected line may not be enough. That use-case is still available exactly as today, with GDB hooks and maskisr on/off. Which is good. Wouldn't that mean an unpredictable difference in behaviour depending on how GDB chooses to do the step? No. In both cases pending interrupt handlers will be called and in both cases GDB stops on the next line. I see. I assumed you wanted the same behaviour as the GDB hooks use-case. Note that I haven't yet looked at the patch so this may not be relevant. I would be glad if you can try it on a real use case. I've briefly checked the patch now. I won't probably have time to test it anytime soon. But basically it looks good. I guess there's no way around requiring setting a breakpoint at the current pc to force any pending isr to run? Also, will it make stepping significantly slower? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] USB Blaster support broken
On Tue, Jun 28, 2011 at 9:19 AM, Domien Nowicki domien.nowi...@gmail.comwrote: ** 1. The USB Blaster clone does not use the original FT245 chip, and so it tries to emulate its behavior. As it turns out, the API call FT_GetLatencyTimer is not properly emulated by the clone, and this makes OpenOCD abort. In reality, this API call is not necessary, so I have removed this call. Are you sure this is not the bug in FTD2XX on Linux that was mentioned on this list recently? In that case, libftdi shouldn't be affected so it could be left as-is. For ft2232 the error was changed to a warning as a workaround (if that patch got merged), perhaps do the same here? 2. The LED blink code that was added in commit (24943498e611649a540d98406288dd6d4889851d) made the JTAG communication unstable, see http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commitdiff;h=24943498e611649a540d98406288dd6d4889851d. The USB Blaster dongle would properly detect the IDCODE, but would later fail when trying to read/write the DPACC ARM JTAG registers. Not surpringly, this is because the blink code resets the out_value, which keeps track of the state of the JTAG pins. In my tests, disabling or blinking the LED flag made JTAG communication very unstable. This flag needs to be permanently enabled for proper operation. Do you have a clue as to WHY the LED signal must be set for the dongle to function properly? I don't know the internals of the USB Blaster in detail, but it doesn't sound right. For sure, all our USB Blasters blink when used with the Altera tools. No problem there. If out_value keeps state, the blink function is obviously broken, but I don't see why it couldn't be fixed by modifying only the LED bit in out_value. Also, why have you added commented out code? If it doesn't work (it doesn't), don't add it. Of course the better solution would be to make it work. (Hint: fix the bit clear, should be ~LED.) /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] compiler warnings with dsp5680xx.c
On Wed, Jun 29, 2011 at 9:17 PM, Rodrigo Rosa rodrigorosa...@gmail.comwrote: On Wed, Jun 29, 2011 at 12:44 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: This is disturbing. Why switch to global variables? +static uint32_t data_read_dummy; static int jtag_data_write(struct target * target, uint32_t instr,int num_bits, uint32_t * data_read){ int retval; - uint32_t data_read_dummy; i did this to have mem to dump the data read at the time the queue is flushed i do not care about this data, but i need somewhere to dump it (otherwise it'll segfault). multiple instances of the target would not cause trouble, since i do not care about this data, so it could be overwritten and it would no break anything. It should be safe to pass null as read pointer if you want to discard the data from the scan. This is also explicitly stated in dsp5680xx_drscan(). However, jtag_data_write does use the data: if(data_read != NULL) *data_read = data_read_dummy; This doesn't seem right, because the queue hasn't been executed yet and so data_read_dummy has a bogus value. Bug? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 11:35 PM, Øyvind Harboe oyvind.har...@zylin.comwrote: On Wed, Jul 6, 2011 at 11:28 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: mips32_pracc_read_mem casts uint32 to void, so we need to cast it back to uint32. I found no suitable macro in actual sources. Hmm then I think we ought to define one to get this put to bed once and for all... static inline uint32_t uint32_read_unaligned(const void *data) { uint32_t t; // Let's trust the compiler to do something very clever here. memcpy(t, data, sizeof(t)); return t; } Do we really need a memcpy? Trust the compiler: oyvind@fierce:~$ cat test.c #include string.h #include stdint.h uint32_t uint32_read_unaligned(const void *data) { uint32_t t; // Let's trust the compiler to do something very clever here. memcpy(t, data, sizeof(t)); return t; } oyvind@fierce:~$ gcc -O3 -S test.c And with the default optimization level (O2, isn't it)? Could we ever run into an alignment issue when simply cast void *back* to uint32 ? If not, I would prefer the simplifed solution. The below does not work in all cases. It will break on architectures that do not support unaligned access. No, casting a pointer-to-any-type to a pointer-to-void and back will never cause alignment issues. The question is who makes the guarantee that the function is only ever called with uint32-aligned generic pointers. If it just happens to be so that all *current* callers pass a uint32 pointer cast to void pointer, it would be a terribly bad idea to suddenly assume that. If it is guaranteed by design/contract, why is a void pointer used at all? Just use a pointer to uint32 then. I have no experience with the MIPS code or arch at all, but if it was up to me I'd prefer if a *_read_mem function didn't interpret the data and thus it should deal with void pointers. It would by design be totally free from all endian issues and conversions. Moreover, a function accepting a pointer-to-void should be prepared to handle any kind of alignment thrown at it (unless explicitly stated). That excludes direct casts to uint32_t*. That's why GCC is complaining. Sometimes... It should never complain when casting a generic pointer to another pointer, right? You shouldn't even need an explicit cast IIRC. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] eclipse indigo (pipe usage)
On Fri, Jul 1, 2011 at 12:47 PM, Spencer Oliver s...@spen-soft.co.ukwrote: On 1 July 2011 00:41, Andrew Leech coronasen...@gmail.com wrote: One other point, do you know whether you can get openocd to add it's own program directory to the search path for the source [find ...] lines? It'd be great to only need the openocd.cfg file in the eclipse project dir, and have it reference the interface and target files from the common openocd folder. Otherwise I'll likely copy the contents of the files into my openocd.cfg rather than have a copy of target and interface folders in all my project folders. try something like: add_script_search_dir {c:\cygwin\home\soliver\openocd\openocd\tcl} Cheers Spen I wrote a patch to fix this a long time ago, pre 0.4.0 i think. However i didn't test it under cygwin because I don't use it, only msys. It may need some adjustments. Andrew, you didn't say what platform you're on and how you built/installed openocd? The search path should be printed in the debug log, can you look there and see how it differs from where you have the files installed? /Andreas Found the relevant thread(s): http://www.mail-archive.com/openocd-development@lists.berlios.de/msg10145.html http://www.mail-archive.com/openocd-development@lists.berlios.de/msg11678.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development