Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

Merged(+ some changes, see below). On Wed, Dec 8, 2010 at 7:55 AM, Peter Stuge wrote: > Øyvind Harboe wrote: >> If the JTAG speed has not been set, then it has no defined >> value, add code to propagate the error. >> >> Signed-off-by: Øyvind Harboe > .. >> +++ b/src/jtag/core.c >> @@ -1384,9 +13

Re: [Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()

Paul Richards wrote: > +++ b/src/jtag/core.c > @@ -296,27 +296,25 @@ int jtag_register_event_callback(jtag_event_handler_t > callback, void *priv) > > int jtag_unregister_event_callback(jtag_event_handler_t callback, void *priv) > { > - struct jtag_event_callback **callbacks_p; > - str

Re: [Openocd-development] Bug in core.c::jtag_unregister_event_callback()

Hi Peter, I just saw your mail after submitting a patch. I kept the double pointer usage for consistency but simplified the logic. On 2010/12/08 15:35, Peter Stuge wrote: Should it? I don't think the following callback should be skipped just because the current one is removed. I believe y

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

> From: Øyvind Harboe > > The error is propogated to the point that openocd exits with the error >> message. > > So, if I have not missunderstand  something, I think the desired end > > effect is already reached. > > I'm not quite sure what you mean. jtag_get_speed() doesn't propagate > errors tod

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

Øyvind Harboe wrote: > If the JTAG speed has not been set, then it has no defined > value, add code to propagate the error. > > Signed-off-by: Øyvind Harboe .. > +++ b/src/jtag/core.c > @@ -1384,9 +1384,13 @@ int adapter_init(struct command_context *cmd_ctx) > > int requested_khz = jtag_g

[Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()

Fix for issue described in the following mail https://lists.berlios.de/pipermail/openocd-development/2010-December/017479.html From c78f5203622438e73580c327a6e55a0df17b85a8 Mon Sep 17 00:00:00 2001 From: Paul Richards Date: Wed, 8 Dec 2010 15:48:55 +0900 Subject: [PATCH] Fix for segmentation fa

Re: [Openocd-development] Bug in core.c::jtag_unregister_event_callback()

Paul Richards wrote: > 307 for (callbacks_p = &jtag_event_callbacks; > 308 *callbacks_p != NULL; > 309 callbacks_p = next) .. > 311 next = &((*callbacks_p)->next); > ... > 316 if ((*callbacks_p)->callback == cal

Re: [Openocd-development] Bug in core.c::jtag_unregister_event_callback()

Hi Øyvind On 2010/12/08 3:58, Øyvind Harboe wrote: Looks like bugs indeed... How did you come across them? The processor I am using (PXA16x) has TAPs (including the CPU TAP controller) that must be switched in via the default TAP. When I enabled the CPU TAP post-init the enable event callb

Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts

Hi, Freddie Chopin wrote: > I've CCed Peter Stuge, as he's another person that has different > opinion on this subject than official version from NXP. Thanks. I have had significant development issues both with LPC2148 and LPC1768 having reset_config srst_pulls_trst in their target files. It wa

Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.

you mentioned using an RTOS. Stepping on Cortex-M works poorly with a common OS feature: Use of the WFI (or WFE) instruction stops the core so that you can't get at it using JTAG.(It saves power, but in a way that complicates debugging.) My baby Cortex-M RTOS has a build/coonfig option for

Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts

On 12/07/2010 09:40 PM, Freddie Chopin wrote: > reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain I tested the srst_gates_jtag instead of the srst_pull_trst option on the only LPC2000 board that I have here available at home. It works fine on this board despite

Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts

I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. On 2010-12-07 20:45, Rolf Meeser wrote: The problem is that in fact LPC2000 targets need the srst_pulls_trst option. Your claim is: "The srst_pulls_trst option doesn't apply

Re: [Openocd-development] Getting rid of default jtag clock rate

On 12/07/2010 10:39 AM, Laurent Gauch wrote: > Will be never good. A JTAG frequency is not only board specific, but > wire (cable length) dependent, buffer dependend, dongle dependent > Too many parameters !!! Chip, dongle, board configs could supply max values (and OpenOCD would have to selec

Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts

On 12/07/2010 05:16 PM, Freddie Chopin wrote: On 2010-12-04 15:47, Freddie Chopin wrote: This is directly related to the findings from this post: https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html I've only removed srst_pulls_trst and comments that mentioned th

Re: [Openocd-development] Bug in core.c::jtag_unregister_event_callback()

Looks like bugs indeed... How did you come across them? > I have fixed and verified on my build but am unfamiliar with submission > procedures.  I'm happy to contribute with a little guidance. 1. Get the latest version from git 2. checkout the master branch git checkout origin/master 2. Modi

Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.

On Tue, Dec 7, 2010 at 5:13 PM, Freddie Chopin wrote: > On 2010-12-03 23:27, Ian Lambert wrote: >> >> Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY >> Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and >> I've noticed some major problems with stepping

[Openocd-development] Bug in core.c::jtag_unregister_event_callback()

Hi, I believe I've found a bug or two in jtag_unregister_event_callback(). 273 int jtag_register_event_callback(jtag_event_handler_t callback,

Re: [Openocd-development] Problem loading to CFI flash

On 06/12/2010 14:42, Jonathan dumaresq wrote: Have you fond some time to test this ? I have run a quick test and it fails for me also. As a quick test i commented out block writes (cfi_write_words) and it works as expected - albeit even slower. Also found this patch where they have disable

Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts

On 2010-12-04 15:47, Freddie Chopin wrote: This is directly related to the findings from this post: https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html I've only removed srst_pulls_trst and comments that mentioned that (and comments that were not very helpful) So

Re: [Openocd-development] Problem loading to CFI flash

Hi Spen, I'm happy that i'm not the only one !!! Is it possible to send or put somewhere a windows version that works ? I have never compiled openocd so, if you can provide the binary file i'll be happy. If not I can try to compiled it too. Regards Jonathan Spencer Oliver wrote: > On 06/12/2010

Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.

On 2010-12-03 23:27, Ian Lambert wrote: Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and I've noticed some major problems with stepping in GDB. If it's of any help, I am using the Codesourcery arm-2009

Re: [Openocd-development] Problems stepping in GDB on the luminary lm3s6965.

On Fri, Dec 3, 2010 at 11:27 PM, Ian Lambert wrote: > Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY > Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and > I've noticed some major problems with stepping in GDB. > > If it's of any help, I am using the C

[Openocd-development] Problems stepping in GDB on the luminary lm3s6965.

Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and I've noticed some major problems with stepping in GDB. If it's of any help, I am using the Codesourcery arm-2009q3 toolchain. I'd appreciate any help. I

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

> The error is propogated to the point that openocd exits with the error > message. > So, if I have not missunderstand  something, I think the desired end effect is > already reached. I'm not quite sure what you mean. jtag_get_speed() doesn't propagate errors today, it should and the patch fixes

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

> -Original Message- > From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] > The patch doesn't actually do anything other than add propagation of error, > which needs to be in place at some point down the line. > > It's basically a big no-op patch so that the next patch that *does* someth

[Openocd-development] How to reflash OMAP35x on a beagleboard.

Hi. I'm interesting in reading into a PC and then re-flashing the OMAP3530 POP NAND on a beagleboard rev C3. Can somebody help me with is the correct procedure? I am a little wary of ruining the board, and the search I did on the web so far was less than conclusive on the matter. I saw s

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

> -Original Message- > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe > Sent: Monday, December 06, 2010 10:30 PM > To: openocd-development@lists.berlios.de > Subject: [Openocd-development] [PATCH] jtag:

Re: [Openocd-development] [PATCH] jtag: getting the JTAG speed can fail

The patch doesn't actually do anything other than add propagation of error, which needs to be in place at some point down the line. It's basically a big no-op patch so that the next patch that *does* something will be that much smaller. Your patch seems more orthogonal to this one. -- Øyvind Ha

Re: [Openocd-development] Getting rid of default jtag clock rate

All device vendors should provide BSDL files for their devices which specify the maximum TCK speed the device can support. This can be used to create an auto-configuration that is fairly easy to use and robust. An example of this is the Xilinx programming tools. They do an initial shift at a l

Re: [Openocd-development] Getting rid of default jtag clock rate

1MHz is just as bad as as default as 30MHz. It may work in more cases, but it is still broken in some. As I said before the 1Mhz startup frequency could be 10kHz. The important is not the value of the startup frequency, the important is to know we have a startup frequency !!! IMHO, there ar