I am not very keen on changing anything in terms of
tools around openocd as there are a lot of developers out
there that are familiar with the current situation. Every so
often we get a request to use some new tool, switch version
control, etc. I believe that it is a good thing that any such
Here is another grazy idea regarding build tools: how about adding
Eclipse project definitions? From experience I know that Eclipse
projects can be transferred between Windows and Linux without problems.
I agree the autotools aren't ideal especially when cross-compiling. When
cross compiling
This adds
config.h.cmake
which was missing in the first patch.
It seems that I will need help getting this committed.
CMake fans please step forward and make your voices heard. CMake has been accused of being off the beaten path.
From my perspective, those that take the
Øyvind Harboe wrote:
I am not very keen on changing anything in terms of
tools around openocd as there are a lot of developers out
there that are familiar with the current situation. Every so
often we get a request to use some new tool, switch version
control, etc. I believe that it is a
Kishore,
Thank you for your efforts to make this usable by those who would.
Attached is a single comprehensive patch, which should be used instead
of my two previous patches.
For those who would like to give it a spin, remember to use an out of
source build, and to use the ccmake command
Dear people,
I am looking for a way to use keil uvision with openOCD; I found that keil
has an API to talk to third party debuggers, but I can not find a driver to
talk to openOCD. So, is there any imposibility to do that, or just nobody
wrote it yet? Thanks in advance for your help.
best
Hello,
I'm new to embedded development and I've just bought a STM3210E-EVAL
board and an Olimex ARM-USB-TINY JTAG connector to play with. I've
managed to set the tool chain and such up and I'm having trouble
flashing an application. The application is from the ST example code
and blinks the LEDs
Instead of all the commands you use, just do 'reset halt' and then
flash write_image erase file_name.extension 0 bin
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Hi,
The patch does not have any side effects and problem seems to be solved
so I have committed the patch with minor cosmetic changes.
Thanks.
Regards,
Magnus
Zach Welch wrote:
Given your information and the code, the attached patch should work
around the problem, unless there are
Hi
You are just erasing one sector of the flash memory, 1k, and probalby
your bin file is larger.
Try something like: flash erase_sector 0 0 10
Magnus
Robert Taylor wrote:
Hello,
I'm new to embedded development and I've just bought a STM3210E-EVAL
board and an Olimex ARM-USB-TINY JTAG
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very
helpul about the cause of the error.
My suggestion is to return the
Dick Hollenbeck wrote:
Duane Ellis wrote:
Dick I am working on the ft232 stuff starting today.
I am to - we should coordinate...
my changes are non-trivial.
-Duane.
OK, send me what you have and what your thought are to Personal Mail if
you want.
Until I get that,
Johann F. wrote:
I can't make out the important changes from the gratuitous ones. Can
you please revert all the u8 - uint8_t changes as well as whitespace
changes?
--
Rick Altherr
kc8...@kc8apf.net
Its been a week now. I can boil it down and find the essence of the
changes.
This patch adds a couple of lines from Johann's patch, but mostly it is
merely a matter of left indenting the big switch statement by one tab
stop.
Since the function is big, and indentation levels are used liberally, I
felt we needed to scoot left one tab stop. This is consistent with the
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not
Hi
The following patch is a first step towards support for sevaral AP in
one dap.
- Adds a apsel variable, corresponding to the corresponding field in the
DP SELECT register, to the swjdap structure.
- adds a function swjdp_apselect(swjdp_common_t *swjdp,u8 apsel) to set
this variable.
-
Committed.
I haven't followed this discussion, but I take your word for that
there is a consensus that this should be committed.
Please check that the patch applied correctly.
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
Hello list,
I am working on a Mac OS X installer for OpenOCD.
If I only install the openocd executable, I got an
error that the dynamic library for libusb and libftdi
can not be found.
This is correct, because this libraries was not installed.
For the toolchain build I could use
Michael Fischer wrote:
Hello list,
I am working on a Mac OS X installer for OpenOCD.
If I only install the openocd executable, I got an
error that the dynamic library for libusb and libftdi
can not be found.
Are you saying that you want to use:
1) static libraries for libusb and
Hello Dick,
I want to build OpenOCD for FT2232 device, which use
later static libraries for libusb and libftdi.
This mean that the user do not need to install the libftdi and
libusb.
Best regards,
Michael
-Ursprüngliche Nachricht-
Von: Dick Hollenbeck [mailto:d...@softplc.com]
Hello Dick,
I try to understand how the libftdi test is working, I think
the test source look like (conftest.c):
#include stdio.h
#include ftdi.h
int
main( int argc, char **argv )
{
struct ftdi_context *p;
p = ftdi_new();
if( p != NULL ){
return 0;
}
On Apr 14, 2009, at 12:09 PM, Øyvind Harboe wrote:
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu
wrote:
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
On Apr 14, 2009, at 11:56 AM, Michael Fischer wrote:
Hello list,
I am working on a Mac OS X installer for OpenOCD.
If I only install the openocd executable, I got an
error that the dynamic library for libusb and libftdi
can not be found.
This is correct, because this libraries was not
Hello Rick,
OpenOCD is already part of MacPorts.
But here the user must install MacPorts.
Do you know my windows page, www.yagarto.de ?
Here the user will find a toolchain, and openocd
which works out of the box without to install anything else.
For the Mac I want to create a solution like
I'd rather know _why_ something failed rather than having to dig through the
code to figure out which layer and why. Not every user is a UNIX programmer
with intimate knowledge of the targets, interfaces, and general protocols.
That's what the LOG_ERROR()'s are for. They tell you where and
The reasons
First there is no support for interactive commands in cortex_swjdp.c,
and ther should not be any. All commands use a swjdp structure for
state information. This structure is owned by the target device
structure, in our case the cortex_m3 target type so that is the natural
place
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
I'd rather know _why_ something failed rather than having to dig
through the
code to figure out which layer and why. Not every user is a UNIX
programmer
with intimate knowledge of the targets, interfaces, and general
protocols.
That's
As a general matter, anyone doing OSS development on a Mac will
already have MacPorts installed. It correctly handles dependency
tracking and updating components independently.
If you really want to build a standalone package for this, you should
just include the libftdi and libusb
Rick Altherr wrote:
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
I'd rather know _why_ something failed rather than having to dig
through the
code to figure out which layer and why. Not every user is a UNIX
programmer
with intimate knowledge of the targets, interfaces, and general
So because it isn't that way today, we shouldn't set a policy to do so in
the future?
I think that would be moving in the wrong direction, yes.
I'm in favour of a boolean success/failure return value and other mechanisms
to convey other information.
Why should information about what went
On Apr 14, 2009, at 2:09 PM, Michael Fischer wrote:
Hello Rick,
As a general matter, anyone doing OSS development on a Mac will
already have MacPorts installed. It correctly handles dependency
tracking and updating components independently.
Yes you are sure, for OSS development. But I
On Apr 14, 2009, at 2:11 PM, Øyvind Harboe wrote:
So because it isn't that way today, we shouldn't set a policy to do
so in
the future?
I think that would be moving in the wrong direction, yes.
I'm in favour of a boolean success/failure return value and other
mechanisms
to convey other
32 matches
Mail list logo
