Okay, lots of code cleanup has been done and the patches has just been
sent to gerrit, I hope this time no complications :-)
Thank you Freddie for large amount of your work to pass checkpatch!! :-)
Lets see what happens now :-)
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.
I have removed today changes from gerrit, sorry, I will do the stuff
as supposed next weekend :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Rem
On Sun, Dec 9, 2012 at 9:06 PM, Freddie Chopin wrote:
> W dniu 2012-12-09 20:59, CeDeROM pisze:
>
>> You mean I can amend a commit and send it again? Like forced push? :-)
>
>
> Not only - you can change order, remove them or add new ones wherever you
> like- just make sure that the ones you wish
W dniu 2012-12-09 20:59, CeDeROM pisze:
> You mean I can amend a commit and send it again? Like forced push? :-)
Not only - you can change order, remove them or add new ones wherever
you like- just make sure that the ones you wish to keep have the same
change-id.
4\/3!!
---
On Sun, Dec 9, 2012 at 8:46 PM, Freddie Chopin wrote:
> You can do that - just update and push them again - like I did with 3 of
> them.
You mean I can amend a commit and send it again? Like forced push? :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
-
W dniu 2012-12-09 20:24, CeDeROM pisze:
> Is it possible that I send fixed commits on top of existing review
> head? Or we need to remove the patches?
You can do that - just update and push them again - like I did with 3 of
them.
4\/3!!
--
On Sun, Dec 9, 2012 at 8:17 PM, Freddie Chopin wrote:
> Here's the reason for second one failing - it's inside LibSWD actually...
> http://openocd.zylin.com/jenkins/job/openocd-gerrit-build/1256/TARGET=mingw64/console
Tanks Freddie :-) I have fixed that in 0.5, so I need to update the
first commi
Here's the reason for second one failing - it's inside LibSWD actually...
http://openocd.zylin.com/jenkins/job/openocd-gerrit-build/1256/TARGET=mingw64/console
4\/3!!
--
LogMeIn Rescue: Anywhere, Anytime Remote support f
Aah, I did not run the checkpatch... thanks for hints, please remove
all commits that I have sent, I need to rework them and send again
then :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
LogMeIn Rescue: Anywhere
On 09/12/12 18:30, CeDeROM wrote:
> Uhm, Senior Jenkins complains, but yet I am not able to get into
> details on what he is complaining about :-) Help :-)
>
You need to check the Jenkins build log for each failure, start with the
first in a series, eg.
http://openocd.zylin.com/1012 the build log
W dniu 2012-12-09 19:30, CeDeROM pisze:
> Uhm, Senior Jenkins complains, but yet I am not able to get into
> details on what he is complaining about :-) Help :-)
For example for this one:
http://openocd.zylin.com/#/c/1017/
You click the any of the links in the comment and than click on "Console
Uhm, Senior Jenkins complains, but yet I am not able to get into
details on what he is complaining about :-) Help :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
LogMeIn Rescue: Anywhere, Anytime Remote support fo
On Thu, Dec 6, 2012 at 9:31 AM, Freddie Chopin wrote:
> W dniu 2012-11-28 11:39, CeDeROM pisze:
>> Because now we know that new transport is functional and old transport
>> is still operational, do you think we should merge this work into
>> openocd master already? Are there any objections or othe
W dniu 2012-11-28 11:39, CeDeROM pisze:
> Because now we know that new transport is functional and old transport
> is still operational, do you think we should merge this work into
> openocd master already? Are there any objections or other ideas on
> what needs to be done more in this field?
I th
s, which will be a great cost down to original solutions.
Users can simply develop applications on Android with my library to communicate
with some specified peripherals.
simonqian.openocd
From: CeDeROM
Date: 2012-11-30 03:38
To: simonqian.openocd
CC: openocd-devel
Subject: Re: Re: [OpenOCD-devel] o
On Wed, Nov 28, 2012 at 10:22 AM, Freddie Chopin wrote:
> Maybe point nr. 3: an option to silence libswd a bit would be nice too -
> currently it floods the console with endless lines of bit dumps, so I see no
> warnings/erros/important_things.
This is already there :-) Please try the "libswd log
On Thu, Nov 29, 2012 at 6:55 AM, simonqian.openocd
wrote:
> For SWD, some more wise device is necessary to speed up.
> I'll try to add my code into the latest libswd when ready.
Hello Simon :-)
I have made some preparations for the OpenOCD to accept different
solutions for transport implementati
On Thu, Nov 29, 2012 at 12:26 PM, Akos Vandra wrote:
> Also, this was tested on lpc17xx, not stm32, so that's a plus :)
Akos, please send me the configuration file and details on the
configuration so it is easier for other to test this configuration as
well and I will attach it to the repository
Also, this was tested on lpc17xx, not stm32, so that's a plus :)
On 29 November 2012 11:08, CeDeROM wrote:
> On Wed, Nov 28, 2012 at 11:31 PM, Akos Vandra wrote:
> > Just started testing your code. Looks promising :)
>
> Cool, thanks for your support! :-)
>
> > SWD seems to be working - even t
On Wed, Nov 28, 2012 at 11:31 PM, Akos Vandra wrote:
> Just started testing your code. Looks promising :)
Cool, thanks for your support! :-)
> SWD seems to be working - even though extremely slowly. When resuming the
> execution, the resume does not happen only after polling the target again,
>
-11-28 18:50
To: Freddie Chopin
CC: openocd-devel
Subject: Re: [OpenOCD-devel] openocd+libswd call for testing work in progress...
On Wed, Nov 28, 2012 at 10:22 AM, Freddie Chopin wrote:
> With connected interface (JTAG-lock-pick Tiny 2) and connected target (STM32
> HD VL via SWD) I can do
Hi!
Just started testing your code. Looks promising :)
JTAG seems to be working fine for a single-device chain. For
multiple-device chains I am having problems with jtag, but the problem is
in the trunk as well. Will investigate further, and will open a new thread
for it, as the bug is probably (i
On Wed, Nov 28, 2012 at 10:22 AM, Freddie Chopin wrote:
> With connected interface (JTAG-lock-pick Tiny 2) and connected target (STM32
> HD VL via SWD) I can do some basic operations, which are really slow, but
> seem to work
The speed is limited mainly by the USB bottleneck, it should not be an
Hey Freddie! :-)
Glad to see things working, thanks! :-)
Reset is still hardwired into jtag infrastructure, I was waiting to
check current changes, then I will move reset out to src/interface,
where is thould be placed :-) Maybe polling and resuming is related to
this part...
Flash programming i
I have a fresh build (if anyone is interested I can share that)
1. Without an adapter:
> d:\openocd-dev\openocd-swd\bin-x64>openocd -f target/stm32f1x-swd.cfg
> Open On-Chip Debugger 0.7.0-dev-g2de3ce9-dirty (2012-11-28-09:33)
> Licensed under GNU GPL v2
> For bug reports, read
> http://o
On Sun, Nov 25, 2012 at 9:56 PM, CeDeROM wrote:
> Can you please change swd_libswd.h with
> extern oocd_feature_t oocd_transport_swd_libswd_arm_dap_feature;
Yes, that was the issue, Freddie thanks for your support!! :-) I have
now fixed past commits, please clone fresh repository and try the
buil
On Sun, Nov 25, 2012 at 10:09 PM, Freddie Chopin wrote:
> Hmm... How should I do all of these (yes, I'm no unix kind of guy...)?
>
> CFLAGS="-O0 -g -ggdb3" LDFLAGS="-g" ./configure ...
>
> Will that work? The configure scripts probably sets optimization to some
> other level so how do I override t
W dniu 2012-11-25 21:58, CeDeROM pisze:
> Ah, can you also try to build with no optimization? I have some
> variables "optimized out" when debugging :-)
Hmm... How should I do all of these (yes, I'm no unix kind of guy...)?
CFLAGS="-O0 -g -ggdb3" LDFLAGS="-g" ./configure ...
Will that work? The
Ah, can you also try to build with no optimization? I have some
variables "optimized out" when debugging :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
Monitor your physical, virtual and cloud infrastructure from
Hey Freddie :-)
I have tried your binaries :-) They additionally need the sources in
proper location to debug because binary does not contain source code
symbols (?).
For some reason "oocd_feature_t
oocd_transport_swd_libswd_arm_dap_feature;" from
src/transport/swd_libswd.h is invisible at runtim
On Wed, Nov 21, 2012 at 4:55 PM, Freddie Chopin wrote:
> I had to add --disable-werror as there are some problems (warnings) during
> the build (or there were?). If you did not see them I can check for them
> again and post details... I'm not sure whether the warnings were there with
> these exact
W dniu 2012-11-21 15:51, CeDeROM pisze:
> I have made a build on a Linux and it works fine, so the issue seems
> to be Windows related.. please tell me the exact build environment, or
> send the binary so I can debug it :-)
Below is the link to unstripped binary (32- and 64-bit version,
whichever
I have made a build on a Linux and it works fine, so the issue seems
to be Windows related.. please tell me the exact build environment, or
send the binary so I can debug it :-)
cd@bt:~/work/openocd-libswd/libswd$ /tmp/openocd/target/bin/openocd -c
"source [find target/stm32f1x-swd.cfg]"
Open On-C
On Wed, Nov 21, 2012 at 10:50 AM, Freddie Chopin wrote:
> Debug log doesn't give much more info (apart from filenames and line
> numbers):
> If you think that some previous version would work I could try, but I
> don't know if it will be any benefit for you.
Nope, this is some compiler issue...
On Wed, Nov 21, 2012 at 10:38 AM, Freddie Chopin wrote:
> This approach would not work for cross-compilation and Windows (; My
> configure command was equivalent to the script (maintainer mode,
> ft2232-libftdi), yet it does not work like for you...
Hmm, interesting! :-)
The problem is in src/tr
Debug log doesn't give much more info (apart from filenames and line
numbers):
> d:\openocd-dev\openocd-swd\bin>openocd -c "source [find
> target/stm32f1x-swd.cfg]
> " -d3
> Open On-Chip Debugger 0.7.0-dev-g88134cb-dirty (2012-11-20-08:36)
> Licensed under GNU GPL v2
> For bug reports, read
>
W dniu 2012-11-21 09:39, CeDeROM pisze:
> % /tmp/openocd/target/bin/openocd -c "source [find target/stm32f1x-swd.cfg]"
> Open On-Chip Debugger 0.7.0-dev-g88134cb-dirty (2012-11-21-09:36)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.sourceforge.net/doc/doxygen/bugs.h
On Tue, Nov 20, 2012 at 8:29 PM, Freddie Chopin wrote:
> Well, I've cloned the repo and built the binary this morning, so it's
> not that old (;
> I'll rebuild and report whatever you need, hoping that we're closer to
> the end [;
Here what happens for me with recent head of master branch:
% git
Well, I've cloned the repo and built the binary this morning, so it's
not that old (;
I'll rebuild and report whatever you need, hoping that we're closer to
the end [;
4\/3!!
--
Monitor your physical, virtual and cloud
W dniu 2012-11-20 19:46, CeDeROM pisze:
>>> Open On-Chip Debugger 0.7.0-dev-g88134cb-dirty (2012-11-20-08:40)
> Open On-Chip Debugger 0.7.0-dev-g7767703-dirty (2012-11-18-22:56)
On the other hand - my binary (1st) is the last commit from your repo:
http://repo.or.cz/w/openocd/libswd.git/commit/88
Uhm, thanks for repoting!! I have renamed the features for swd and
libswd this might be the reason. Please clone fresh reporisoty and
retry as I have made some forced pushes :-)
> Info : Transport - selecting LibSWD as SWD transport mechanism and interface
> fea
> tures...
> Error: Cannot add thi
I cannot get it to work with SWD... What am I doing wrong here?
> d:\openocd-dev\openocd-swd\bin-x64>openocd.exe -f target/stm32f1x-swd1.cfg
> Open On-Chip Debugger 0.7.0-dev-g88134cb-dirty (2012-11-20-08:40)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.sourceforge.
On Tue, Nov 20, 2012 at 7:43 AM, Akos Vandra wrote:
> I have not yet had time to test your code, but I am looking forward to.
> Can you tell me in advance what were the r/w speeds you achieved?
Its no speed optimization yet - around 15sec per 2k. I have added
example toggle.hex/bin and stm32f1x-s
As there was no objections for existing JTAG infrastructure, I have
applied next commits with MEM-AP code fix and separation from
hardcoded jtag part (i created a wrapper and old function is in place
untouched).
The SWD flash memory programming now works, you can try example:
1. contrib/helloworl
I have updated the libswd+openocd fork head, the JTAG should work now,
please verify..
When JTAG is verified working and I did not introduce any regression
in JTAG with my rather large changes I will move forward and apply
following commits in mem-ap code that makes SWD work (I have them
already o
Ah your session should look something like this:
% ./openocd -f stm32swd.cfg
Open On-Chip Debugger 0.7.0-dev-gcf35ed5-dirty (2012-11-16-02:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect '
Hello :-)
I have made it to detect IDCODE with KT-LINK (FT2232H) interface and
STM32(Primer2) board using SWD provided by LibSWD. Because there are
major changes in the Transport system I need some support and feedback
if SWD IDCODE detection and old JTAG code works for other people - SWD
IDCODE s
Regarding the interface - no need to modify the sources everything is
already there, just create your interface configuration script based on the
kt-link-swd.cfg, the RnW signal is mandatory for SWD even if you dont use
it simply pass a LED or something to see things working :-) good luck, now
im l
Witht the KT-LINK design there is one signal (GPIOL1) that routes TDI and
TDO signal into SWDIOTMS pin, and one RnW (GPIOH4) signal that switches the
TDI output buffer for write, the TDO is always listening.
Therefore if you put a 1k resistor (or a diode with K at TDI) between TDI
and TDO and pull
W dniu 2012-04-14 14:23, Tomek CEDRO pisze:
> Thank you for your input :-) currently I am in Paris out of my lab so I
> cannot exactly tell you how to create the buffer with a resistors sorry,
I know how to create such buffer (;
IN -[R]--
|- IN/OUT
OUT -[R]-
simpliest JTAG-SWD converte
I've managed to compile the code. There was only one error/warning - in
function ft2232_transfer() in ft2232.c the name "byte" shadows global
variable with the same name.
4\/3!!
--
For Developers, A Lot Can Happen In A
Hello Freddie!
Thank you for your input :-) currently I am in Paris out of my lab so I
cannot exactly tell you how to create the buffer with a resistors sorry,
but it should work on standard ft2232 based cable as well and someone nice
guy from Srilanka reported it is working :-) I will check that
Hi there!
First of all - thx for all your work on SWD!
I have two questions:
1. What steps should I follow to add "drier" for "normal", non-SWD-aware
interface, where you'd have two pins (In and Out) shorted with two
resistors to form the SWDIO signal? Is that possible? (;
2. Would that be pos
Hello :-)
I have managed to clean up the code and push it to the repository. I
have abandoned advanced enqueueing stuff for now in favor to simply
make it work :-) There are still lots of things to be done, but it is
working already and you can use it to burn your favorite binaries
straight into F
54 matches
Mail list logo
