Hello Martin!
If you are using the libftdi and FT2232H version, make sure you have
latest libftdi - with older version (ie. 0.14) you will have problems.
Regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing li
Guys in a month or two I'll be ready for action! I've got the required
equipment already (STM32Primer{1,2}, KT-LINK, ... ), just need some
free time. Currently I'm hardly fighing deadlines! :\
Best regards!
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_
Hello Freddie!
On Fri, Jul 16, 2010 at 11:14 PM, Freddie Chopin wrote:
> Hoping for soon-to-come SWD support in OpenOCD I'm wondering about an
> adapter and/or modification of JTAG schematics. Analyzing the schematics of
> existing JTAG/SWD interfaces gave me nothing more than a headache (who dra
Hello all :-)
On Tue, Jul 20, 2010 at 10:22 AM, simon qian
wrote:
> New Versaloon driver is ready, including JTAG, SWD,
> USART, SPI, IIC, GPIO(SRST and TRST control),
> ADC(target power sampling), POWER(outout power to target)
> and so on. The new driver is based on USB_TO_XXX
> protocol and can
Hello Øyvind!
On 8/27/10, Øyvind Harboe wrote:
> Presumably one of the benefits of trace would be to
> be able to step back/forth.
Stepping back can be hard to implement in efficient way...
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
__
Hello SerialWireDebuggers! ;-)
>From what I see on other posts, a release might be coming with the end
of the year... if its not the bugfix release 0.4.1, then I thought
that this might be a good occasion to intensify SWD works to make it
work with 0.5.0!
What is the current work status? Who is c
Hello Øyvind! :-)
On Thu, Oct 7, 2010 at 3:27 PM, Øyvind Harboe wrote:
> the official position of the maintainers is that we want a maintainable,
> documented SWD implementation or none at all.
Good approach, totally agree on this! :-) I have just started
http://sourceforge.net/projects/stm32pri
On Thu, Oct 7, 2010 at 4:38 PM, Laurent Gauch wrote:
> Yes, you 're right . SWD is not incremental changes since it touch the low
> layers of the OpenOCD.
> Amontec Team is working on SWD too, and have some first communication
> results. But the "How-to" integrate correctly this new Serial Wire De
Hello Peter!
On Sat, Oct 9, 2010 at 10:14 PM, Peter Stuge wrote:
> Tomek CEDRO wrote:
>> What are the current approaches of independent SWD implementations?
>
> Maybe Simon could also mention something about his USB-to-XXX method
> of doing SWD with the Versaloon.
Thank you
Hello David, nice to hear from you! :-)
On Mon, Oct 11, 2010 at 2:29 AM, David Brownell wrote:
> From: David Brownell
> Subject: initial SWD transport (SWD infrastructure #2)
>
> This piggy backs on JTAG so it's not yet pretty, but that
> seems unavoidable so far given today's OpenOCD internals.
Hello Nived, Hello OCD'ers :-)
On Wed, Oct 20, 2010 at 9:39 PM, Nived wrote:
> Hi,
> We have hacked (connected jtag pins on the processor manually to create a
> jtag port on the board) an stm32 primer2 that uses an stm32f103vet6
> processor. When we try to start the server, we are getting the fo
ng on in stm32primer{1,2} and KT-LINK SWJ
cable based on FT2232H. I want it all to work by end of year :-)
Please take a look at poject website: http://stm32primer2swd.sf.net
Best regards,
Tomek Cedro
On 29 Nov 2010 14:15, "simon qian" wrote:
> How is going on SWD support?
> I ha
...however I can understand the urge to have stable release done. If the
GIT repository contains mainly bugfixes, then maybe it is time to freeze it
as 0.4.1, so we can release 0.5.0 with SWD suport as planned - anyway it
will probably happen soon when the SWD is already implemented and tested..?
The SWJ cable that I have use tdi and tdo pins anyway but the buffers are
more complex, maybe there is a simple way to make jtag only cable swd aware,
i have some other cables so after the base is working we can give a try on
that :-)
Best regards
Tomek
> On 2010-11-29 14:44, Tomek CEDRO wr
Maybe this is good idea to increase the build number at least every half a
year - this could help keeping packages up to date and even make development
faster and more accurate as there would be some predefined deadline for
testing and this can be good motivator :-P
Best regards
Tomek
On 30 Nov 201
30 Nov 2010 08:46, wrote:
> "David Brownell" napisał(a):
>
> > Plans are still: (i) merge framework code first,
> > hold the FT2232/Luminary driver code till la...
> Have you synchronized your work with that of Tomek Cedro? There is a big
> chance that Tomek
On 30 Nov 2010 08:46, wrote:
> >
> > "David Brownell" napisał(a):
>
> >
> > > Plans are still: (i) merge framework code first,
> > hold the FT2232/Luminary driver code till la...
>
>
> >
> > Have you synchronized your work
>
> > Have you synchronized your work with that of Tomek Cedro?
> It should go the other way around. The only part of my work that's not yet
> been public is a driver that first needs test-time; OpenOCD integration has
> been on-going. Nobody has bothered asking any
> technic
On Mon, Dec 6, 2010 at 12:35 AM, Rolf Meeser wrote:
> On 12/05/2010 11:00 PM, Freddie Chopin wrote:
>> So how about this idea of removing useless and wrong occurences of
>> srst_pulls_trst from lpc config files?
>
> If your findings were correct, you would have discovered an easy way to
> circumve
On Mon, Dec 6, 2010 at 5:43 PM, Nick Pelling wrote:
> (...)constructing a suitable target cfg file for it. I've asked Samsung for
> documentation listing all its JTAG codes, but that may take some time to
Hello Nick, the other problem is that Samsung may want you to sign the
NDA and keep quiet ab
On Mon, Dec 6, 2010 at 5:43 PM, Nick Pelling wrote:
> (...) constructing a suitable target cfg file for it. I've asked Samsung for
> documentation listing all its JTAG codes,
Btw. have you tried UrJTAG and the "discovery" command - it helps
finding such registers on unknown devices :-)
--
CeDeR
I am interested in uploading uboot into blank flash on similar device
too, so waiting for thread to spread ;-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlio
Hello Openers! :-)
Today is my birthday so I want to share promised draft of the libswd,
that is now available at
http://files.tomek.cedro.info/electronics/arm/cortex/libswd/ ;-)
I forgot power supply for my laptop so was not able to put it on the
sourceforge and document with doxygen as planned -
Hello David!
On Sat, Dec 25, 2010 at 3:07 AM, David Brownell wrote:
>> http://files.tomek.cedro.info/electronics/arm/cortex/libswd/
>
> I took a quick look. Two comments:
>
> Looks at first glance like it might help
> write some types of bit-level SWD driver
> (not ones that use higher level co
On Sat, Dec 25, 2010 at 3:17 AM, David Brownell wrote:
> Also, as promised some time back I'll soon
> commit my second SWD "framework" patch. The
> build issues with mainline OpenOCD have now been
> resolved; framework patch got updated; and it passes
> sanity testing. BUT ... SWD won't yet be f
On Tue, Jan 11, 2011 at 5:02 PM, simon qian wrote:
> Hi,
> I'm back for SWD, I have about 3-5 weeks holiday(hope my company will not
> call me back at holiday).
> So I can prepare for the Versaloon SWD driver in OpenOCD.
>
> Is the SWD transport usable now in OpenOCD?
Hello Simon! :-) Not yet usa
On Wed, Jan 12, 2011 at 8:52 AM, David Brownell wrote:
>> From: Peter Stuge
>> Subject: Re: [Openocd-development] SWD progress
>> To: openocd-development@lists.berlios.de
>> Date: Tuesday, January 11, 2011, 11:06 PM
>> simon qian wrote:
>> > SWD in Versaloon is based on operation.
>> > For exampl
Hello Simon :-)
On Wed, Jan 12, 2011 at 6:57 PM, simon qian wrote:
> When SWD is initializing, in swd_select, get_current_target is called.
> But maybe target is not initialized here.
> Log:
> Warn : 25 47 transport.c:127 allow_transports(): must select a transport.
> Debug: 26 47 transport.c:130
On Wed, Jan 12, 2011 at 1:38 PM, simon qian wrote:
> For SWD transaction layer, only 3 operation is needed.
> 1. initializaion/finalization/config(set trn)
> 2. output sequency on SWD, which is used to make adi into SWD mode.
> 3. The other is the transaction itself, including read and write opera
On Tue, Jan 18, 2011 at 10:26 AM, simon qian
wrote:
> I have fixed the patch for OpenOCD to support SWD of Versaloon, but not on
> the transport framework.
> I'll then try the transport framework.
> One question:
> How to define the trn in the configuration file?
Hello Simon! In libswd TRN is yet
On Tue, Jan 18, 2011 at 1:18 PM, simon qian wrote:
> In my implementation of SWD in OpenOCD, trun is configured in configuration
> files.
Nice! :-) OpenOCD has already great infrastructure implemented and it
will surely allow many other transport implemented. Maybe it would be
convenient to separ
On Sat, Jan 22, 2011 at 2:03 PM, simon qian wrote:
> According to the feedback of my patch for SWD. I was busy fixing these
> feedback these days.
> I found that dap_to_jtag is not called. So it will be problem to operate
> JTAG after operating SWD.
> In my opinion, dap_to_jtag should be not be ca
On Sat, Jan 22, 2011 at 2:15 PM, simon qian wrote:
> For helping the implementation of SWD transport, I can provide 2-3 Versaloon
> hardwares.
> The SWD driver is implemented, so people can concentrate on higher layer,
> and you don't need to add the driver into git.
> And after the SWD driver of
Hello Luca!
On Sat, Feb 12, 2011 at 12:54 PM, Luca Ellero wrote:
> dap_ap_select was used in the code at various points, but that can lead to
> confusion, without any knowledge of what AP is really selected at some
> points. (...)
This is also somehow related with the TRANSPORT and DP system tha
Good news - I have managed to perform bidirectional communications
with the STM32(Primer2) using ft2232h device (kt-link) + libswd
incorporated into urjtag using its drivers!
I had some hard time recently caused by incompetent people at ARM
writing documentation - even most "up to date" documentat
On Tue, Mar 8, 2011 at 2:01 PM, Jean-Claude Repetto wrote:
> Thanks for your answer. Unfortunately, the EFM32 has only a SWD debug port,
> no JTAG. So, unless Openocd supports SWD very soon, I'll have to use an
> external adapter.
Hey hey! SWD transport is now functional for FT2232H chip (KT-LINK
Hello world :-)
On Mon, Mar 21, 2011 at 3:00 PM, Øyvind Harboe wrote:
> In terms of maintenance we can't really support
> two files that are so similar, so unless I hear major
> objections, I'd rather go with this patch and sort
> out any regressions afterwards.
Maybe those two files are similar
On Tue, Mar 22, 2011 at 6:22 AM, Øyvind Harboe wrote:
> cortex a8 and a9 are very similar, so they should be merged and
> conditional code used + configuration options.
>
> cortex m3 is more mature(hence breakage is more of an issue) and
> much more different so merging *all* cortex code is furthe
On Sat, Apr 2, 2011 at 7:04 AM, Øyvind Harboe wrote:
> I've pushed a fix for the ti_pandaboard.cfg file.
> Anyone out there who can give it a try?
I should have one in some time - I will let you know when I get it (~month?) :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.in
On Tue, Apr 5, 2011 at 9:26 AM, Xiaofan Chen wrote:
> As I have seen this tangentally mentioned already a few times
> publically, I figured it warranted it's own announcement now.
>
> Linux has lost a great developer with the passing of David Brownell
> recently and he will be greatly missed.
WHA
On Mon, Apr 11, 2011 at 1:05 PM, Øyvind Harboe wrote:
> In target.c, I'm wondering if we should modify the code to execute
> the same code path and have support for no new packages, unless
> the target->rtos is initialized.
Hello! This modular design of OpenOCD is so awsome when I look at it
now
Hello Michael!
Awsome work and it extends functionality without destroying old ones!
I really enjoy OpenOCD day by day :-) Maybe it would be more
convenient to be able to set bp/wp for each core/target, but this is
minor issue :-)
Best regards! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.ced
Great work Drasko!
This document should be included into openocd source tree to help mips
developers, and probably to some world-wide-web location as it offers
many practical information :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Thu, Apr 14, 2011 at 10:59 AM, Drasko DRASKOVIC
wrote:
> (..)
> After this it can be replicated on any WWW location.
> At least we have it now in lists archives. That's better than nothing ;).
There are or will be people looking for the answers you/we already
know, especially the details hard
Exactly - such wiki is not to replace documentation/manual, but rather
gather konwledge about embedded systems, especially useful for
developers, and so developers have scratchpad for their own
subprojects (ie. http://wiki.freebsd.org/ or
http://stm32primer2swd.sf.net)
Best regards! :-)
Tomek
--
On Thu, Apr 14, 2011 at 11:52 AM, Øyvind Harboe wrote:
> If you look at the OpenOCD documentation, you'll find that Zach Welch
> did write up development documentation and that it's in git repository.
Hello Øyvind! How about creating open and centralized knowledge-base
about embedded systems as a
On Thu, Apr 14, 2011 at 2:02 PM, Øyvind Harboe wrote:
> I don't particularly like wiki's as they would not be in sync with the
> git source
> code.
> What's wrong with updating the documentation in OpenOCD git?
No no, its not about doubling the manual! The manual is built up from
the doxygen and
Hello!
While I am working on integration libswd with openocd, it turned out
that OpenOCD needs some restructurization in source tree and API
standarization, so I have made some changes in my local repository
[1]. Please take a look and let me know if my proposition is okay so I
can move forward an
On Wed, Apr 27, 2011 at 9:43 AM, Øyvind Harboe wrote:
> Scripts would be encouraged by the default low speed to have
> an adapter_khz command to set a more approperiate default
> for that board.
>
> Further down the road, I was thinking about modifying OpenOCD
> to have *no* default speed and have
On Wed, Apr 27, 2011 at 10:08 AM, Øyvind Harboe wrote:
> (...)
>> So I think having no default and forcing the user to specify a value
>> might be the way to go.
>
> Agreed. If we could have that patch first and not go the detour of
> a fixed default across all interfaces, then that would be
> my
Hello Sebastien :-)
On Tue, May 10, 2011 at 3:33 PM, Sébastien Baillou
wrote:
> (..)
> 1- Currently, multiple CPUs are connected to the GDB clients via multiple
> GDB servers and not via GDB threads. Is the addition of a threaded GDB
> server planned in any roadmap ?
I am afraid with current int
On Thu, May 12, 2011 at 7:13 PM, Øyvind Harboe wrote:
> What would this do?
" TCF is intended to become a replacement for protocols like the GDB
Serial, WDB, and GDB/MI protocols used for embedded software
development.
On top of the protocol specification, which is the core of TCF, the
initial c
On Mon, May 16, 2011 at 8:32 AM, Øyvind Harboe wrote:
> One thing that would help greatly for someone wanting to review
> your patch is that you wrote it as a full, normal git patch with a comment.
Totally agree that there should be some systematic approach to
development and patching of the Open
On Wed, May 18, 2011 at 8:52 AM, Øyvind Harboe wrote:
> The position of a release master is open. Nobody has stepped up.
>
> The build scripts are there. David Brownell did 0.4.
>
> We're pretty much ready to cut 0.5 and could probably cut a release
> per quarter.
Maybe 0.4.x first as everything
On Sat, May 21, 2011 at 10:22 AM, Øyvind Harboe wrote:
> For now we just continue to make incremental improvements to
> openocd as they arrive. If good patches for swd or general refactoring,
> rinsing and general cleanup, backed by someone
> who's willing to do work to integrate them smoothly wit
On Mon, May 23, 2011 at 2:30 PM, Simon Schwarz
wrote:
> Hi List,
> I'am a bit frustrated with OpenOCD...
> I have more or less random problems with it. So I am at a point to just drop
> it because I can't say if there are problems in the code or just another
> openOCD problem.
Hello Simon! Here g
On Tue, May 24, 2011 at 11:12 AM, Simon Schwarz
wrote:
> The problem is I don't have the time to do that :( I'am working on my
> bachelor thesis and the title is not "devkit8000/omap3530 support for
> OpenOCD" - unfortunately ;)
Yes, I had the same problem with my BSc two years ago and LPC2148 cp
On Tue, May 24, 2011 at 11:41 AM, Tomek CEDRO wrote:
> ps/2: I just found that switching off clock divisor in 2232H breaks
> khz clocking - fix in progress...
Clock selection mechanism was broken, but its already fixed in current
source tree, false alarm, I have documented some functions
On Wed, May 25, 2011 at 7:56 PM, Rodrigo Rosa wrote:
> (..)
> What I need is similar to getting a command to manually blink the leds
> on a given layout (execute layout->blink @ ft2232.c). The difference
> would be that i want to send/receive parameters.
Use the MPSSE and ft2232_write() (I think
On Thu, May 26, 2011 at 2:00 AM, Rodrigo Rosa wrote:
> what I would like to implement is a user command to run from the
> telnet interface to read and write to the io pins available on the
> ftdi chip while set to jtag mode.
Ah, I forgot to mention the most important - to be able to realize
trans
I think this bug (or similar) was removed very recently (less than
month), surely in cable_init(), maybe some other place? Please take a
look at changelog - I had the similar issue with FT2232H but its now
fixed with change in adapter_init()
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Hello Sebastien,
Please stay to your convention and use "open" to open functionality
and "init" to init functionality - this is very good idea and used in
transport layer (select, then init), but there is "select" instead of
"open", so maybe we should change all names to "open"..?
Using "init_sub
Uhm, ok then if it was like this. Anyway "init" for the interface or
transport that does not do "init" but verify/interrogate/start sounds
strange for me anyway. "open" and "init" sounds better :-) Maybe
"init" and "start" would be even more unabiguous? But thats for
future.. :-)
--
CeDeROM, SQ7M
On Wed, Jun 1, 2011 at 3:06 PM, Øyvind Harboe wrote:
> I haven't read over this patch. Do you think it is ready or does it need work?
Hello :-) For me lots of things should be changed/reorganized anyway
so I don't really want to interfere at this stage until I know I have
time and resources to wo
Hello again :-)
I have reviewed the patch.
The old source code had 3 functions ft2232_init() that can call
ft2232_init_libftdi() or ft2232_init_ftd2xx() depending on a ft2232
ftdi communication library available. This is pretty simple and
coherent.
The new source code (after patching) have 6 fu
On Wed, Jun 1, 2011 at 7:05 PM, Peter Stuge wrote:
> Please just use goto to handle errors.
"goto hell" ;-)
God function looks like:
input o---[function]---o output
no other :-) no gotos :-) no globals :-) nice program flow :-) clean
and self commentary code :-) good vibration :-) :-)
--
CeD
Hello Oyvind! :-)
On Sat, Jun 4, 2011 at 7:43 AM, Øyvind Harboe wrote:
> I've been pondering adding a new target that would use a
> gdbserver as a backend.
>
> Here it would be possible to use e.g. OpenOCD's
> thread support against commercial GDB servers that
> add support for targets that OpenO
On Sat, Jun 4, 2011 at 8:31 AM, Øyvind Harboe wrote:
> I definitely want to see a gdb server target. I don't think
> a gdb server openocd "interface" makes any sense.
From current organization:
-target is a device/cpu
-target needs physical connection using interface
"Remote gdb" would not be ne
On Sat, Jun 4, 2011 at 9:26 AM, Øyvind Harboe wrote:
> No reason why target should require this in the future. I'd also like to see a
> "dummy" target for testing purposes that requires no interface.
Hmm, such "dummy target" could become pretty good universal framework
for abstracting many other
One question from me to the subject - why git submodule {init,update}
is located after autotools? Autotools can depend on submodules so
those should be ready before autotools..? :-)
Another question - why not use autoreconf that can work recursively on
submodules?
:-)
--
CeDeROM, SQ7MHZ, http:/
On Mon, Jun 6, 2011 at 8:11 AM, Yegor Yefremov
wrote:
> I see your point. This won't function because
> ftdi_usb_open_desc_index() makes strncmp() and the strings won't
> match. So the patch was wrong. Sorry for the noise.
I think recently I have tried to use JTAGkey2 configuration to
JTAGkey2P d
Hello Laurent,
Sorry if my comment seems not meritoric, I am not mentioning about
coding style because this leaves a lot to tell in case of all program
source tree. I am not advanced OpenOCD developer, I am learning code
internals for some time and I have some grasp on it already (enough to
recogn
On Mon, Jun 6, 2011 at 11:44 AM, Laurent Gauch
wrote:
> If our ft2232.c patches are not merged quickly, Amontec Team will certainly
> come with a new specific jtagkey.c API driver instead of the ft2232.c JTAG
> driver.
> The advantage with a specific Amontec JTAGkey API driver in openocd, will be
On Mon, Jun 6, 2011 at 3:39 PM, Freddie Chopin wrote:
> OpenOCD currently does not support SWD (only JTAG), thus it cannot support
> Cortex-M0. I don't know the status of SWD work - I haven't followed it for
> some time.
Work in progress, almost ready, still fixing stuff, should send patches soon
Hello all! :-)
>From all of the above posts Laurent it looks that you are trying to do
the TRANSPORT job. Please take a look at transport infrastructure. The
interface simply needs to be available for other things to work, so
there is no point in having handle ready with unusable interface. I
can
Hello world :-)
The work on SWD is almost ready. You can watch the code at [1]. This
is the source tree I am currently working on with KT-LINK interface
and STM32Primer{1,2}. After some fixes and verification its in a few
days it should be merged with OpenOCD source tree. You can already
test, fam
Sure thing Oyvind! I am working on the separate repository that is
publicly available, so anyone can take a look at the code, also the
migration using git should be possible easily. When I consider the
work is definitely finished (soon I hope), I will work on providing
small patches :-)
You may st
On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe wrote:
> First thing I tried was to rebase your master branch on
> top of origin/master and that didn't work...
Uhm, this is based on a version from March or April... and there are
also some unnecessary changes that should be filtered out I guess.
>
Hello Laurent! :-)
On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch 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
On Thu, Jun 9, 2011 at 2:58 PM, simon qian wrote:
> Is this patch acceptable?
> Or should I put all codes in vsllink.c file?
My proposition is to put everything in vslink.c for better
organization in upcoming update..? Then we pick the best of all and
put yet in another place :-)
--
CeDeROM, SQ
On Thu, Jun 9, 2011 at 10:57 PM, Andreas Fritiofson
wrote:
> 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
Hello Andreas :-)
On Thu, Jun 9, 2011 at 11:30 PM, Andreas Fritiofson
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 a
On Thu, Jun 9, 2011 at 11:46 PM, Andreas Fritiofson
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
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 phys
On Fri, Jun 10, 2011 at 12:35 AM, Andreas Fritiofson
wrote:
> What are you talking about? Not all ftdi dongles are wired like this =>
> there is no universal default setting suitable for all dongles.
Uhm, I read bad at 3am :-) You told that not always setting Hi-Z on FT
chip equals Hi-Z on JTAG c
On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe wrote:
> First thing I tried was to rebase your master branch on
> top of origin/master and that didn't work...
>
> Could you rebase it on top of master branch and force a push?
I also have problem with merge conflict in src/jtag/core.c :-( How can
I
Good news - the interface_signal and bitbang framework is now ready
and verified on KT-LINK FT2232 based device. The example screenshots
of new functionality are here:
http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=Main_Page#Screenshots_2
It took some more time to verify and
The solution for deinitialization is trivial - fix generic
ft22332_quit() to match general needs of well designed interfaces
(i.e. putting Hi-Z on FT chip is enough to cut it off electrically
from target / produce Hi-Z on cable pinout). If any other dongle needs
some specific deinitialization defin
Xiao, with your involvement to both projects, I long thought you are
already a maintainer/developer! Why not yet? :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists
On Fri, Jun 10, 2011 at 7:17 PM, Michael Schwingen
wrote:
> If we agree that we do not want to touch the target, that means the
> lowlevel interface driver must not change any signal state upon exit,
> because it does not know what state that will put the target into.
If you disconnect the dongle
On Fri, Jun 10, 2011 at 7:39 PM, Øyvind Harboe wrote:
>> Please - cut a simple release now - nothing fancy, one or two RC, two weeks
>> for feedback and voila.
>
> I want someone qualified to step up to do the work of a release manager
> or I'm happy with current situation.
I agree with Freddie -
On Fri, Jun 10, 2011 at 8:01 PM, Michael Schwingen
wrote:
>>> Changing signals to High-Z is *not* safe. It changes the JTAG signals to
>>> a board-specific state that depends on the pullup/pulldown resistors on
>>> the board. Depending on the old state of the JTAG pins, this may cause a
>>> clock
On Fri, Jun 10, 2011 at 8:06 PM, Peter Stuge wrote:
> Tomek CEDRO wrote:
>> > Changing signals to High-Z is *not* safe. It changes the JTAG signals to
>> > a board-specific state that depends on the pullup/pulldown resistors
> ..
>> If you switch output into Hi-Z the
On Fri, Jun 10, 2011 at 8:35 PM, Tomek CEDRO wrote:
> Quiting without quit is like quit button in windows vista - it does
> not only quit but first of all suspends system ;]
I mean "shutdown".. or something like that.. I don't use that shit anyway :-)
--
Done. I have created new branch in my repository, just in case, it is
named openocd-swd, it is already rebased with actual openocd/master
branch :-)
It builds fine. The interface_signal and bitbang works fine, I will
prepare patches in a moment. The rest of functionality is not yet
verified! bewar
Oyvid,
I have also created branch openocd-master to have up-to-date openocd
repository at site to produce patches.
Now when I do "git format-patch openocd-master file" I get bunch of
patch files based on my local commits. This is nasty as brings
unnecessary commits. I would rather produce one pat
Do you think its time to create and work on 0.5 branch?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Sure thing I want to support in an useful way! This is also good
skills training for me :-) Thank you all for useful hints -
interactive rebasing seems to be what I need, as presented on
http://book.git-scm.com/4_interactive_rebasing.html
"You can also rebase interactively. This is often used to r
Im afraid there is not much sense in that interactive rebasing for
such big change - it took me so many hours to split patches and in
result now there are even more patches some new patches patched by old
patches ;] This is far from perfect.
I think we should simply use the default rebase patches
I have deleted ols meddy openocd-swd branch and pushed new branch with
the same name openocd-swd, this one:
-use fresh openocd master head
-is already rebased openocd master with changes from my fork
-has already squashed commits of my work (less commits than before,
more changes at once, no need t
1 - 100 of 217 matches
Mail list logo
