Hi!
From what I've read berlios has found some funding so it's going to
operate, but will the mailing lists be kept online?
Sourceforge deleted the list, there is an archive available, so what's
so hard in undeleting it?
4\/3!!
___
On 2011-11-03 17:38, Tomek CEDRO wrote:
The problem is that C (or GCC) can
only change variable out of function using *variable=value
construct.
That's how C works - everything is passed to the function by value, so
when you pass a pointer, you just pass a value which is an address.
4\/3!!
New package for Windows is available for download on my website
www.freddiechopin.info
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
So that's normal that all patchsets now are marked as not verified
(X) because the build fails at a file completely unaffected by that
patch and unchanged for a long time (buspirate.c for example)?
4\/3!!
___
Openocd-development mailing list
The change that Steve Bennett suggested me in email is now posted to
Gerrit and it solves the problem.
uplevel #0 [list source [find $filename]]
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On 2011-10-22 10:50, Øyvind Harboe wrote:
all you have to do, is to rebase your fix on top of the other fix
that's in the
queue and push. Then your patch will go green.
Hmm... Something not working on the server probably...
$ git fetch http://openocd.zylin.com/p/openocd refs/changes/43/43/3
Just as Peter suspected the problem is caused by commit
a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with
bisecting. I've also build version with that single commit reverted
which worked as expected and as before.
I've pushed revert-patch for Gerrit review. I believe it should
On 2011-10-21 19:09, Øyvind Harboe (Code Review) wrote:
Please look up the discussion of why this code was modified to use
uplevel and amend the commit with an explanation of why we should use
the proposed behaviour instead.
I cannot comment on Gerrit...
The discussion -
On 2011-10-21 19:39, Peter Stuge wrote:
Not so easy. I disagree with reverting the patch without having a
clear plan for the real fix.
Not easy because it is not neccessarily possible to implement the
same functionality in any other way.
The proper solution requries Jim expertise which I have
On 2011-10-21 20:13, Peter Stuge wrote:
Meanwhile, the workaround is quite trivial.
Yeah, right... Tell that to thousands of OpenOCD users who do NOT build
their binary. How can they change startup.tcl when it's hardcoded into
openocd.exe?
I'm more interested in knowing if not using
Hi!
The most recent OpenOCD behaves differently on Windows than 0.5.0 (and
before) and in my opinion the direction of change is to worse.
OpenOCD 0.5.0 could be run this way:
openocd -f interface/jtagkey.cfg -f target/stm32.cfg
And it worked fine. Current OpenOCD when trying this gives:
Hi!
I've prepared a package but I've found an inconvenience in handling
paths in new version (see other thread) so I'll see whether there's a
will and possibility to fix/change that before publishing. If you need
it now I can send you the package.
4\/3!!
On 2011-10-20 01:42, Peter Stuge wrote:
Maybe you can also describe how you build them?
No magic here - it's just much simpler to do crosscompilation on Linux
than fighting natively in Windows. The cause of problems in Windows is
that OpenOCD needs many tools to be compiled. libftdi needs
Nothing to comment here - pretty straightforward.
4\/3!!
From 39cb927737d653db8610fce8001aa98e8b256451 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 19 Oct 2011 17:55:33 +0200
Subject: [PATCH] Unused variables
Fix a few errors with set and unused variables
On 2011-10-19 19:50, Øyvind Harboe wrote:
Please read HACKING and post to Gerrit.
Sorry, I don't have time to do so because:
1. The patch is trivial
2. I use git in Linux hosted in VitualBox, where emailing patches kinda
does not work
3. My knowledge of Linux and Git is minimal
So basically
Hi!
I've just posted Windows packages with OpenOCD 0.5.0 on my website -
http://www.freddiechopin.info/ - enjoy (;
Below I post the news article associated with this files
OpenOCD 0.5.0 finally published!
Almost one and a half year
On 2011-08-10 18:13, Manuel Borchers wrote:
The point he was trying to make is, that one _may_ need (or want to
stick to) the native FTDI drivers. This may be because one wants to
use the other channel as a normal UART (speak use the virtual com port)
You can use normal UART on the second
On 2011-08-10 20:04, Freddie Chopin wrote:
I don't know whether an IT admin would refuse to
install completely free driver in the system.
I meant:
I don't know any reason why IT admin would refuse to install completely
free driver in the system.
4\/3
Is the idea to make a release already dead? rc2 was the last (3 weeks
ago) and there were huge plans to have six of such release candidates.
There were not many new patches in the repository, maybe not enough to
mandate another release candidate, but there are not many patches
because people
On 2011-07-22 17:30, Andreas Fritiofson wrote:
According to objdump, the completely different hex file is located in RAM:
Oops (; Indeed it is - I forgot that it's from a project I recently
experimented on... Sorry for the mess (;
So - I cannot confirm the issue, it works for me with 0.4.0
I can partially confirm...
Tested with 0.5.0-rc1
Comparing with right image works fine:
verify_image c://stm32_blink_led.bin 0x800
verified 29888 bytes in 0.468750s (62.267 KiB/s)
verify_image c://stm32_blink_led.bin
verified 29888 bytes in 0.484375s (60.258 KiB/s)
verify_image
On 2011-07-15 10:29, Xiaofan Chen wrote:
Interestingly increasing the jtag_khz value does not help too much.
This is with a different PC and with Freddie Chopin's binary but the
result is similar.
Most probably you reached the limit with flash programming. To test just
the throughput you
Tarballs available for 0.4.0-rcs allowed me to build executables which
would show correct version on startup as well as PDF User's Guide with
correct tag. Now all people can see is 0.5.0-dev. Real release
tarballs would be really appreciated...
4\/3!!
On 2011-07-04 16:11, Jean-Christophe PLAGNIOL-VILLARD wrote:
I'll prepare the tarball on sf.net
A tarball would be highly appreciated (; Drop us a line on the list when
it will be available! (;
Regards!
___
Openocd-development mailing list
I restate some previous question - on which revision from master is this
RC based.
My big request - could we have this RC in the official OpenOCD
repositiory (the one on sourceforge)?
4\/3!!
___
Openocd-development mailing list
OpenOCD versions from my website ( www.freddiechopin.info ) - 32- and
64-bit, the most recent one is a week old - are built with this
compiler, but with the most recent version (GCC 4.7.0) and on Linux, as
I found that easier than using Cygwin or MSYS directly in Windows.
4\/3!!
On 2011-06-10 22:02, Peter Stuge wrote:
Finally, I would be fine with a release only after Tomek's work on
SWD is done.
Sure, but it's been 18 months (1.5 year!) since a release and waiting
for some more non-tivial changes can postpone a release by unknown
amount of time. Maybe two weeks,
On 2011-06-11 04:07, Xiaofan Chen wrote:
On the other hand, I can understand what Freddie Chopin's point --
Windows users need a binary release and now many of the OpenOCD
Windows users get the binaries from Freddie. And having a release
version is important here.
Maybe it is less important for
On 2011-06-10 22:29, Tomek CEDRO wrote:
Michael, in this situation you probably simply don't want to shut down
the OpenOCD and leave things as-is with your session active
controlling the target. What is the point of leaving target in some
specific state when OpenOCD is not running? It sounds
On 2011-06-10 22:06, Peter Stuge wrote:
And that just because the code does not have information, it should
not make guesses.
Restoring initial state of FT2232 interface is just like pulling a
plug - disconnecting JTAG from board. I really see no danger in such
operation... Physical
On 2011-06-11 10:45, Michael Schwingen wrote:
Nothing fancy - just declare the current master as -RC, and see if any
critical bugs pop up during the next 2 weeks or so. I don't think this
really requires fancy release management - if noone steps up as
release manager, any release is better than
On 2011-06-07 23:04, Øyvind Harboe wrote:
Nobody has stepped up to do the work of being a release
manager.
Please - cut a simple release now - nothing fancy, one or two RC, two
weeks for feedback and voila. Reasons:
1. More or less - everything works, no fatal problems etc.
2. When SWD
: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:10:03 +0200
Subject: [PATCH] Fix unused variable warnings (errors) detected with GCC
4.7.0 - leftover changes
---
src/jtag/drivers/usbprog.c |6 --
src/target/arm_simulator.c |9 -
src/target/etb.c | 10
I've just posted new compilation od OpenOCD on my website
http://www.freddiechopin.info/index.php/en/articles/34-news/75-dostepna-nowa-rozwojowa-wersja-openocd-wreszcie
I hope to keep up the recent schedule (new compilation every two months).
BTW - is any release planed? 0.4.0 was downloaded
Hi!
New version of OpenOCD should be available on my website soon - we just
have to get rid of some compilation errors...
https://lists.berlios.de/pipermail/openocd-development/2011-June/019260.html
4\/3!!
___
Openocd-development mailing list
On 2011-06-06 14:17, Jonathan Dumaresq wrote:
I wonder if openOCD have support for Cortex-M0 ? We just started working
with NXP devices and I don’t see any support for the M0 in the Openocd
script file…
OpenOCD currently does not support SWD (only JTAG), thus it cannot
support Cortex-M0. I
On 2011-06-04 09:48, Øyvind Harboe wrote:
usbprog.c is clearly broken, I don't think this warning should be fixed as
that would be shuffling a bug under the carpet.
Maybe, but it compiles this way (; To me it seems that there was some
old way of making things, then new way come and somebody
On 2011-06-04 10:30, Øyvind Harboe wrote:
I just wanted to merge those changes that were ready to go
in as that was all I have time for this morning.
Some of your changes broke compiling on gcc 4.4.3(generated
more warnings), so I didn't want to put them in there yet. I think
gcc 4.4.3
From 4ddfcfae08c7413de09b8f08eb079a63fe609596 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:10:03 +0200
Subject: [PATCH 1/2] Fix unused variable warnings (errors) detected with GCC
4.7.0 - trivial fixes
---
src/flash/nor/core.c |2
From 47280c11e16f2136ef4c4c7ffd89466985cc5faa Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:13:35 +0200
Subject: [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC
4.7.0 - dubious fixes
---
src/jtag/drivers/usbprog.c |6
On 2011-06-02 08:12, Øyvind Harboe wrote:
Perhaps you could split this patch into several patches with the first
patch to go in are with the most obvious fixes?
E.g. I was less sure about etb.c, but it might be fine...
Any hints on the method to split such commited change into several
Hi again!
I've completely modified my build environment. Now I'm using current
Ubuntu (on virtual machine) with most recent MinGW-W64 (32-bit for now,
currently setting up 64-bit). The error with sscanf() is gone, but new
GCC (4.7.0) is now more picky about non-used variables and it almost
2001
From: Freddie Chopin freddie@Ubuntu-VirtualBox.(none)
Date: Wed, 1 Jun 2011 22:18:38 +0200
Subject: [PATCH] Fix unused variable warnings (errors) detected with GCC 4.7.0
---
src/flash/nor/core.c |2 --
src/flash/nor/em357.c |3 ---
src/flash/nor/pic32mx.c |3
Hi!
I'm trying to compile new OpenOCD source (from git) in my
crosscompilation setup but I see these errors:
/../../src/rtos/'`rtos.c
libtool: compile: i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I../../../src/rtos -I../.. -I../../../src -I../../src
On 2011-01-09 23:50, Øyvind Harboe wrote:
I don't think so, I'm not sure what you mean.
So I'm not sure whether I know what you propose (; Your example is
pretty cryptic for me (; In a free moment I'd be grateful for a better
explanation of your idea.
4\/3!!
for names like $_FLASHNAME and so on.
4\/3!!
From 3fad208e72dff84db40e95d9553944a105f2b977 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 8 Jan 2011 12:29:31 +0100
Subject: [PATCH] Add another level of procedures to LPC2xxx initialization -
procedures for specific
On 2011-01-07 17:11, Øyvind Harboe wrote:
Hopefully we can make some progress towards
simplifying the scripts going forward...
I've come up with an improvement of the idea - I'll present the patch
tomorrow. This will make it easier to create custom versions of specific
targets (;
Would
On 2011-01-07 17:18, Øyvind Harboe wrote:
How about using named parameters instead?
Is that possible? How would that be done? This could be very nice, as
now the comment with explanation is necessary. The same is true for
flash bank command. There is one con of such idea - the call to
On 2011-01-07 17:22, Freddie Chopin wrote:
I've come up with an improvement of the idea - I'll present the patch
tomorrow. This will make it easier to create custom versions of specific
targets (;
Here is an example of lpc2103.cfg with this change (draft [; ):
# NXP LPC2103 ARM7TDMI-S
How about something like this?
4\/3!!
From d89da81ac005fd645522e620fee20cd6808a0af1 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Thu, 6 Jan 2011 12:48:05 +0100
Subject: [PATCH] Add common LPC2xxx setup procedure, use in all LPC2xxx files.
Signed-off-by: Freddie
On 2011-01-06 13:00, Øyvind Harboe wrote:
What about the reset-init sequences?
E.g. LPC2478 has a reset-init sequence that is gone here, so
this would break flash programming.
Can or should the reset-init sequences be pretty much centralized too?
Are they simply missing from some of the other
On 2011-01-05 20:02, Øyvind Harboe wrote:
Going twice...
I'd just like to say, that I like the idea but all LPC2xxx family can
have only one common script, as there are no differences in how OpenOCD
handles these chips. If you want to make that in several steps - fine,
but the lpc21xx.cfg
On 2011-01-05 23:00, Øyvind Harboe wrote:
On Wed, Jan 5, 2011 at 10:55 PM, Freddie Chopinfreddie_cho...@op.pl wrote:
On 2011-01-05 20:02, Øyvind Harboe wrote:
Going twice...
I'd just like to say, that I like the idea but all LPC2xxx family can have
only one common script, as there are no
On 2010-12-26 17:54, Øyvind Harboe wrote:
tcl/target/lpc2x78.cfg | 32
Wouldn't that be better to just add lpc2xxx.cfg file? Whole LPC2xxx
family is quite the same if OpenOCD is concerned...
4\/3!!
___
On 2010-12-22 18:31, Spencer Oliver wrote:
- 0xdf, 0xf8, 0x20, 0x40, /* ldr r4, STM32_FLASH_BASE */
+ 0x08, 0x4c, /* ldr r4, STM32_FLASH_BASE */
How is that possible?
4\/3!!
___
On 2010-12-22 18:31, Spencer Oliver wrote:
diff --git a/tcl/target/stm32.cfg b/tcl/target/stm32.cfg
index 86e6ebb..eef1269 100644
--- a/tcl/target/stm32.cfg
+++ b/tcl/target/stm32.cfg
@@ -52,18 +52,22 @@ if { [info exists BSTAPID ] } {
set _BSTAPID4 0x06414041
# Connectivity line
On 2010-12-20 15:58, Kenan Özdemir wrote:
I already turned off the optimization, and there is no return in my main.
my code looks like this:
...
I reduced it a lot to find the error, but it always jumps to the same
address. So as you can see I dont return from main...
Show the whole
According to ST datasheets the last two characters (usually -T6) stand
for package type (T = LQFP) and temperature range (6 - industrial).
These two are not very informative and not very important, so I'd be for
omitting them every time.
4\/3!!
___
On 2010-12-14 17:35, Alan Bowman wrote:
I have just connected my JTAGkey2 to a new STM32E-EVAL board, and have
found that I am unable to program/erase the onboard flash. When I
first connected to the target, I was warned that there was an
unrecognised BS tap ID. I added an extra expected-id to
On 2010-12-09 10:07, Peter Stuge wrote:
I'm hoping to hear test results from Rolf soon, as long as he does
not discover any problem I think the patch should be committed.
I'm afraid they are hoping that we get bored with waiting for any
reply or decision, and that this good idea will die.
On 2010-12-06 00:35, Rolf Meeser wrote:
Copy protection of LPC controllers relies on the fact that it is not
possible to halt the processor right after reset.
If your findings were correct, you would have discovered an easy way to
circumvent NXP's security mechanism.
The copy protection still
On 2010-12-08 06:57, Peter Stuge wrote:
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.
U'r welcome [;
I will violently oppose any attempt to add the option back to config
files for 2148
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
On 2010-12-04 19:29, Michael Schwingen wrote:
Just because the current files are hard-wired in a way that suits you
does not mean they work fine for everyone.
Have you considered opposite approach? Just because the need of creating
another file suits you does not mean this is fine for
On 2010-12-05 10:13, Andrew Leech wrote:
On 05/12/2010, at 7:49 PM, Freddie Chopinfreddie_cho...@op.pl wrote:
On 2010-12-04 19:29, Michael Schwingen wrote:
Just because the current files are hard-wired in a way that suits you
does not mean they work fine for everyone.
Have you considered
Oh - another solution is creating a board file that defines all that is
necessary. Such board file could also define some default values of
reset_config, adapter_khz etc. I'm starting to like that idea (; The
only problem is the amount of new files that would be created this way...
4\/3!!
So how about this idea of removing useless and wrong occurences of
srst_pulls_trst from lpc config files?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On 2010-12-04 00:00, Michael Schwingen wrote:
On 12/03/2010 11:11 PM, Freddie Chopin wrote:
How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz
internal clock. Doing reset halt sets that clock and prevents any
code from changing that (let's not talk about broken cases, because
On 2010-12-04 00:32, Rolf Meeser wrote:
This is a misconception. When OpenOCD tries to take control after a
reset, the CPU is already running. ISP mode or existing user firmware
may or may not have changed the clock tree. Like it or not, but there is
no a priori knowledge of CPU clock.
When
On 2010-12-04 12:05, Rolf Meeser wrote:
When doing reset halt (which would halt the chip immediately after
reset) the clock would be 4MHz.
Wrong. I've explained that often enough.
So you say that after reset and immediate halt the chip clock (for new
LPCs) is not 4MHz? Are you working for
On 2010-12-04 12:05, Rolf Meeser wrote:
For me this policy is right. I'm willing to state this on as many
occasions as required.
Speaking about this right/wrong policy - it's said that reset_config
does not belong to target config files, yet you haven't changed that,
but left these wrong
On 2010-12-04 13:59, Rolf Meeser wrote:
Definitely my last post on this thread.
If that's the case then there's no need to reply...
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On 2010-12-04 13:59, Rolf Meeser wrote:
Definitely my last post on this thread.
On 12/04/2010 12:33 PM, Freddie Chopin wrote:
On 2010-12-04 12:05, Rolf Meeser wrote:
When doing reset halt (which would halt the chip immediately after
reset) the clock would be 4MHz.
Wrong. I've explained
74e3b52516be9211fa6ea6a89853ac7a3a1fa478 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 4 Dec 2010 15:45:40 +0100
Subject: [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
LPC2xxx do not require reset_config srst_pulls_trst. This can cause various
strange problems when flashing the chip
to original patch: CCLK is made optional, if not specified use 4MHz
default value.
Originally by: Rolf Meeser rolfm_...@yahoo.de
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2478.cfg |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/tcl/target
On 2010-12-03 14:31, Rolf Meeser wrote:
This patch allows a board script to specify the CPU clock of the LPC2478 target.
The clock frequency used to be fixed to 4 MHz. However, there is no default
frequency for this CPU. You mustn't assume prior knowledge of the clock
frequency, but rather
On 2010-12-03 12:49, Spencer Oliver wrote:
On 02/12/2010 13:15, Spencer Oliver wrote:
How about something like this:
http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/stm32reset
No objections to this then i will commit later today.
If I understand your path correctly - it removes
On 2010-12-03 21:39, Rolf Meeser wrote:
On 12/03/2010 08:09 PM, Freddie Chopin wrote:
First of all, the chip frequency after reset actually is 4MHz due to
internal RC oscillator, so this default frequency assumption seems
pretty correct (actually it was probably me who added that script
On 2010-12-03 21:39, Rolf Meeser wrote:
If for instance the flash is empty, the device will enter ISP mode
automatically. It will activate the PLL, and from then on run with
14.748 MHz. When in this situation you program the flash with the clock
parameter set to 4 MHz, the programming pulse will
On 2010-12-03 22:42, Michael Schwingen wrote:
On 12/03/2010 10:06 PM, Freddie Chopin wrote:
On 2010-12-03 21:39, Rolf Meeser wrote:
The clock parameter is vital for correct and reliable flash programming.
It must be possible for the user to select the frequency that he is
using.
I don't know
On 2010-12-03 23:29, Spencer Oliver wrote:
On 03/12/2010 19:13, Freddie Chopin wrote:
On 2010-12-03 12:49, Spencer Oliver wrote:
On 02/12/2010 13:15, Spencer Oliver wrote:
How about something like this:
http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/stm32reset
No objections
On 2010-12-02 00:37, Antonio Borneo wrote:
the patch involves file renaming.
Please add the flags -M -C to git-format-patch
With these flags the patch would be smaller, and would be easier to
follow the renaming.
Sorry, can't do that... The patch you see was created in Windows with
Update Eclipse to the most recent version (Helios SR1) and use the most
recent GDB Hardware Debugging plugin.
Take a look at similar thread on arm-gnu list (CodeSourcery's mailing
list for Lite version).
4\/3!!
___
Openocd-development mailing list
On 2010-11-30 08:20, Øyvind Harboe wrote:
Are there any patches out there that should have been
applied but haven't?
Are you planning a release?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On 2010-11-30 06:38, Tomek CEDRO wrote:
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 :-)
This is also an
On 2010-11-30 17:46, Tomek CEDRO wrote:
Freddie, this is free and open source project, so no way to enforce rush
from anyone on anyone, the work is in progress. I have managed to
include this project somehow with my current tasks so I can put some
more time into it, but I had to reschedule it
From 852e118ef27fd3fb0b7d32f9524c89f58d171152 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:49:48 +0100
Subject: [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
STM32 fully support NVIC's sysresetreq (which also resets peripherals
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
From 995335b80223931c2c4b3686c4db563b9119cce1 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:55:56 +0100
Subject: [PATCH 2/2] rename some target scripts to be consistent with the rest
Rename Atmel target scripts which had wrong name (at91 missing
On 2010-11-29 14:44, Tomek CEDRO wrote:
The SWD API is almost done, for few days already im trying to integrate
it into UrJTAG as this is simpler software than OpenOCD from complexity
point of view. When transport is verifed (~week 49/50) im moving to
OpenOCD and debugging. The hardware I am
On 2010-11-29 07:40, Eric Parsonage wrote:
I want a release version of openocd that supports Lisa-l.
Lisa-l support has been in the code for several months now but there is no
sight of any release.
BTW if you use Windows, you can download development versions of OpenOCD
from my webpage -
On 2010-11-16 00:27, Andrew Leech wrote:
I personally don't have an issue with requiring unix line endings
Most likely all Windows users won't mind that...
World does not end on *nix systems... However the list of popular OSes
probably does, so actually that should be the other way around
On 2010-11-14 16:13, Øyvind Harboe wrote:
But you did add another error check?
+ tst r3, #0x14
/* PGERR (bit2) == 1 or WRPRTERR (bit4) == 1 = error */
+ bne exit
On 2010-11-09 10:16, Øyvind Harboe wrote:
Error: 793 186992 stm32x.c:582 stm32x_write_block(): error executing
stm32x flash write algorithm
Error: 794 186993 core.c:98 flash_driver_write(): error writing to
flash at address 0x0800 at offset 0x (-302)
On 2010-11-14 16:13, Øyvind
On 2010-11-14 18:49, Øyvind Harboe wrote:
The problem is that the target is crashing while executing the programming
algorithm, so it never completes.
You mean crashing like having Hard Fault exception or sth like this?
4\/3!!
___
bbd6137fdade1b2760ade58cc23d6f9fc9b52cc2 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 13:07:08 +0100
Subject: [PATCH] Add cortex_m3 capabilities soft_reset command
Add cortex_m3 capabilities command group. Add cortex_m3 capabilities
soft_reset command
On 2010-11-13 12:48, Øyvind Harboe wrote:
I was wondering if the target database of peripheral registers
could somehow be leveraged in OpenOCD. Recall all those
pesky target combinations?
I'm not sure what do you mean );
Isn't there information in this peripheral register view plugin
that
a8d788763856fdf4dfeecad7827bb0e51e774c13 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 15:42:00 +0100
Subject: [PATCH] Add comments and tiny improvements to STM32 flash loader
algorithm
Add comments to assembly flash loader for STM32. Add tiny improvement
On 2010-11-13 16:47, Øyvind Harboe wrote:
Is it conceivable that this would address the block
flash programming problems I saw the other day
and you were not able to reproduce?
Rather not... The mechanics of this algorithm are exactly the same -
I've just shortened the inner write loop (no
On 2010-11-13 21:40, Spencer Oliver wrote:
May be better calling it config_soft_reset or similar.
I've tried to keep that short (; The longest one to type is
capabilities anyway, but I couldn't find a better word [;
Another point is that some targets (luminary) do not correctly support
1 - 100 of 365 matches
Mail list logo
