Re: [Openocd-development] [PATCH] treat warnings as errors

> > Committed. > > Note that treating warnings as errors may well have to stay > non-default. Be prepared for a bit of flak... > > Since you're willing to address issues that are brought up > here, I'm applying the patch to see if we can navigate some > dire straits w/a few patches and then b

Re: [Openocd-development] [PATCH] fix at91rm9200 warning

> > This patch fixes a missing initializer warning in the > at91rm9200 module. > > Cheers, committed Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] fix mingw32 prototype warning

> Spencer, > > The attached patch includes an attempt at fixing the > following warning: > > jim.c: In function `Jim_EnvCoreCommand': > jim.c:11977: warning: function declaration isn't a prototype > > If this doesn't do it, you might explore this one; my patch > is a wild stab in the dark, but

Re: [Openocd-development] [PATCH] fix mingw32 fd_set macro warnings

> > The attached patch is required to work around bugs in the > MinGW32 build. > > For context, the fd_set macros appear to be poorly defined on > MinGW32, causing superfluous sign-compare warnings. The > patch turns it off only when building a) that platform and b) > those files that use th

Re: [Openocd-development] vsllink update and warnings in MinGW

> Hi, > Attachment is the update for vsllink against SVN. > 1. some tweaks > 2. add DMA mode using original vsllink TAP 3. add configure file > I have committed the attached patch. > BTW: > I find that -Werror is added to the compilation option. > And in Cygwin, it's OK. But in MinGW(I'll test

Re: [Openocd-development] Fix in server.c for cygwin

> Subject: Re: [Openocd-development] Fix in server.c for cygwin > > Committed. > > Thanks! > I have also noticed that the new configure options need adding to the texi - if anyone has time that is. Cheers Spen ___ Openocd-development mailing list Op

Re: [Openocd-development] IAP with STM32 Cortex M3

> This is a bit off topic for this list but thought I would ask > since quite a bit of discussion on programming STM32 is here. > > This is in regard to "in-application programming" (IAP) mentioned in > PM0042 Programming manual. Does this mean that your > application running in flash can progr

Re: [Openocd-development] STM32 "reset halt" appears broken

> "reset halt" for STM32 appears to be broken in SVN HEAD... > > I don't know if this is a regression. > > "reset run", "halt", "flash probe 0" works. > "reset halt", "flash probe 0" fails. > > Any ideas? > Not aware of any issues - i can check tomorrow. Cheers Spen _

Re: [Openocd-development] STM32 "reset halt" appears broken

> > What config script and target board are you using? > > > > > I have played a little with the standard scrips but the > interface is basic ft2232 usbjtag layout and nonstandard > vid/pid and Serialnumber string. > > For the target it is the stm32.cfg but the reset config is: > > jtag_nsrs

Re: [Openocd-development] STM32 "reset halt" appears broken

> > It depends. WIth IAR If I don't reset the device correctly > it programs > > garbage. What I found out was that the DMA was still running and > > wiping out some RAM location used by the downloader. With > IAR you have > > the option to reset or not reset the peripherals. > > Perhaps thos

Re: [Openocd-development] STM32 Flash Module Information block

> > Can anybody tell me more about the content and organisation > of the STM32 Flash Module Information block. I have searched > but not found :( > This should help http://www.st.com/stonline/products/literature/pm/13259.pdf Cheers Spen ___ Openocd

Re: [Openocd-development] STM32 Flash Module Information block

> I have tried that one, and found "The area is reserved for use by > STMicroelectronics . . For further details please refer > to AN2606." > > And AN2606 contains how to use instruction but no information > on the actual contents. > > Specifically: How do we know that flash size can

Re: [Openocd-development] missing ltmain.sh? notes on r1695

> This one-time step comes from the addition of the > AC_PROG_LIBTOOL macro. > It will be performed automatically in the bootstrap script > for newly checked out working copies. Sorry for the inconvenience. > Been away for a week and it looks like i missed a busy one !! Just for info the min

Re: [Openocd-development] missing ltmain.sh? notes on r1695

> This one-time step comes from the addition of the > AC_PROG_LIBTOOL macro. > It will be performed automatically in the bootstrap script > for newly checked out working copies. Sorry for the inconvenience. > Any reason for the libtool change? I have also noticed the build takes quite a bit lo

Re: [Openocd-development] Compile issue on mingw on current svn

> 4) This one is blocking, during the compilation of openocd.c, > there is a syntax error around -DPKGBLDDATE=\"`date +%F-%R`\" > I am not sure how to fix it ... > > mingw32-make[3]: Entering directory `c:/Workspace-1/openocd/src' > C:/cygwin/bin/sh.exe ../libtool --tag=CC --mode=compile mi

Re: [Openocd-development] Compile issue on mingw on current svn

> > No, I still have the same problem with r1776. > > there are some uint32_t uses in replacement.h which are not recognized > - I don't have an elf.h system include. > > export CPPFLAGS="-IC:/libusb-win32-device-bin-0.1.12.1/include" > export LDFLAGS=-LC:/libusb-win32-device-bin-0.1.12.1/lib/gc

Re: [Openocd-development] svn head should now be OK again

> > Try using > > > >        libtool gdb ../openocd > > > > or the more pedantic (but future-proof): > > > >        libtool --mode=execute gdb ../openocd > > Once a solution has been identified, it would be nice to have > the BUGS file updated... > > -- for dev work it is often easier to config

Re: [Openocd-development] PIC32 openocd status

> > Gentlemen, > > AFAIK EJTAG is already implemented in OpenOCD (I'm using it for > > another MIPS based SOC to program external flash). I just > don't know > > how complete it is in respect to debugging/single stepping. > The flash > > programming routines for PIC32 are also available in Ope

Re: [Openocd-development] OpenOCD J-link under Windows

> The other choice is to use the libusb-win32 device driver. > In that case, you create the INF using the INF wizard and > replace the stock Segger driver with libusb-win32 device > driver.It works better than the filter driver and works under > Vista 32 bit. But in this case, you can no longer

Re: [Openocd-development] "Short" state table enabled as of r1827

> Does the LPC2148 (which I have) exhibit the same problem? > > I can not test the attached patch here, but it is intended to > allow switching between the long(old) or new (short) > tms_sequence tables. The patch uses the short table as default. > > Try: > > tms_sequence long > tms_sequence

Re: [Openocd-development] pxa270.cfg patch

> This patch also lists the two CPU IDs I've found in testing. > This leads on to two related points about how the CPUTAPID > thing is used. > > 1) How do I specify that a bit is don't care for > -expected-id? As you can see pxas can be (at least) rev 7 and > rev4: 0x79265013 and 0x49265013.

[Openocd-development] [PATCH] mip32 interrupt disable

Hi, The following patch has been in my local tree for a while. It simply brings the mips step/resume interrupt handling inline with the rest of openocd. Tested on svn head using pic32mx target. No objections i will commit. Cheers Spen mips32_int.patch Description: Binary data _

Re: [Openocd-development] "Short" state table enabled as of r1827

> > We want to make OpenOCD robust against the particular path > taken do we not? > > > > > > > This is black jtag controller magic, I have tested short > table for imx21 and omap3530 a lot, seems cortex-m3 does not > like the startup sequences. > Try to change the first row in the short tab

Re: [Openocd-development] "Short" state table enabled as of r1827

> > Hello Øyvind, > > yes the same behaviour with a LPC2148 here. > Does my patch or using tms_sequence long fix the problem? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/list

Re: [Openocd-development] Compile error under Cygwin

> In file included from ../../config.h:264, > from binarybuffer.c:24: > ./replacements.h:213: error: syntax error before "Elf32_Addr" > .. > > replacements.h is included in config.h. > I check the config.h and system.h, types.h is not included. > try running bootstrap a

Re: [Openocd-development] [RFC] How to add FA526 support (problemidentified)

> > Today we have found the problem why previous attempts to > debug FA5226 failed! The reason is that arm9tdmi has > 5 stage pipeline while FA526 6 stage one. > > Currently I have modified arm9tdmi_read_xpsr to do one extra > NOP per command and CPU halted successfully! > Since I am very new t

Re: [Openocd-development] On Resets

> Is there any particular reason why the JTAG layer uses > hardware resets (TRST)? > > I would assume that the most portable way to go to TLR, the > one that works even if all reset lines are missing or are not > yet or incorrectly configured would be to shift out five HIGH > bits which leads

Re: [Openocd-development] Sorry for breaking the thread

> My new emial for openocd is ready, that is > simonqian__DOT__openocd__AT__gmail__DOT__com > > Please remove my current email and add that one. > I have subscribed with my new email. > you have control over that at the following url: https://lists.b

Re: [Openocd-development] On Resets

> > > > If you define your interface with only srst then the > software method > > will be used. > > Well it did last time i checked - see jtag_add_reset for code. > > > > That code makes a move to TLR. This method is fine when you > know in which state you are, but not when OpenOCD is started

[Openocd-development] [PATCH] cortino jtag support

Hi, I have committed the attached patch, simply adds support for the Hitex cortino jtag interface: http://www.hitex.com/index.php?id=cortino Cheers Spen cortino.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@li

Re: [Openocd-development] [patch 0/3] openocd.texi updates

> > Here are more doc updates > > - get rid of most PDF generation errors, like the >"line too long" ones, as well as the "can't do >sane linebreak" warnings > > - restructure flash driver descriptions so each >driver's info is in one place, not scattered >through up to three l

[Openocd-development] meminfo cmd

Hi, I notice that the meminfo cmd seems to be zylin specific (ecosboard.c/ioutil.c). Currently this is in the openocd texi - this should really be removed. Thoughts? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de

[Openocd-development] jlink issues

Hi, I have been running a few tests with regards to jlink support (win32) svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and stm32 target. Connecting using r1192 is ok, just a little slow. The strange thing is if i then connect using r1943 it will work !! Replug the jlink

Re: [Openocd-development] jlink issues

> > svn head (currently r1943) fails when connecting using a > v6/v5.3 jlink > > and > > stm32 target. > > Connecting using r1192 is ok, just a little slow. > > > > The strange thing is if i then connect using r1943 it will work !! > > Replug the jlink and it will fail with r1943, run r1192 > th

Re: [Openocd-development] jlink issues

> -Original Message- > From: Magnus Lundin [mailto:lun...@mlu.mine.nu] > Sent: 29 May 2009 16:42 > To: Spencer Oliver > Cc: 'Dylan Reid'; openocd-development@lists.berlios.de > Subject: Re: [Openocd-development] jlink issues > > Spencer Oliver wrot

Re: [Openocd-development] jlink issues

> > Still it would be very good to know if this is the problem for (at > > least some of) the V6 adapters. > > Unfortunately not mine... I still get a 1 returned (instead > of a zero) as the error code from EMU_CMD_HW_JTAG3, when I > send 8 bits: > > Debug: 191 667 jlink.c:1032 jlink_usb_write

Re: [Openocd-development] [PATCH] Ugly fix for J-Link hard power-on

4 > > Some (all?) V6 firmware on the J-Link adapter fails to step > the TAP unless the first EMU_CMD_HW_JTAG3 command has 8 bits > rather than 7, immediately after adapter power-up. Add a hack > to pad out to 8 bits, the first time only. > I am hoping todo some usb traces today using seggar's

[Openocd-development] [COMMIT] jlink 8bit TLR patch

Hi, I have committed the attached patch to svn. - hack added to fix a issue with v5/6 jlink v5/6 jlink seems to have an issue if the first tap move is not divisible by 8, so we send a TLR on first power up Cheers Spen jlink.patch Description: Binary data ___

Re: [Openocd-development] No flash patch comparator unit availablecortex-m3.c [jlink]

Hi, > > Updated svn to current r2003 and fixed the problems above. > However, don't know why I can't reliably go over jtag_khz 470 > like I could when debugging with the same jlink on the str712 > demo board (arm7tdmi). With the arm7 I could set the jtag > speed to zero (adaptive) and it work

Re: [Openocd-development] [Patch] Fix overrun problems on Cortex targets.

> >> Contents: > >> + change signature for adi_jtag_dp_scan and > adi_jtag_dp_scan_u32 to > >> + use > >> swjdp_common_t *swjdp instead of arm_jtag_t *jtag_info > >> + change SWJDP_IR/DR_APACC to DAP_IR/DR_APACC to conform > with ARM_ADI docs. > >> + add swjdp->memaccess_tck field and code for

Re: [Openocd-development] [Patch] Fix overrun problems on Cortextargets.

> > > >> Contents: > > >> + change signature for adi_jtag_dp_scan and > > adi_jtag_dp_scan_u32 to > > >> + use > > >> swjdp_common_t *swjdp instead of arm_jtag_t *jtag_info > > >> + change SWJDP_IR/DR_APACC to DAP_IR/DR_APACC to conform > > with ARM_ADI docs. > > >> + add swjdp->memaccess_tck fie

Re: [Openocd-development] [patch 2/2] openocd.texi - lowlevel jtagcommands

> > Dumb question: Is there a way to get a printable unified > document from this. I know there is a lot I am missing since > I am not real good at navigating the openocd.info/texi files > using "info" or whatever. try make pdf or make html Cheers Spen

Re: [Openocd-development] [patch 2/2] openocd.texi - lowlevel jtagcommands

> Dumb question: Is there a way to get a printable unified > document from this. I know there is a lot I am missing since > I am not real good at navigating the openocd.info/texi files > using "info" or whatever. > prebuilt docs are available against trunk here: http://openocd.berlios.de/web/?

Re: [Openocd-development] evb_lm3s811 ... don't all those EVBs use thesame JTAG glue?

> The existing doc for "ft2232_layout evb_lm3s811" is unclear > and/or misleading ... can someone clarify? > > Board docs say it supports JTAG in two modes. > > - The one documented for OpenOCD is "pass through" ... the >EVM operates as a $49 (sez DigiKey) JTAG adapter without >TRST, SR

Re: [Openocd-development] [Patch] TAR autoincrement block size and alignment

> >> Hi > >> > >> The number of bits used for TAR autoincrement when using > >> CSW_ADDRINC_PACKED must be at least 10 according to ARM ADI > >> specifications. Cortex-M3 uses 12 bits (4k blocks) and > OMAP35xx uses > >> 10 bits (1k blocks). > >> > >> This patch adds support for different T

Re: [Openocd-development] Cygwin & EOL settings - an idea..

> > Could there be something we could put in the "configure > script" - that > > tells CYGWIN - to behave? > > ie: Perhaps something like the SHELLOPTS thing? > > > > For example - maybe in the "bootstrap" script? > > And in the "CONFIGURE' script? > > And in the Makefiles? > > > > FYI - with SV

Re: [Openocd-development] mips32 bug in target examined wrapper

> The r1962 patch to add a target examined wrapper created a mips bug. > > https://lists.berlios.de/pipermail/openocd-svn/2009-May/000746.html > here is the offending hunk: > > Modified: trunk/src/target/mips32.c > === > --- trunk/sr

Re: [Openocd-development] License

Dominic, I agree with your comments, and feel it is a shame this whole situation has occurred. > 2) The OpenOCD project itself released binaries linked > against FTD2XX on its Berlios page, for example > openocd-cygwin-ftd2xx-20060213.tar.gz. I don't think it's > totally unreasonable to extrap

Re: [Openocd-development] License

> > Against currently. > > The current technical problems are just a tiny bump in the > road compared to the >2000 revisions we have in SVN. > > We need a robust license(GPL is that) and we need to make > sure that all the things we want open stay open. Who's to say > what the effects of an

Re: [Openocd-development] License

> > What is the situation with the ZY1000, I assume that all > modifications > > to the OpenOCD source tree are public, but can you > guarantee that the > > code running on the Zylin1000 does not link to anything that is > > nonopen and thus violates the GPL ? > > zy1000 runs eCos which is G

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

Hi, > -Original Message- > From: openocd-svn-boun...@lists.berlios.de > [mailto:openocd-svn-boun...@lists.berlios.de] On Behalf Of > du...@mail.berlios.de > Sent: 24 June 2009 02:55 > To: openocd-...@lists.berlios.de > Subject: [Openocd-svn] r2381 - trunk/src/helper > > Author: duane

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

> > Added: > >trunk/src/helper/membuf.c > >trunk/src/helper/membuf.h > > Modified: > >trunk/src/helper/Makefile.am > > Log: > > Add a growable sprintf memory buffer library > > > > Modified: trunk/src/helper/Makefile.am > > strok_r is not available on win32 - strok is said to be >

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

> > Spencer Oliver wrote: > > strok_r is not available on win32 - strok is said to be > reentrant on win32. > > Not near a dev pc at the moment so i thought i would point > it out - i > > can make the change later if you do not have time. > > > &g

Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers

> I'm itching to apply any patches on MIPS4K, but I can't > really dive into MIPS support and provide useful feedback > > Part of my job description in OpenOCD is to be a recruiter > and we're desperately short on active MIPS target experts. > > So if anyone out there have opinions about M

Re: [Openocd-development] Dynamic library loading

> > The FT_Read is executed (via a function pointer of course), > and it returns. There is no OpenOCD error (so some status is > returned, the number of bytes is ok, and so on). The function > gets to it's end, but never returns to the caller. Windows > shows "access violation" exception, so I

Re: [Openocd-development] Dynamic library loading

> > you are using the wrong calling convention if this happens. > > Note the WINAPI > > Dude - you rule! That was exactly the problem - I've copied > the typedef for pointers from msdn and the example used > __cdecl instead of WINAPI. > Changing that with your suggestion fixed the problem [; >

Re: [Openocd-development] [Openocd-svn] r2434 - trunk/src/flash

> > Having looked at the same code to fix (what I presume are) > the same "may be used uninitialized" warnings, I am curious > how you managed to trigger these warnings? I have to wonder > if you're using an older version of gcc or a different set of > optimizations. > > --Z > You are cor

Re: [Openocd-development] Getting openocd to compile on cygwin !

> Dear Devepment and support people, > > On "sparkfun" I am following "mifi's" instrutions to a tee. > http://forum.sparkfun.com/viewtopic.php?t=11221 > never the less: > > I took another shot at attempting to compile my own version > of openOCD with ftd2xx. Both attemps on my work laptop >

Re: [Openocd-development] Mingw build

> > I used to build OpenOCD for Win32 with mingw/msys since > svn<100 but I > > could not get it to work any more, there seems to be an > issue with the > > libtool that comes with mingw/msys which is too old. libtool may be > > updated from source [...] > > IMHO, compiling in mingw is *ver

Re: [Openocd-development] Mingw build

> -Original Message- > From: openocd-development-boun...@lists.berlios.de > [mailto:openocd-development-boun...@lists.berlios.de] On > Behalf Of Freddie Chopin > Sent: 03 July 2009 21:20 > To: openocd-development > Subject: Re: [Openocd-development] Mingw build > > Alain Mouette pisze

Re: [Openocd-development] Mingw build

> > Using both works for me but it takes some work getting a > working msys, > > you have to manually make most of the build tools. > > it would be very important to have a detailed howto. As I > said, lots of people will need to build their own OpenOCD > > > It is much easier to use cygwin wi

[Openocd-development] [PATCH] Cygwin build issues and proposals

> On Sat, Jul 4, 2009 at 2:46 AM, Martin > Thomas wrote: > > the build process continued a little bit further but > stopped with an > > error in replacements (don't remember the exact message). > This error > > has been caused by usage of stdint.h typdefs but stdint.h > has not been > > inc

Re: [Openocd-development] Mingw build

> Somehow cross build with ftd2xx and libftdi do not work for > me yet. I just tried the process under Ubuntu 9.04. > > 1) With libftdi, it chocked at the test program building. > With normal build under Linux, it works. > ../trunk/configure --host=i586-mingw32msvc > --enable-maintainer-mode -

Re: [Openocd-development] [PATCH] Cygwin build issues and proposals

> > > > Tested on ubuntu64 9.04 > > I would like to see the #include "types.h" moved into the > #ifndef HAVE_ELF_H block, as that code is creating the > problems. Otherwise, looks good for 0.2.0. > > Cheers, > I have committed this patch (with your suggestion) as this is a bug. Cheers Spe

Re: [Openocd-development] Jlink compilation (./configure) was missingusb.h , svn#2459

> done using: > > svn# 2459 > > ./configure --enable-maintainer-mode --disable-werror > --disable-shared --enable-jlink CC="gcc -mnocygwin" > > It worked until I got "configure: error: usb.h is required to > build some OpenOCD drivers(s) > http://forum.sparkfun.com/viewtopic.php?t=11221 If

Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag

> Author: zwelch > Date: 2009-07-06 12:34:33 +0200 (Mon, 06 Jul 2009) New Revision: 2471 > > Modified: >trunk/src/jtag/jlink.c > Log: > Gary Carlson : > > Fix intermittent J-Link interface startup failures: > - Use usb_reset to ensure selected dongle is in known good state. > - Assert emulat

Re: [Openocd-development] Mingw build

> >>> Somehow cross build with ftd2xx and libftdi do not work > for me yet. > >>> I just tried the process under Ubuntu 9.04. > >>> > >>> 1) With libftdi, it chocked at the test program building. > >>> With normal build under Linux, it works. > >>> ../trunk/configure --host=i586-mingw32msvc > -

Re: [Openocd-development] Mingw build

> > > you should see the following message: > > whether ftd2xx library works... Skipping as we are cross-compiling > > This does not happen unfortunately. > try running bootstrap or autoreconf. what do you get when svnversion is run ? > > I have tested ubuntu 9.04 (64 and 32bit) here and it i

Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag

> > > > For info this breaks my v5 and v6 jlinks (tested stm32). > > Not sure if any one else is having trouble? > > How does it break? > All read/writes fail as the usb handle is invalid after the usb_reset is performed. Perhaps the win32 libusb does a reset whereas the linux one does not? Ch

Re: [Openocd-development] Mingw build

> > I run bootstrap in the trunk directory before running > configure in different build directories. I use separate > directory for different build options (native Linux build for > J-Link, cross build for J-Link, native build for FTD2xx, > cross build for FTD2xx, etc). But this should not m

Re: [Openocd-development] Mingw build

> mc...@ubuntu904:~/Desktop/build/openocd/build-win32-libftdi$ > cat myconfig-win32-libftdi.sh ../trunk/configure > --host=i586-mingw32msvc --enable-maintainer-mode > --disable-shared --enable-ft2232_libftdi > > Log file is attached. > In both your cases a cross compiler is not being detecte

Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag

> >> > For info this breaks my v5 and v6 jlinks (tested stm32). > >> > Not sure if any one else is having trouble? > >> > >> How does it break? > >> > > > > All read/writes fail as the usb handle is invalid after the > usb_reset > > is performed. > > Perhaps the win32 libusb does a reset whereas

Re: [Openocd-development] J-Link Reset Halt Bug

> With jlink on cortex M3 boards (ST Mic), "halt reset" works > OK. But with > STR712 board (ARM7TDMI) it doesn't work and I have to do > "soft_reset_halt". I don't remember the exact failure with > "halt reset" > with ARM7 since I don't have anything setup right now. > just tested with a jl

Re: [Openocd-development] J-Link Reset Halt Bug

> > With jlink on cortex M3 boards (ST Mic), "halt reset" works OK. But > > with > > STR712 board (ARM7TDMI) it doesn't work and I have to do > > "soft_reset_halt". I don't remember the exact failure with "halt > > reset" > > with ARM7 since I don't have anything setup right now. > > > > just

Re: [Openocd-development] J-Link Reset Halt Bug

> > > > strangely however the str912 fails the reset halt using jlink. > > But works fine using amontec/olimex - the saga continues. > > Some devices (str912??) need CLK=0 in idle for reset halt to work. > Thanks, i remember that from before. Thought this was sorted for jlink? Cheers Spen

Re: [Openocd-development] J-Link Reset Halt Bug

> > We have an STR712 board by Olimex but (actually, an IAR > kickstart board). We can do the "halt reset" with no errors > but it does not do a clean reset (the PC does not go to > zero). With soft_reset_halt it does go back to zero. There > are no errors logged in either case. > soft_reset

Re: [Openocd-development] J-Link Reset Halt Bug

> > > > This is why people often put a small reset delay in the > startup file > > for the > > str7 to compensate for this. > > Last I checked there was a str710.cfg file which we use. How > do you set his "small reset delay" you speak of? Would this > be jtag_n[st]rst_delay? Should this be

Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag

> You asked me what the result of Spencer's patch was under Mac > OS X. I tested it against my system this evening and as you > will see below, it caused a number of startup faults. It > also appears to make the j-link dongle completely > unresponsive thereafter. > > I guess the bigger quest

Re: [Openocd-development] Version 3 test patch for jlink.c

> Zach/Spencer/Xiaofan, > > I did some more experimentation on the latest subversion > (2499) and was able to tweak the jlink.c code slightly to > possibly achieve three objectives: > > 1. Make jlink dongles work under Windows for Spencer. > 2. Make jlink dongles work under Mac OS X for me. >

Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag

> > Hi Spencer, > > I will do some more digging. It sounds like you have a > Windows test platform. Was the intermittent startup issue > ever a problem on this operating system? > Not that i noticed - if i just remove the usb_reset all seems well. Cheers Spen ___

Re: [Openocd-development] Version 3 test patch for jlink.c

> > It is starting to look like there is no single solution that > will fix all OS issues with respect to this issue. I am > starting to think it is time to turn to conditional > compilation directives. > > Any thoughts, comments, or reservations? > Its looking that way - try the attached.

Re: [Openocd-development] Version 3 test patch for jlink.c

> > A minor fix needs to be done as I mentioned before. > usb_init(); needs to be moved up to the helper function > find_jlink_device(void) (before the line usb_find_busses();) > http://libusb.sourceforge.net/doc/examples-code.html > > Could you rework the patch? Thanks. > Why does it? usb_in

Re: [Openocd-development] Version 3 test patch for jlink.c

> > If they give a thumbs up, would you agree that committing the > patch makes the most sense at this point given what we know > today about libusb? > Looks good to me - only had time to test win32 however. Cheers Spen ___ Openocd-development mail

Re: [Openocd-development] Version 3 test patch for jlink.c

> > I will ask again in the libusb mailing list. > > Here is the answer from Alan Stern (Linux USB kernel > developer) in the libusb mailing list. > http://article.gmane.org/gmane.comp.lib.libusb.devel.general/6569 > "If the reset causes the device to disconnect and reconnect > or change its de

Re: [Openocd-development] SRST/TRST Question

> Based on some initial testing it looks like the what the code > thinks the state of the JTAG state machine is verses what it > is inside the processor are two different things following reset. > > There are some other relevant details about this board worthy to note. > First this particular b

Re: [Openocd-development] libusb-win32 svn released as 0.1.12.2

> >> PS: The best is if the OpenOCD project get a wiki page, > where other > >> one can add information too? > >> > > > > I agree. > > > > Actually there is one Wiki for OpenOCD. > http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger > > The content is a bit old though. Maybe

Re: [Openocd-development] SRST/TRST Question

> > Still Spen could commit Gary's V3 J-Link patch to fix the > problem for Windows users. > https://lists.berlios.de/pipermail/openocd-development/2009-Ju > ly/009438.html > commited as rev2513 Cheers Spen ___ Openocd-development mailing list Openoc

[Openocd-development] dump_image buffer question

Hi, I have just spotted that we use a block size of 560bytes for the dump_image cmd. This cmd as such has not been changed since the original svn import. I will look into speeding this up unless anyone know's a reason why 560bytes are used? Cheers Spen ___

Re: [Openocd-development] [Openocd-svn] r2514 - trunk

> Modified: >trunk/configure.in > Log: > Make the parport-ppdev option enabled by default. This may > require giving --disable-parport-ppdev to configure on some > platform(s). > > Any reason why as it breaks win32 build - why not leave as disabled by default? Cheers Spen __

Re: [Openocd-development] [Openocd-svn] r2514 - trunk

> On Tue, 2009-07-14 at 10:11 +0100, Spencer Oliver wrote: > > > Modified: > > >trunk/configure.in > > > Log: > > > Make the parport-ppdev option enabled by default. This > may require > > > giving --disable-parport-ppdev to configure on

Re: [Openocd-development] [Openocd-svn] r2514 - trunk

> > In this respect, I think all of the drivers should be enabled > by default. Developers could disable them by choice, but > their underlying libraries are being detected such that we > can add new checks to disable the drivers when their > dependencies are missing. > > The goal is to allow

Re: [Openocd-development] Charset choice for OpenOCD

> Committed. > > These are the Eclipse settings w/Cp1252 charset. > > Perhaps the charset should be defined/documented otherwise, > but it's nice to have the these settings saved for those(me > :-) that use Eclipse to check out and work on OpenOCD > This also changes my personal setting'

Re: [Openocd-development] Charset choice for OpenOCD

> > > > This also changes my personal setting's when using ecplise - can we > > revert this patch? > > Yes and no. > > We should choose *one* charset that is the standard charset, > no matter which charset that is. > > I don't care what charset it is, much. > > Choosing a charset is not the

Re: [Openocd-development] [Openocd-svn] r2543 - trunk/src/target

A few comments as i have not had time to look over the original patch. > * What the Core Debug facility exposes is > *implementation-specific* >not architectural. These values aren't fully > portable. They match >Cortex-M3 ... so no current implementation will make > trou

Re: [Openocd-development] [Openocd-svn] r2543 - trunk/src/target

> -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: 16 July 2009 17:29 > To: Spencer Oliver > Cc: openocd-development@lists.berlios.de; zwe...@mail.berlios.de > Subject: Re: [Openocd-development] [Openocd-svn] r2543 - > trunk/src/targe

Re: [Openocd-development] [Openocd-svn] r2543 - trunk/src/target

> > > > The code is in cortex_m3.c. > > The original code used 4 virtual regs to let the user see > each special > > register. > > I didn't see anything to morph the "real" register into four > "virtual" ones though... the code was treating it as having > for unique DCRSR identifiers, which i

[Openocd-development] dual cfi flash

Hi, Before i start diving in, has anyone attempted to use openocd cfi driver with a similar config: data nor flash (2x8MB total 16MB - one lower 16bit data, the other upper 16bit data) connected on a 32bit mcu data bus? Some changes will be needed, just wondering if anyone has attempted this. It

Re: [Openocd-development] [Openocd-svn] r2543 - trunk/src/target

> > I have just tried to change CONTROL[0] using reg 20 > 0x100, it fails. > > The cause is the array issue i mentioned earlier, this is > working in > > the previous code. > > > > The read is done in the function > cortex_m3_load_core_reg_u32 and num > > will only ever be 20. > > Before

[Openocd-development] [PATCH] cfi device id

Hi, Attached is a patch to fix two cfi.c bugs i found recently. The first on the device id looks like it has been present while, since the changes to using flash_address anyway. The second fixes a check on total memory. Any objections to committing? Cheers Spen cfi.patch Description: Binary d

Re: [Openocd-development] [Openocd-svn] r2543 - trunk/src/target

> > > > Since we're back in normal development and you have a good track > > record of producing great work, I felt it was safe to push > these into > > the repository for testing. I know patches to fix problems would > > follow if they proved to be needed. Should I have held off longer? >

  1   2   3   4   5   6   7   >